SQL Injection: Sleeping Giant
Michael Sutton from Spidynamics did some very cool research titled, “How Prevalent are XSS Vulnerabilities” and a follow up article titled, “How Prevalent are SQL Injection Vulnerabilities“.
His results were as follows:
- XSS: 17.3%
- SQL Injection: 14%
You will immediately notice that the two figures are not far off from each other. Why is this? May I offer a suggestion: both these problems occur due to a lack of input validation; therefore, would it not makes sense that both security risks are like husband and wife, joined together.
It has been fascinating for me to watch the webappsec community scurrying around XSS. Agreeing with Michael Sutton’s point on SQL Injection being the worst of the two, it is ironic that SQL Injection has not received the attention it deserves when compared with the opposing XSS risk.
The question then is why not? I could write an essay on this but I am going to simply say, because XSS is the easier road :) I think XSS is the new script kiddie attack. Its easy, simple and powerful. I mean look at the new Google XSS Watchfire released. Nice find, but like most of these vulnerabilities it could be exploited by a 5 year old.
Alot more work needs to be done in this area. As a start I have been trying out different opensource SQL Injection tools in an attempt to categorise their strengths, weaknesses and limitations. I hope to publish this results shortly. Also, after bouncing some emails off Jungsonn yesterday I will be merging his SQL Injection Cheat Sheet with Michaeldaw SQL Injection Cheat Sheet - look out for alot more work here, lets get this party pumping.
I don’t quite agree. XSS can be as complicated as SQL Injection and sometimes even more. Both types of vulnerabilities are easy to find. However, both of them require some expertise to exploit them.
I don’t agree with your analysis of why XSS gets more attention. I don’t think its because its so easy to exploit, I think its because there are many more interesting things to do, and because there is so much more to discover.
With SQL, barring encoding issues, you either escape things or you don’t.
With XSS, we are generally more interested in filter evasion, rather than finding a website which echoes our html right back. There is no such thing as an SQL Injection filter which allows users to enter some SQL commands, but tries to stop them executing others.
Furthermore with SQL it is perfectly clear where things need to be escaped, with XSS, even that is not a certainty, especially if you consider the FindMimeFromData issues in IE.
And besides hashing data, etc, there is not much you can do in terms of defence in depth, whereas to prevent XSS you can.
I’d agree with David that won’t take too long to find a XSS vulnerability. The low-hanging fruit here is to look for something that will echo back what you put in. All you need is some HTML knowledge. Release it to bugtraq (usually without telling the script author) and job done. Filtering evasion… That’s part of the challenge. There is a limited set of characters that you want to check to see if it is filter properly or not? (e.g. tags, quotes, apostrophes…)
SQL Injection is not so easy. Generally, you do need to know some SQL before you can start SQL injection and I think that’s the point Dave is trying to make. There’s a lot more attack vectors, you can try once you can put your foot in the door with some blind SQL injection. e.g. attempting to access system tables, selecting data from a table, escalate privileges if possible. That sounds a bit more interesting…