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

Reply via email to