Thanks Alex. I re-read Ross's reply but I don't think you and him ( and even me ) is saying something different. It's all about validating the input. In my dictionary of programming vocabulary, validation is not just validating user input but also sanitizing it. You summed it up nicely by saying programmer's string vs user's string. It's the user's string where we want to focus on... If we go to the source of the problem that is "receiving user input", that's where we start. So, every single user input ( not just query-string and form-post data or cookies but even the server variables such as the *http_referer" must be considered as potential threats. If we are to store the user ip based on the server var http_referer value - without validating/sanitizing it - then we are really risking things! I Aren't we? So we should not think that hey that's a $_SERVER variable so why worry about it... I wanted to bring this matter up as a side parenthesis cause I don't think http_referer would be on many programmers' list of things to be watched out and to be sanitized! So first things first, we ned to identify all possible ways that a user input can take place. and that's not limited to querystings/form-posts and cookies. Server vars are in my list too, not all of them but those that have issues with. If you guys can think of some other types ( like the server variables that one would not think from the userland ) that I may be missing, I'd appreciate your filling in here. Once we know what possible places are out there that a user string can make it, we apply our function right there and then. So, yes, we need a library function that does this for us for once and for all. This library function must deal with data validation (on data length and on data type ) as its first line of defense. In that function, we should also do the escape! And that bring us to the 2nd line of defense. In this 2nd line of defense, we must take care of the char code specific issues. And for that it looks like mysql_real_escape_string() is my only line of defense. That's per this article http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string But it looks like, Alex you'd have a problem with that. Your reply sounded like that. Correct me if I got you wrong. If I have not misunderstood you, you have an issue with mysql_real_escape... But then could you tell me how you would deal with the GPK and GPK like matters in the light of Shiflett's article? And after that if the function is still returning OK, then I take that user input, use it in a PDO based implementation. Am I missing anything? Feel free to fill it in please so I can close this chapter and move on. On Tue, Jan 17, 2012 at 2:56 PM, Alex Nikitin <niksoft@xxxxxxxxx> wrote: > Haluk, don't listen to Ross, escaping fails, it was and is a bad > solution to an old and still largely unresolved problem. The problem > is and has been that of language interoperability, and we have been > and continue failing at making a good way for languages to talk to > each other, but because this is so needed, especially on the web, > where you blink and you are in another language; php, css, html, throw > in some javascript, and here is some SQL, oh i need some python, now > let's throw in some C, but none of these languages talk to each other, > so we have had to make it work and we do it with strings... This is > why we have SQL injection and XSS, and the only, i will repeat that, > the ONLY way to fix this issue is to have a clear way to say from > language to language that this is a programmer string, run it, and > this is user input, don't run it. > > The only right solution is to pass your code as code and the user > input as user input, this way you are guaranteed that no execution of > user input is possible via usual SQL injection or XSS means. Of course > you still need to check and sanitize your input, there are still > typical issues, buffer and heap overflows, etc, but simple inclusion > of some "special" character and user input code that just gets ran > just like programmer code is simply not possible. > > Escaping is a bad and many times failed attempt at saying that it's ok > to pass user input as code, we just escape the characters we think are > bad, to tell the interpreter not to execute them as it normally would. > But what does it mean to be a character? Well back when all these > languages were designed there was ASCII, and life was easy, now, > however we have utf7, utf8, utf16, with tens of thousands of > characters, many of which are the same symbol. Oh and they morph, if > you don't know what best-fit matching is, look it up, but at the end > of the day, if you think that you know what characters you need to > escape, you are wrong, i'm sorry. This is why in javascript there are > 3 escape functions: escape, escapeURI and escapeURIComponent. Which > roughly translate to "we failed", "we failed again" and "we failed the > third time". > > So in short, no, mysqli_real_escape_string is not a good solution to > SQL injection, PDO (as far as i can tell, though i haven't poured over > the code yet) or prepared statements, are. And neither negate the need > to check your input, as other, more traditional exploits would still > be possible (potentially) > > Oh Haluk, drop the idea of occurrences of words, it may stop someone > who is just testing your code for fun, someone determined to get in > will still do plenty of bad with whatever words you allow, and you > have to allow certain words for your queries to run ;) > > Anyways, hopefully this is something for you guys to think about and > hopefully enough to stop suggesting escaping as a viable option to > stop any sort of simple code injection... > > > ~ Alex > > -- > The trouble with programmers is that you can never tell what a > programmer is doing until it’s too late. ~Seymour Cray > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
