WebApp Sec mailing list archives
RE: SQL Injection
From: The Crocodile <tcroc () pasture com>
Date: Sat, 05 Jun 2004 09:19:59 -0400
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 <script> 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. - SteveMASTEK "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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Current thread:
- Re: SQL Injection, (continued)
- Re: SQL Injection Serg B. (Jun 01)
- Re: SQL Injection RSnake (Jun 01)
- Re: SQL Injection Paul (Jun 01)
- RE: SQL Injection Scovetta, Michael V (Jun 01)
- Re: SQL Injection David Cameron (Jun 02)
- RE: SQL Injection Imperva Application Defense Center (Jun 02)
- RE: SQL Injection stevenr (Jun 02)
- Re: SQL Injection Steven M. Christey (Jun 03)
- Re: SQL Injection The Crocodile (Jun 04)
- RE: SQL Injection stevenr (Jun 06)
- RE: SQL Injection The Crocodile (Jun 06)
- Re: SQL Injection Jeff Williams (Jun 08)
- Re: SQL Injection saphyr (Jun 09)
- RE: SQL Injection The Crocodile (Jun 06)
- Request for comments - French readers saphyr (Jun 08)
- Re: SQL Injection Serg B. (Jun 01)
- Re: SQL Injection Steven M. Christey (Jun 08)
- RE: SQL Injection Michael Howard (Jun 09)
- RE: SQL Injection or XML gcb33 (Jun 09)
- RE: SQL Injection Michael Howard (Jun 09)
- RE: SQL Injection Michael Silk (Jun 09)
- RE: SQL Injection WebAppSecurity [Technicalinfo.net] (Jun 10)
- RE: SQL Injection stevenr (Jun 09)