OWASP (www.owasp.org) just released the final version of their Top Ten Risks for 2010 document. For those of you that have seen my talks on web app security, I was working off the Release Candidate so you will want to read up on this final version.
http://www.owasp.org/index.php/Top_10
Tuesday, April 20, 2010
Friday, April 16, 2010
CSRF Big Deal or Not?
Great blog post about CSRF and whether it is a big deal or not.
http://ha.ckers.org/blog/20100414/csrf-isnt-a-big-deal-duh/
You have to read this and then read all the comments. Great feedback plus back and forth by folks in the field. The important thing is to keep this topic and others in our minds, and share the knowledge with other developers. Only you can prevent forest fires...wait, I mean, web attacks.
http://ha.ckers.org/blog/20100414/csrf-isnt-a-big-deal-duh/
You have to read this and then read all the comments. Great feedback plus back and forth by folks in the field. The important thing is to keep this topic and others in our minds, and share the knowledge with other developers. Only you can prevent forest fires...wait, I mean, web attacks.
Wednesday, April 7, 2010
New category of XSS attack -- so what?
In DarkReading (http://www.darkreading.com/vulnerability_management/security/app-security/showArticle.jhtml?articleID=224201569) there is a current article about a new type of XSS attack that exploits services that provide networking data, where malicious data is stored in TXT records or other back-end things and are then returned by a service where it is executed on network admin screens.
Uh...this is no different than any other XSS attack. Sure, new category. Sure, really tough to find. But hellooooo? You have input from an untrusted source (data file) that you are taking and displaying to a screen. Service developer, scrub your output! Network app screen developer, encode your output! Duh!!! Come on people. This just shows that we need to be aware that hackers are going to a deeper and deeper level in our systems. As we patch our brochureware sites, they are going to the network folks that don't care to be security developers. But we have the responsibility to do it right.
And it is easy. Please encode and stop XSS!
Uh...this is no different than any other XSS attack. Sure, new category. Sure, really tough to find. But hellooooo? You have input from an untrusted source (data file) that you are taking and displaying to a screen. Service developer, scrub your output! Network app screen developer, encode your output! Duh!!! Come on people. This just shows that we need to be aware that hackers are going to a deeper and deeper level in our systems. As we patch our brochureware sites, they are going to the network folks that don't care to be security developers. But we have the responsibility to do it right.
And it is easy. Please encode and stop XSS!
Sunday, March 28, 2010
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".
- Do you build web sites/apps, web services, or windows apps that use a browser control?
- Do you know what SQL Injection is?
- Do you know how it works?
- Do you actively code against SQL Injection attacks?
- Do you know what XSS is?
- Do you know how it works?
- 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?
Many times reflected XSS is used to grab your cookies so they can impersonate you, but obviously it can be for other things too.
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.
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).
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.
Subscribe to:
Posts (Atom)