Re: SQL Injection Basics

["Sverre H. Huseby" <shh () thathost com>]

[dreamwvr () dreamwvr com]

|   Yes then you simply extend the ; example to permit certain
|   patterns in certain fields of a certain max len. Since one never
|   directly updates databases but rather interfaces via a SQLproxy of
|   some sorts right? Then this can do the filtering or translation if
|   you will.

I'm not sure that I follow you.  What do you mean by "SQLproxy"?  Can
I buy such a proxy, or will I have to write it myself?

Small web applications tend to talk directly to the database.  In
larger web apps, the web layer is separate from the business logic
layer, which talks to the database (you may even find apps with more
layers than that, or with other kinds of separation).  Eventually,
some layer will have to talk to the database, and if that layer builds
dynamic SQL, it will need to to some filtering.

It's not just about databases:

  * Some systems generate XML.  If they combine data and tags manually
    (not using e.g. a DOM), they will have to pay attention to parts
    in the data that may be interpreted as tags.  (What would an
    "XMLproxy" be like?  (to make me understand what you mean by that
    proxy))

  * Some systems run external programs through some OS shell.  If they
    include data as part of the command, they will have to make sure
    that both the shell and the command that gets run does not treat
    any part of the data as something special.  One can get rid of the
    shell by calling some exec-like construct, but one can hardly get
    rid of the command, which may parse both command line parameters
    and piped data in special ways.

  * Some systems talk to the OS or system libraries in order to
    e.g. create local files.  If you want the context to be "inside a
    directory", the slash (and for some systems the backslash) becomes
    special.  In other cases the null-byte may be special, as it
    terminates strings in C, while it's just another character in most
    web programming languages.

  * Most web apps generate web pages, and if they build those pages
    using both markup and data combined, they will need to make sure
    the HTML parser of the browser does not treat any part of the data
    as markup.

|   So this really should not be considered the universal solvent or
|   anything.

OK.  Until I understand what you really mean, I continue thinking that
it is. :) And it would be interesting to learn what you think _is_ the
universal solution.

When passing data along to some subsystem (which we tend to do far
more often than most programmers realize), we need to understand
exactly how the system will parse every single piece of what we pass
along, in order to stop the subsystem parser from switching context.
What we see as plain data in the application, must be seen as plain
data by the subsystem.  That's my general solution. :)

The preferred approach is to pick a communication channel in which
data are passed separately from control information (e.g. prepared
statements for SQL, DOM for XML), but that's not always possible.

|   Besides boundary filtering is nothing new. It has been around for
|   a long time.

You may be right, but it has not been the most widely deployed
filtering approach in web applications.  At least not when people have
tried to explain "best practices".  Just read the few books that have
come out, or skim Usenet news or even webappsec E-mails: Most of the
time people talk about input validation as a mean to solve problems
that eventually occur deep within the system.


Sverre.

-- 
shh () thathost com             Computer Geek?  Try my Nerd Quiz
http://shh.thathost.com/        http://nerdquiz.thathost.com/