#03: XSS, Session fixation, and input sanitization

Holy cow, it's been a busy week.  Who would have thought moving to a new vulnerability scanner would cause all kinds of issues.  What kills me about the number of vuln scanners I've used in the past is that all of them have their own findings, and none of them find everything.  Retina, Nessus, OpenVAS, Critical Watch...  all of them detect their own little things.  Some are better at finding OWASP issues, others are better at OS-level detection.  All of them suck at detection, but then, they can only do so much.

One of the major findings was multiple XSS errors.  That was easy enough to fix, developers just had to be mobilized to fix the issues.  Santize that input!!!!

The issue is with testing.  I'm not what you might call 'savvy' with all the OWASP issues.  Cross Site Scripting, Request Forgery, Session Fixation...  I have gone from 'things I hear on a podcast' to knowing how they work to now using specific tools that allow me to test for them.

My tools of choice in the last year has been Burp Suite.  I love it. A lot...  Not only do you get a powerful tool to show exactly what internet connections are going across (if you're using the 'Interceptor'), but if you've changed the Internet Explorer proxy settings, you can modify the HTTP connections BEFORE they are shipped back to the server, or change the incoming request from the server.  Add to that Burp Suite is free, and you have a tool that you should carry with you on a flash drive.  Burp Suite runs in Java, so that is the only dependency.

I find that I get better results testing XSS with Internet Explorer, because it's easier to disable the XSS protections.  There are ways to do it in Chrome, but a radio button in IE is just easier.  Also, we test for clients and what the lowest common denominator would use, and that is still unfortunately Windows, and Internet Explorer.

I am also looking at Cookie Flags, which are another method of reducing XSS attacks.  Next week, matter of fact, I will be testing as to whether the flags have been correctly set when visiting certain websites.  You can use Burp for this, but I have found the easiest method is to find a plugin, like "Edit This Cookie" to show you the flags.

This is just an example above.  According to OWASP, Setting the "Secure" flag and the "HTTPOnly" flags tells the site what cookies will be transmitted and when.  This tells the browser to transmit a cookie when encrypted communications is required, or in the case of this cookie, whenever HTTP traffic is generated.  This means both HTTP and HTTPS.  'HTTPOnly' is not the opposite of 'Secure'.

For me to test, it's as easy as visiting the site, and clicking on the icon.  I can also set the cookie flags if I want to.  This can be good for testing web applications that set multiple cookies... you can even break a site I'd imagine.

I've only scratched the surface with Burp Suite.  One thing I did have an issue with, and believe me, it's NOT an issue. When using Chrome 29 with Burp, I found that I could not do Google searches with burp Suite on...  Chrome complains that the site SSL certificate doesn't match.  That is fantastic!  Even with the intercept set to 'Off', Chrome will not allow someone to surf Google with a fake cert.  IE isn't so kind. I'm able to do everything I need to do, even Google Searches.

There are others, like Parosproxy, but I've been happy using Burp Suite.  I may try to get our organization to buy a license. There isn't a need to, because for what I'm using it for is available on the free model. I just think that good software should get supported.  And if I can socially engineer my boss into giving them some beer money, then I've done my good deed for the day.