WebApp Sec mailing list archives
RE: ISA Server and SQL Injection
From: "Mark Curphey" <mark () curphey com>
Date: Mon, 21 Feb 2005 12:06:54 -0800
I have sat back for the last 12 months and watched threads like this fly past my head. After this mail I will do the same but I somehow feel compelled to respond and get a few things of my chest. I am not trying to be controversial or confrontational, just offer a balanced approach to the debate. These are my personal opinions and "yes" I already know that more than enough product vendors already don't like me for being very vocal about my opinions on these things. Quite frankly I don't care. Freedom of speech baby, I just say it like it is and I am not sorry if that halters your ability to sell cotton candy and moon dust. 1. Automation (both protection and detection) 2. Thinly disguised marketing posts in public lists 1. Automation Firstly I 100% agree on the desire to automate as much security testing and protection as is possible; that much is undisputed. Before we look at the automation of both assessment and protection lets first scope the extent of the software security problem. Many of the issues brandished around in marketing and the press seem to intimate that data validation is the extent of the software security problem (in fact it's a lot worse than that with most people only considering input validation). While these attacks that exploit insufficient or inappropriate data validation are of course way too prevalent there is a distinct bias in the media and on lists like bugtraq. You have to be pretty damn silly to build an app in ASP.NET and have a SQL injection issue these days (even my level of development which is pretty basic its hard to slip up). The bias comes in when you look at the amount of php based software that is written by very inexperienced developers appearing in advisories. The low cost of entry (while admirable) inevitably will lead to more issues in software created in the big picture. This software however generally (note generally not exclusively) tends to have very limited deployment and is not representative of what is found in the commercial world. At Foundstone we have tested literally thousands of apps and the most frequent and most insidious issues are rarely data validation issues these days. They were a few years back but not today. They are issues with authorization systems, user management systems, business logic, data protection in (storage and transport), broken protocols, badly implemented cryptography and such like. The bar has been raised. So if we are interested in systems to help test and protect bespoke software we should first consider the scope of the issues. This is a key point. Software security problem does not equal input validation. Protection systems or web app firewalls. These tend to be some sort of intelligent proxy that intercepts the data steam and applies a set of rules (sig based or heuritics). These tools are only good for data validation IMHO. They have no hope whatsoever to protect a web application where say switching a name value pair gives you another persons account. They have no hope in detected poorly implemented cryptographic algorithms or key management systems. They are dealing with a very very limited scope of the problem. Not only that but IMHO they are architecturally in the wrong place. There are many options for data validation. In order from left to right you can do it in the code, in a framework (STRUTS), at the web server (ISAPI, NSAPI) or on the network (web app ids). The further away from the code the less control you have over the validation. This is common sense. Validation is about context. You can't simply say don't let a ' hit the app. What about poor Rosie O'Grady. You have to build context based validation to be effective. The closer you are to the code the more control, more precision and more flexibility you have. The further way you are the less control, less precision and less flexibility you have. The closer to the code the better, the further away the worst off you are. We have driven trucks past every major web app firewall I know about. When I see marketing from the likes of Imperva stating they defend against the OWASP top ten I just ROFL. Poor use of crypto. Its just total hog wash. Repeat we have driven trucks past every major web app firewall I know about. I can write a simple app with a catastrophic vulnerability (total control of the system) that you can not protect against with a data stream analysis approach. That in itself is why I would never buy one and never recommend to others they do either. It's a hyped market. As a SMALL part of a layered approach there is obviously value. A few people keep asking me where I think validation should be done. I always say in the code. The argument sometimes comes back that that's not always possible. While I completely disagree (every commercial company I have worked for has a release cycle of every few weeks and consistently changes the code base so either I have been living under a rock in major financial services companies or the vendors marketing thought they had a good sales angle) I challenged some of my guys at Foundstone to offer an alternative to code based validation. On March 8th we will release the Foundstone .NET Security Toolkit for free (with source under an Apache license) with two tools. This is a "proof of concept toolkit" to prove other approaches and ideas. Think of it as the D in R&D. One tool is Validator.NET that uses the reflection API in .NET to systematically determine some inputs to a web application and build a rule set in XML. You can then load this into an HTTP module (also in the toolkit). No source needed and free. Also the a few steps closer to the code than the http proxy based web app firewall! We think we can do the same for Java as well. The same is true of automated testing, especially pen testing. I personally firmly believe that the most cost effective and efficient way to test software is to use the code. To say that code review is too expensive is misleading and outright wrong. It's a common misconception perpetuated by the uneducated. I wrote an article about it at www.softwaremag.com. Pen testing web apps is a Turing problem, the number of inputs has to equal the number of outputs and that's computationally unfeasible in a modern app. For low hanging fruit its great but for the type of issues being found now the bar has been raised I don't think its appropriate. Again at work we have driven trucks past app that have been given a clean bill of health by the scanners. And that's pretty frequent not an edge case BTW. If you look at code analysis tools as well they are getting good at finding bugs like overflows but flaws like people using poor PRNG or storing keys in config files they are next to hopeless. Guess what, flaws are the most insidious type of issue we find. Its not that these tools are of no value. We use automated tools for code review and will likely buy or build something for web app pen tests this year. For the LHF it's a no brainer. The point is any automated solution is a subset of the problem space. At the moment I would say its less than 25% for the web app firewall space and about 20% for the pen test space (gut feeling). We will also be releasing Hacme Books (think Hacme Bank but a full Java version that looks like Amazon (properly architected)) on March 8th which shows similar results if you scan it with a scanner. And today I don't even want to get started about automated tools helping with compliance like GLBA and HIPPA. That's so laughable its not worth the electrons. Dreamt up in marketing land. Which leads me neatly onto; 2. Thinly disguised marketing posts This is just a mater of taste but I have become so skeptical of articles ad posts on mailing list now. "I think x and BTW I happen to make a product that does exactly this". The worse are the ones that say "BTW only we have a solution that does this". I have seen articles in the likes of eWeek that are just pure product pitches. I have also had articles rejected from the trade press as it would have "not been good to keep the advertisers happy". Buyer beware! Not all you read is true. -----Original Message----- From: Ofer Shezaf [mailto:ofer () shezaf com] Sent: Saturday, February 19, 2005 3:50 PM To: webappsec () securityfocus com Subject: RE: ISA Server and SQL Injection Unfortunately there are no blacks and whites, and answers are usually somewhere in the middle. I agree with Matthieu that in many cases programmers are not good enough, patches for internally developed software are non-existing and code review is too expensive to be done for every line of code. On the other hand automated application security is not easy either. Most signature based systems will have hard time blocking SQL injections and other application layer attacks. While 'select' is way to prone to produce false positives (read: block legal users), '1=1' is much two weak as it is just an example: any '1=1' expression can be replaces by '2>1' and hundred others. And on the other hand application firewalls which employ a white list mechanism that allow only specified input are difficult to implement in a manner which is secure enough. This does not mean any of the solutions is bad; it is just that, like everything in security (and in life?) none is perfect. In my opinion Patching, code review and security testing should always be done, but a real time application security solution is also an important option. I also think that these systems are getting better and are starting to evolve from either simple signature based or white list based systems to more effective hybrid systems. Ofer Shezaf CTO, Breach Security Tel: +972.9.956.0036 ext.212 Cell: +972.54.443.1119 ofers () breach com http://www.breach.com
-----Original Message----- From: Matthieu Estrade [mailto:mestrade () apache org] Sent: Friday, February 18, 2005 1:17 PM To: webappsec () securityfocus com Subject: Re: ISA Server and SQL Injection Sebastien Deleersnyder wrote:-----Original Message----- From: Matthieu Estrade [mailto:mestrade () apache org] Sent: donderdag 17 februari 2005 14:58 To: webappsec () securityfocus com Subject: Re: ISA Server and SQL Injection Yes sure, if you code application using in parameter some SQL query,you should read "howto do secure code forwebapp".... Application mainly use value after used by the application inside aquery, but the query is in the code.http://www.toto.com/test.php?product_id=4 is ok and there is NO WAY tosee here some SQL Syntax. Be aware that the above parameter can directly be used to build up the SQL query such as SQLParam= "SELECT * FROM products WHERE productid = " & getParam("ProductId") This poses a danger when the 4 is replaced by "4 and 1=1" => gives back all the rows of the product table. You can imagine disaster scenario's with e.g. patient health data that is displayed. Also this will allow an attacker to provoke errors and from the errormessages deduct the table(s) structure, etc ... One of the best ways to prevent SQL injection is to build parameterized queries that will limit the variable data types used!I agree, but if the web app fw see a "AND" + "1=1", he should block. AND is a part of SQL Syntax.http://www.toto.com/test.php?product_id=SELECT%20*%20FROM%20product%20WHERE%20id=4 is not ok, and you shoud fire developper doing this.... Using parameters values doing directly actions is "HACKER FRIENDLY!"This is indeed not a good idea! But instead of firing, the developper should get educated.sorry yes, but i am not sure many developpers do this nowadays, so nobody will be fired. It was more to say that seeing an SQL query into a safe request is really rare so it can be protected by a webappfw blocking on SQL Syntax pattern matching.--- infosecurity.be --- Bezoek ons tijdens Infosecurity.be 2005 op 23 of 24 maart in BrusselsKart Expo.Registreer vooraf en ontvang uw gratis toegangskaart via: http://www.databadge.net/isbe2005/reg/?link=4dd995bba9ac221908f3 Voor meer info: http://www.ascure.com/default.asp?type=Eventsdetail&id={4D6980F0-651A-419A-93AF-E9EB42F74651}&lang={00000000-0000-0000-0001-000000000001}
Current thread:
- Re: ISA Server and SQL Injection, (continued)
- Re: ISA Server and SQL Injection fantomas (Feb 28)
- RE: ISA Server and SQL Injection Hofmeyr, Michael (ZA - Johannesburg) (Feb 15)
- Re: ISA Server and SQL Injection Darren Bounds (Feb 16)
- RE: ISA Server and SQL Injection charles freeman (Feb 16)
- RE: ISA Server and SQL Injection Roberto GABERGI (Feb 17)
- RE: ISA Server and SQL Injection Jeff Robertson (Feb 17)
- Re: ISA Server and SQL Injection Matthieu Estrade (Feb 17)
- RE: ISA Server and SQL Injection Sebastien Deleersnyder (Feb 19)
- Re: ISA Server and SQL Injection Matthieu Estrade (Feb 19)
- RE: ISA Server and SQL Injection Ofer Shezaf (Feb 21)
- RE: ISA Server and SQL Injection Mark Curphey (Feb 21)
- Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeremiah Grossman (Feb 23)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] David (Feb 23)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeremiah Grossman (Feb 28)
- storing SSNs, CCNs, password in the DB Francesco (Feb 28)
- Re: storing SSNs, CCNs, password in the DB Adam Shostack (Feb 28)
- Re: storing SSNs, CCNs, password in the DB Francesco (Feb 28)
- Re: storing SSNs, CCNs, password in the DB Andrew van der Stock (Mar 01)
- Re: storing SSNs, CCNs, password in the DB Paul Johnston (Mar 01)
- Re: storing SSNs, CCNs, password in the DB Joseph Miller (Mar 01)
- Re: ISA Server and SQL Injection Matthieu Estrade (Feb 19)
- Re: storing SSNs, CCNs, password in the DB Alvin Oga (Mar 01)