WebApp Sec mailing list archives
RE: SQL Injection or XML
From: gcb33 () dial pipex com
Date: Wed, 9 Jun 2004 12:38:34 +0100
Hi, My quick suggestion or experience Most vendors that I used are now not sucseptable to SQL injection even if their is no filtering or character injection in any form, they do use XML schemas to talk from web server aspx pages to the app server we also use XML to the back-end or middleware systems for on-line enquires for cash or account balance as in a internet banking application With experiense I have found that when you have multi-lingual web site especially if it uses non european characters they would hard code the values to reject on , not ideal but then better than nothing non the less. so reject on if allowed it is harder to setup but more secure. as in this case mentioned next I found one case is if you have a mixture of vendor products that a certain characters that are not exploitable would appear not to work will effect another like a this setup web server and app server is Micrsoft with a database is either DB2 or Oracle that the high order ANSI code 145 or 146 would be treated the sames as ' so even if you think that you have blocked the normal ASCII ; or ' characters would still be susceptable to SQL injection A key question or point for design of security components if when the component or components fails under extreme conditions how is the application going to handle this condition , as in pre-production or UAT enviroments you cannot simulate 100,000 users logged into at once with multiple calls to systems async logical required components do fail in productions for no apparent resone and would giver eranous errors or could allow for certain validation sequences to fail. And the other two security areas i have seen which is always over looked is session management of the site... with clustered enviroments always without a doubt will work given enough time on nearly 60-70% of vendors products in the wild. SQL injections is mostly resolved for enterprise products but now with XML with the new 'XML injection' as i call is the next thing and found it on one vendor product due to the order of the validation componets before calling the XML listerner middle of last year Their are excellent materials writtern by microsoft press the blue books on pattern matching and application design plus the black book on security programming that has been mentioned that as been invaluable in re-writtern are applications allowing the developersand system architect to design to a very granually componets for security. We are also using 'Biztalk product' to allow for easy B2B messaging translations on the XML schema for dual direction messaging formats. so SQL yes needs to be addressed but also XML as most systems are now been designed for XML messaging to core banking middle-ware or hosting systems with straight through processing so the SQL is a risk but XML is more damaging if it succeeds. James Security Developer or Consultant and Pentester for Banks ;o) Quoting Michael Howard <mikehow () microsoft com>:
The list, while useful, is very US-centric. You may want to point that out in the XML schema - perhaps have a country code attribute or something! I often look at RegExLib for ideas - including non-US constructs: http://www.regxlib.com/Search.aspx [Writing Secure Code 2nd Edition] http://www.microsoft.com/mspress/books/5957.asp [Protect Your PC] http://www.microsoft.com/protect [Blog] http://blogs.msdn.com/michael_howard [Annual Security Training] http://mste/training/offerings.asp?offeringid=7142 -----Original Message----- From: Jeff Williams [mailto:jeff.williams () aspectsecurity com] Sent: Sunday, June 06, 2004 9:19 PM To: tcroc () pasture com; stevenr () mastek com Cc: coley () mitre org; 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 InjectionBlindly 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 hasbeenoversimplified 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 asputforth by Crocodile. Its about creating rules about what characterscanbe allowed and rejecting (or encoding) the rest. Another approachwhichI think may help (as mentioned by Crocodile) is blindly encoding alltheinput and then saving it in the db (or showing it on the page). Thismaynot always be right, specially if there are other tools/systemswhichread the data but are unable to decode it back to original form. BTW, any opinions on if I just encode all input without checking foranycharacters? 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 particularinputparameter 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 mightallow1234567890()- and that's it. White listing the particular inputfield toallow only those characters (and escape them if neccesary) shouldstopboth XSS and SQL injection attack characters. Encoding the output presented to the user is an additional step that can be done todoublecheck for display type attacks (again XSS). Maybe I misunderstood your post, but I just wanted to make surethesesubtle differences were clear to the list. Cheers, --The Crocodile And yes I know "whitelisting" won't catch input data that is validthatadditional 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 onlydefinedcharacters and rejecting everything else. Saves you headaches inthelong run. Use Regexs for this.While white lists are far better than black lists, the correct"whitelist" will vary depending on which type of vulnerability you are protecting against. For example, restricting inputs toalphanumeric,spaces, and hyphens will still open you up to certain argument injection vulnerabilities. So, you may need to apply differentwhitelists to the data, depending on where (and how) the data is being used, and which types of vulnerabilities may be present at thatpoint.You may want to use a "SQL injection" white list on data input,withan "XSS white list" on data output (though "XSS white list" isalmostan 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 andnot 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 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 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)
- RE: SQL Injection Michael Silk (Jun 09)
- RE: SQL Injection V. Poddubniy (Jun 10)
- encryption over the web OPTUSBYS (Jun 14)
- Re: encryption over the web Sam (Jun 14)
- Re: encryption over the web Keith W. McCammon (Jun 14)
- Re: encryption over the web Ivan Krstic (Jun 14)
- encryption over the web OPTUSBYS (Jun 14)