mailing list archives
Re: SQL Injection
From: "Jeff Williams" <jeff.williams () aspectsecurity com>
Date: Tue, 8 Jun 2004 17:08:56 -0400
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
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
- 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
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.
Aspect Security, Inc.
----- 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.
On Sat, 2004-06-05 at 02:17, stevenr () mastek com wrote:
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 <script> Can anyone
still do XSS or SQL Injection in that case?
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.
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.
"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.
Re: SQL Injection Jeff Williams (Jun 14)
Re: SQL Injection Stephen de Vries (Jun 17)