Interesting (No) Show of Hands

Yesterday I spoke at CodeCamp 13 in Waltham, MA about web app security. Two talks, one for XSS and SQL Injection, the other for CSRF and discussion about the rest of the OWASP Top 10 list. During the first session I asked a set of questions to see first-hand whether what I had suspected was true. People were to raise their hand if the first question was a "yes" answer and leave it up until they answered "no" to a question.

Here is the set of questions, in order. Note the spot where you can't answer a question with a "Yes".

1. Do you build web sites/apps, web services, or windows apps that use a browser control?
   
   
2. Do you know what SQL Injection is?
3. Do you know how it works?
4. Do you actively code against SQL Injection attacks?
   
   
5. Do you know what XSS is?
6. Do you know how it works?
7. Do you actively code against XSS attacks?

Did you answer "yes" to all seven questions? I had 26 people in the talk and almost all raised their hand for the first question, which makes sense. After all seven questions, not a single hand was left up. There were 3 or 4 people who made it through six of the seven questions, but no one actively codes against those attacks.

THOSE ATTACKS ARE THE TOP TWO OUT IN THE WILD AND EXPECTED TO BE A RISK FOR 2010!

Think about this for a second. This was at a CodeCamp, where real developers go. There were hundreds of developers that didn't attend the event. There were 26 people in the room with me, so those are those most interested in security. There were dozens and dozens attending other sessions at the event at the same time, missing my talks by choice. So the most likely people to be good at protecting their sites are not actively protecting their sites against the top two attacks. Granted some gurus there likely didn't attend my talks since they already do all the work and didn't need them, but this is a clear statement to me about what is not happening in the development community.

Do I blame those folks that attended my session(s)? No way. They had great questions, were honestly concerned, and I know they left with a desire to turn things around. They were a great bunch for sure. But I hope it showed them, as it did me, that this is the norm. There is a lot of work left to be done to educate people on secure web app development. Hopefully the army is a little bigger after yesterday.

Reflected vs Persistent XSS

Most of us by now know what XSS is, how it works and how to stop it. But you may be hearing a bit more now about "reflected XSS" or "persistent XSS". What are they and how are they different, and most of all does it matter?

Reflected XSS

Reflected XSS is when the attacker sends along a link to a vulnerable page with a script in it and victims run the page as the attacker wants it set up. For example, think of search engine pages. If the attacker puts something in the search text so that search results are compromised, he/she can send you a link to that exact page. When you click on the link to that page YOU get the compromised search results and the attacker has you right where they want you...script running on your browser automatically.

Many times reflected XSS is used to grab your cookies so they can impersonate you, but obviously it can be for other things too.

Persistent XSS

This is where a site has malicious code on it, either on purpose or via user input. The victim may be going to a legitimate page with a malicious post (think discussion forum on legit site), or a malicious page whose intent is to attack you or others using your browser.

On thing malicious XSS sites are doing these days with persistent XSS is to infect your machine with malware. They accomplish this by telling you that you need to download a codec to view a file on their site. You accept the download and get the malware.

Thoughts

Something we can agree on is that we can all avoid going to malicious sites for the most part. We just stick to nice neighborhoods and avoid the skeevy ones. But malicious posts on trusted sites are hard to avoid. Consider StackOverflow.com. You go there to solve a tech problem and you hit a post with 15 replies. You get all 15 replies, like it or not. Those posts may have images that are pulled, etc. Before you go to the page, do you know if the page has a malicious script on it? You open the page and BOOM, everything runs...ain't a thing you can do about it either. (Don't worry, StackOverflow does not have this vulnerability, but do you know if other sites you hit are not vulnerable?)

Using something like the NoScript FireFox plugin is a smart thing. It blocks scripts until you allow them for a page or site. So the one bad post out of 15 will have its malicious script blocked unless you say it is ok to go to http://malicious_site.com and pull their script (in that case shame on you).

Final Thought

So now you know reflected and persistent XSS attacks. Do their differences matter? Maybe, but only from you being a USER so you know what to look for or watch out for. IM's, email links, links on pages, etc. Being a web dev, it doesn't matter at all. Stop allowing XSS on your sites, period. You block them the same way. Stop making excuses and get your site plugged, which stops all XSS attacks cold.

About eBay Vulnerabilities

So mid-February it was announced that eBay had some exploitable parts. Not cool! Guess what they involved? One had cross-site scripting (XSS) and another had SQL Injection. A third, that may still be unpatched, is a cross-site request forgery (CSRF) hole. Huh. Surprise surprise! These are the top holes, and have been railed about for years, literally. And here is another example of a big company with lots of developers with those old holes in place. Granted CSRF is tricky and sorta new, at least newly being exploited. But XSS and SQL Injection? Wow. The holes were in rather non-standard pages, but doesn't the mini basement window at the back of your house still get you in, where you can unlock the front door from the inside?

No more excuses! Patch those holes BEFORE you become a news headline! Oh, speaking of which: http://www.esecurityplanet.com/headlines/article.php/3866011/eBay-Vulnerabilities-Found.htm

Here is a good paper on what the top holes are and how to fix 'em: http://www.owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf. And in the coming weeks I'll give a full explanation of SQL Injection and CSRF to help you if you need it.