RE: SQL Injection Basics

[Patrick Debois <Patrick.Debois () sos be>]

> Hi Guys
>
> Seeing that most SQL injection problems are a result of ASP code on IIS
> Why not just drop special characters like the single tick ' using
> urlscan?

The problem is not only with ASP and the URL.
URL filters might works for GET requests but the problem also exists for
POST's (Forms). Someone can bypass the initial form using a post script.

Also it is not IIS,ASP code related as other people pointed out. IMHO it
is testing and testing and testing the APP. ASP or CFM or JSP or servlets
it does not matter.

Note:
-----
Related to what i call input checking=sql escaping, output escaping=html
escaping can be also very important. What if you have an overview page
that lists the results from user input. If someone puts in html codes,
javascript, does the application escape the HTML when giving it back to
the browser.




> Thoughts and perhaps other characters? (; is reserved by urlscan)
>
> I know that this is not the correct approach but it would definitely
> help.
>
> Eric
>
> [DenyUrlSequences]
> '   ; Prevent SQL injection
> ..  ; Don't allow directory traversals
> ./  ; Don't allow trailing dot on a directory name
> \   ; Don't allow backslashes in URL
> :   ; Don't allow alternate stream access
> %   ; Don't allow escaping after normalization
> &   ; Don't allow multiple CGI processes to run on a single request
>
>
> [02-11-2003 - 23:25:59] Client at x.x.x.x: URL contains sequence ''',
> which is disallowed. Request will be rejected.  Site Instance='1', Raw
> URL='/''
>
> -----Original Message-----
> From: Sverre H. Huseby [mailto:shh () thathost com]
> Sent: 11 February 2003 09:49 PM
> To: dreamwvr () dreamwvr com
> Cc: webappsec () securityfocus com
> Subject: Re: SQL Injection Basics
>
>
> [dreamwvr () dreamwvr com]
>
> |   Well IMO why not simply filter out all non alpha and integers.
> |   logging everything else and not allowing to form a SQL statement
> |   at all? Then allow very select special characters like ; only in
> |   a specific position. Just my 2 cents.
>
> Because that's not the general solution.  If you program, say, a bank
> application, you cannot simply say that nobody named O'Connor will be
> allowed to register.  If you program a discussion site for
> programmers, you cannot remove selected characters from the notes,
> because the program snippets people would like to include may
> legitimately contain some of those special characters.
>
> The problem is that input validation is _not_ about filtering for all
> possible subsystems (such as databases) to which you intend to pass
> data.  For some types of input you may put strict limitations to what
> characters are accepted.  For others you may not.  No serious customer
> in the world will accept that "we cannot allow quotes and backslashes
> in the input because the database will choke."
>
> No matter what restrictions you put on valid input, you may have to
> escape some characters before passing data along to a subsystem.  And
> that's what it's all about.
>
> The OWASP (www.owasp.org) Filters project introduces the term
> "boundary filtering" [1]: You do input validation when data passes the
> boundary/border between the client and your application.  And you do
> subsystem filtering when the data passes from your application to one
> of many possible subsystems, including the end users' browsers (to
> prevent Cross-site Scripting).  The "boundary filtering" approach is
> the most ingenious method proposed so far, IMNSHO.  And to be even
> less humble, it's the same kind of filtering I (and most likely more
> people) have preached for the last couple of years, although I failed
> to come up with that cool term.  Drats.  :)
>
>
> Sverre.
>
> 1: Until someone tells me otherwise, I give Alex Russell the credit
>    for that cool term, because I first saw it in one of his documents.