Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Sverre H. Huseby (shhthathost.com)
Date: Sat Sep 22 2001 - 18:28:18 CDT
| [...] the article covers how far sql can be subverted - something
| which its quite easy to forget. [...]
The article shows just a tip of the iceberg. Or something like that.
If you are able to insert your own SQL, you may do almost anything.
From gaining access without knowing the password, as they show in this
article, via deleting and updating information, to extracting
information using creative UNION SELECT statements.
I do not fully agree in the solution outlined in the article. First
client side security", to quote a nice book (Hack Proofing Your
may be bypassed, so why mention it at all?
Second, they do output filtering on the input side (using
htmlspecialchars). If you filter HTML before storing stuff in the
database, you will run into problems when the data sometime in the
future will be used for other things than HTML. You also risk running
into problems like the following: Imagine a user entering the
following to be stored in a database:
with htmlspecialchars nothing happens to the input. If this string is
stored in a database that uses backslash as an escape character, like
for instance PostgreSQL does, the \074 and \076 will be mapped to <
and > respectively. As HTML tag filtering was done on the input side,
it will not be repeated on the output side, and bad guys may thus
bypass the HTML washing mechanism.
The sample in the article won't run into this problem, as they also
use addslashes that escapes the escapes. But escaping the escapes is
easily forgotten. In my opinion you should wash/validate input on the
input side, and output on the output side. Mixing sides gives
Oh, well. I just got home from a big party, so I hope my gibberish
makes sense. :)
-- shhthathost.com Try my Nerd Quiz at http://shh.thathost.com/ http://nerdquiz.thathost.com/