RE: SQL Injection

["Clement Dupuis" <cdupuis () cccure org>]

It seems that Jeff Attachment got stripped by the mailing list.

You can download his fantastic regex file as .XML or as a .zip file at:

http://www.professionalsecuritytesters.org/modules.php?name=News&file=articl
e&sid=110   

Clement


> -----Original Message-----
> From: Jeff Williams [mailto:jeff.williams () aspectsecurity com]
> Sent: Tuesday, June 08, 2004 5:09 PM
> To: webappsec () securityfocus com
> Subject: Re: SQL Injection
>
> Here's a little list of regex's that I put together for an article about
> how
> to build an HTTP Request Validation Engine (see
> http://www.aspectsecurity.com/stinger). If anyone knows of a more complete
> list with some better documentation, I think it could be pretty helpful
> for
> folks.
>
> Architecturally, I think there's a strong case for a centralized
> validation
> engine, as opposed to putting a regex in front of every place you use
> something from the HTTP request.
>
> Here's a few quick questions to see if you're really validating well:
>  - Is your validation scheme mandatory (developer doesn't have to remember
> to do it)
>  - Do you canonicalize before validating?
>  - Are you validating URL params, cookies, and other headers -- or just
> forms?
>  - Do you catch extra, missing, and duplicate parameters, headers, etc...?
>  - If you detect a problem, what are your options (ignore, sanitize,
> continue, fatal, log, notify)?
>  - Can you detect an attack based on repeated failed input validation?
>  - Is what you log different than what you show the user?
>
> Wait -- here are the best ones:
>  - Do your requirements specify all the stuff above?
>  - Do your requirements or detailed design docs specify all the validation
> rules?
>
> Input validation shouldn't just be left to 'best practice' or whatever
> individual developers want to do.  It takes some real design thinking to
> get
> it right for an enterprise application.
>
> --Jeff
>
> Jeff Williams
> Aspect Security, Inc.
> http://www.aspectsecurity.com
>
> ----- Original Message -----
> From: "The Crocodile" <tcroc () pasture com>
> To: <stevenr () mastek com>
> Cc: <coley () mitre org>; <webappsec () securityfocus com>
> Sent: Saturday, June 05, 2004 9:19 AM
> Subject: RE: SQL Injection
>
>
> > Blindly encoding characters may still cause errors and issues if that
> > input is utilized prior to encoding, or if the input in encoded form
> > contains characters that will cause errors. You should always validate
> > the input regardless and then encode the output prior to presenting it
> > back to the end user.
> >
> > A better question is are there any publically available "whitelist"
> > based libraries that are easy to use for input validation? In what
> > langauages are these libraries available? Is there a compiled list of
> > these libraries somewhere that I am unaware of?
> >
> > It would be great to have an extensible regex style whitelist library
> > available where a simple function(s) can be called with the line of
> > input and the whitelist regex and a 1 or 0 are returned. (This has been
> > oversimplified for the sake of the post).
> >
> > I did a brief google search "input validation library", but didn't see
> > anything at first glance.
> >
> > Comments welcome.
> >
> > Cheers,
> >
> > --The Crocodile
> >
> > On Sat, 2004-06-05 at 02:17, stevenr () mastek com wrote:
> > > Hi
> > >
> > > When I had mentioned whitelists in my post, I meant whitelists as put
> > > forth by Crocodile. Its about creating rules about what characters can
> > > be allowed and rejecting (or encoding) the rest. Another approach
> which
> > > I think may help (as mentioned by Crocodile) is blindly encoding all
> the
> > > input and then saving it in the db (or showing it on the page). This
> may
> > > not always be right, specially if there are other tools/systems which
> > > read the data but are unable to decode it back to original form.
> > >
> > > BTW, any opinions on if I just encode all input without checking for
> any
> > > characters? Say converting all <script> to &lt;script&gt; Can anyone
> > > still do XSS or SQL Injection in that case?
> > >
> > >
> > > Regards,
> > > Steven Rebello
> > >
> > >
> > > -----Original Message-----
> > > From: The Crocodile [mailto:tcroc () pasture com]
> > > Sent: Friday, June 04, 2004 5:55 PM
> > > To: Steven M. Christey
> > > Cc: webappsec () securityfocus com
> > > Subject: Re: SQL Injection
> > >
> > > I think I'm confused about your use of the term "whitelist" in the
> > > scenario below. White lists IMHO aren't going to be vulnerability
> > > specific at all. They are going to be specific to the particular input
> > > parameter in question. I don't see how you would have differing
> > > "whitelists" for XSS and for SQL Injection.
> > >
> > > A white list is specifically what is going to be allowed for a
> > > particular parameter. For example a phone number in the US might allow
> > > 1234567890()- and that's it. White listing the particular input field
> to
> > > allow only those characters (and escape them if neccesary) should stop
> > > both XSS and SQL injection attack characters. Encoding the output
> > > presented to the user is an additional step that can be done to double
> > > check for display type attacks (again XSS).
> > >
> > > Maybe I misunderstood your post, but I just wanted to make sure these
> > > subtle differences were clear to the list.
> > >
> > > Cheers,
> > >
> > > --The Crocodile
> > >
> > > And yes I know "whitelisting" won't catch input data that is valid
> that
> > > additional business logic should be catching. IE. Access control
> > > violations. That is a different thread all together.
> > >
> > > On Thu, 2004-06-03 at 20:35, Steven M. Christey wrote:
> > > > > The best way would be creating a white list, allowing only defined
> > > > > characters and rejecting everything else. Saves you headaches in
> the
> > > > > long run. Use Regexs for this.
> > > >
> > > > While white lists are far better than black lists, the correct
> "white
> > > > list" will vary depending on which type of vulnerability you are
> > > > protecting against.  For example, restricting inputs to
> alphanumeric,
> > > > spaces, and hyphens will still open you up to certain argument
> > > > injection vulnerabilities.  So, you may need to apply different
> white
> > > > lists to the data, depending on where (and how) the data is being
> > > > used, and which types of vulnerabilities may be present at that
> point.
> > > > You may want to use a "SQL injection" white list on data input, with
> > > > an "XSS white list" on data output (though "XSS white list" is
> almost
> > > > an oxymoron these days, with all the custom browser behaviors).
> > > >
> > > > It would be interesting to know if anybody's tried to implement
> > > > "context-sensitive taint checks" that know which filters have been
> > > > applied to data elements, and when.
> > > >
> > > > - Steve
> > >
> > >
> > >
> > >
> > > MASTEK
> > > "Making a valuable difference"
> > > Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
> > > In the US, we're called MAJESCO
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Opinions expressed in this e-mail are those of the individual and not
> that of Mastek Limited, unless specifically indicated to that effect.
> Mastek
> Limited does not accept any responsibility or liability for it. This e-
> mail
> and attachments (if any) transmitted with it are confidential and/or
> privileged and solely for the use of the intended person or entity to
> which
> it is addressed. Any review, re-transmission, dissemination or other use
> of
> or taking of any action in reliance upon this information by persons or
> entities other than the intended recipient is prohibited. This e-mail and
> its attachments have been scanned for the presence of computer viruses. It
> is the responsibility of the recipient to run the virus check on e-mails
> and
> attachments before opening them. If you have received this e-mail in
> error,
> kindly delete this e-mail from all computers.
> > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >