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
