Top Five Web Application Security Blogs

Today, I thought I would post great resources for information. If you want to be good at security, it means you need to be well read.

Here are the top five web application security blogs in no particular order.

• Jeremiah Grossman - Probably the most read web application security blogger. Jeremiah reads all of the material so you don't have too.
  
• Rsnake / Robert Hansen - The other most read web application security blogger. Interesting Note: Graduated my alma mater.
  
• Holistic InfoSec - Russ McRee's blog. Russ puts people on the stove. He posts are controversial and exciting. According to ISS, Russ was one of the Top Vulnerability Discoverers in 2008. Keep an eye on him, it is interesting to see what he will do next.
• Billy Rios - Also known as the XS-Sniper! Billy is behind some of the most innovative research as of late. He is the man behind Gifars and URI overflows. He is also known to smuggle olives on occasion.
• Nitesh Dhanjani - Although he covers a wide range of topics outside of web application security, Nitesh continually blogs about topics that are thought-provoking.

An XSS Primer - Understanding Cross Site Scripting

If it hasn't already, Cross-Site Scripting (XSS) will soon be replacing SQL injection as the new buzzword in the security sector.

XSS will continually be a topic on this blog as well as others [1],[2],[3],[4]. Due to this fact, I think a primer would be a good idea for those who don't know or understand this problem.

Many articles have been written about Cross-Site Scripting and if you want to have a better understanding of the problem, I suggest you read those documents (Links at the bottom of the post).

Basically, There are 3 types of Cross-Site Scripting:

1. Stored/Non-Reflective/Persistent Cross Site Scripting (User visits the XSS'ed page)
   
2. Non-Stored/Reflective/Reflected Cross Sited Scripting (User clicks a link that embeds the script into the loaded page)
   
3. DOM Based Cross Site Scripting (please read this article)
   

All of these names make it confusing for a first timer to understand XSS. There really should be a better web application security standards organization. Here is a breakdown of Persistent XSS and Reflective XSS. These are the big two that most people talk about when they are referring to Cross Site Scripting. If you understand these well, you will be able to participate in 90% of XSS conversations.

Persistent Cross-Site Scripting
Persistent XSS is arguablly more dangerous than reflective XSS. This attack embeds the malicious script permenatly into the web application. The script will then wait until people access the page it is located on.

Here is an attack using Persistent Cross-Site Scripting:

1. The victim visits a website they trust, amazon.com.
2. A script has been inserted by an attacker on a page they happen to visit while on amazon.com.
   
3. The script executes in the context of amazon.com.
4. The victim is then compromised.
   

Note: Obviously, someone can increase the chances of the victim visiting this page (step 2) through social engineering, phishing, etc.

Reflective Cross-Site Scripting
These are the ones the media usually reports on. [1],[2],[3]. In this attack, some type of social engineering is involved for the attack to be successful.

Here is an attack, using Reflective Cross-Site Scripting:

1. The victim gets an email/Instant Message that contains a link.
2. The victim clicks the link. (Requires User Intervention)
   
3. A script has been inserted by an attacker on the page they then visit.
   
4. The script executes in the context of that site.
   
5. The victim is then compromised.
   

Note: I want to reitterate that this attack requires some type of user intervention (step 2).

Why is Cross-Site Scripting Bad?
Cross-Site Scripting can lead to all sorts of different exploits, including system compromise. For an attacker to do this, they need to break out of the browser's context. We have seen examples that breaking out of the browser is not that hard to do.

In addition, an attacker can also establish a bi-directional channel using iframes. This creates a man-in-the-middle attack. The attacker can then intercept key strokes, use the victim as an intranet portscanner, and even stealing creditials. The attacker is only limited by their knowledge of scripting.

Example of a bi-directional channel

Hopefully, this gives you a better understanding of Cross-Site Scripting. Feel free to leave comments if you don't understand something and I will address it in the article.

Additional Resources:
Cross-Site Scripting (XSS) FAQ
OWASP Guide to XSS
XSS tutorial
XSS Video Tutorial (via youtube)
XSS Attack API

Rsnake's Bullet Metric: A Response

A thought experiment asking the following: "If you put Anti-virus on every desktop in the world, would you stop viruses from existing?"

It seems that a critical assumption that is made is faulty. Early in the post, Rsnake answers the above question stating, "I think any reasonable person who understands how viruses work would say no. It will, however, make the bad guys work harder and iterate faster to get by the filters (boutique malware)."

But would virus developers continue to develop? At some point all attackers, and computer scientists, are generally lazy. Attackers want to follow the path of least resistance. If every desktop in the world had Anti-virus installed, would the attackers actually want to "work harder and iterate faster?"

linkage: Silver Bullet Metric ha.ckers.org web application security lab