Geoff Caplan <geoff@variosoft.com> writes:
Doug,
DM> Geoff Caplan <geoff@variosoft.com> writes:
But in web work, you are often using GET/POST data directly in your
SQL clauses, so the untrusted data is part of the query syntax and not
just a value.
DM> Can you give an example of this that isn't also an example of
DM> obviously bad application design?
I'm no expert to put it mildly, but if you Google for "SQL Injection
Attack" you'll find a lot of papers by security agencies and
consultancies. You could start with these:
That doesn't answer my question. :)
If you're trusting the user (via GET or POST data) to hand you valid
SQL fragments, even just column names, you Deserve To Lose. The only
things that come in via GET or POST should be data values, and they
should either be explicitly escaped, or used in prepared statements
where the driver takes care of the escaping.
-Doug
Or, if your POST/GET data is necessary to alter your SQL statement,
then make it conditional, but never accept raw SQL from the user. It's
easy enough to check for certain fields (such as a checkbox for a
boolean AND or OR in your where clause). But be sure that the checkbox
never sends in SQL code, it should just send in a 1 if checked. Then
in your code, you check for that value and you manually program the 2
alternative versions of the SQL statement. It's more work in design,
but it's easier in the long run.