SQL Injection - Primer

SQL Injection is a security vulnerability where a web application allows a user to send un-sanitized input into a SQL query.

The textbook example is that a web application has a username field that inserts the user's input into the following SQL query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

The user then types a' or '1'='1 into the username field. This creates the following SQL statement:

SELECT * FROM users WHERE name = 'a' or '1'='1'

If the statement variable is used for the authentication procedure then the evaluation of the SQL statement will always be true.

An attacker can cause damage if they appended something like, '; DROP TABLE users;--

This would produce the following statement:

statement = "SELECT * FROM users WHERE name = ''; DROP TABLE users;--';

Which would result in the users table being deleted from the Database.

OWASP Top 10 - Primer

When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. This will begin a 10-part series dedicated to each of these vulnerabilities.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 - Cross Site Scripting (XSS)
A2 - Injection Flaws
A3 - Malicious File Execution
A4 - Insecure Direct Object Reference
A5 - Cross Site Request Forgery (CSRF)
A6 - Information Leakage and Improper Error Handling
A7 - Broken Authentication and Session Management
A8 - Insecure Cryptographic Storage
A9 - Insecure Communications
A10 - Failure to Restrict URL Access

Don't Click That Link!

Why did you just click that link? Most likely you have came to this site by clicking a link from another site. Why did you do that? Did you trust the person who sent you the link? Did you click a link from twitter, facebook, or an email someone sent you?

When you click a link, you are telling your browser, "I trust this person." However, this is not the way we use the internet. We click on links all the time. We click on links from "untrusted" sources. We click links from people we don't know and we even click on URL's that have been modified. On Twitter, a person is much more inclined to click the shortened link http://bit.ly/5hXRW then they are to click http://somewherebank.com/transfer.jsp?amount=1000&to_account=56777564. Even though the shortened link could redirect to the somwherebank.com site.

But, why would someone trick you into clicking a cleverly disguised link? The site that you are redirected to may seem harmless. It could also be extremely malicious.

What happens if this page, (the one you are currently viewing), was filled with Cross-Site Request Forgery (CSRF) links? This web page could be setup with all types of malicious intent. However, you didn't know that when clicking the link. Now, it is too late.

If this site did have Cross-Site Requests, I could do things such as:

• Change the password on your facebook account
• Transfer the money from your online bank account to another account
• Enact trades from a financial institution such as E*Trade

The sites that I exploit would have to be vulnerable to CSRF. But researchers, such as Mike Bailey and Russ McRee, are constantly finding CSRF vulnerabilities in web applications.

An example of how clicking links from untrusted sources is never good was demonstrated in Billy Rios and Nitesh Dhanjani, Bad Sushi talk. In their presentation they described sending phishers a word document stating their account numbers were inside. They sent this email to 25 known phishers. 10 of the phishers opened the word document and were presented with this. In additon, there was another link that said, "Actually, my account information is here." 3 of the 10 clicked on that link. Even the phishers click links they shouldn't.

What should be done? Who knows. It is human nature to trust people and we can't get things done if everytime someone sends us a link we open up a VMware image to view a link. So continue using the Internet the way you have been and remember, "These aren't the droids your looking for."

Quantifying XSS - Why Merchants Won't Fix Their Cross-Site Scripting Vulnerabilities

From previous articles, you should be aware that Cross-Site Scripting (XSS) is an issue that is not going away any time soon.

Unlike it's buzzword predecessor, SQL injection, Cross-Site Scripting is a difficult vulnerability to quantify. What is the risk of not remediating a Cross-Site Scripting vulnerability in your web application?

If you have recently gone through a web application assessment, the report most likely indicates the risk factor of having XSS is high. But, what evidence does the report writer have to support this statement?

Basic security teaches us that risk can be quantified as:

Risk = (Probability of the event occurring) x (The impact if the event occurs)

To support the consultants statement, we would need to identify the probability of an attacker using a Cross-Site Scripting vulnerability as an attack vector and what the impact is, if the user is exploited.

Impact
It is important to realize that XSS is a means, not an end. XSS is simply a transportation mechanism. It is used to facilitate the actual attack which could be system compromise or stealing a users session. The only limitation on XSS is that it operates in a browser enviroment.

Do to the numerous things an attacker can do with XSS, it is hard to quantify an impact for all XSS vulnerabilities. Since XSS has different severities in regards to impact, an orginization should always choose the impact that is most severe. In other words, the worst-case-scenario.

If a user is exploited through an XSS attack, an orginzation can assume the attacker is doing the most damaging thing imaginable. Therefore, if a user is compromised from XSS, the impact is high.

Probability of the Attack Occuring
We have now identified that the impact of Cross-Site Scripting is high. But, what about the probability of it actually occuring?

It is difficult to find evidence of people using Cross-Site Scripting as an an attack vector? There are cases where XSS was used, in conjunction with SQL injection, to insert an offsite iframe into a web page in order to attempt a traditional overflow. Should these attacks be included into the equation for probability of it happening? Since it can be argued that these attacks used SQL injection, and not XSS for propigation, these attacks need to be excluded.

The only evidence I can find is Verizon's 2009 Data Breach Investigation Report. That docuement however, doesn't go into much detail about the specifics of the XSS attack.

Due to the lack of overwhelming evidence, XSS currently is not a common attack method. The probability of a Cross-Site Scripting attack occuring is low.

Cost-Benefit Justification of Fixing Cross-Site Scripting
Since it is difficult to quantify the cost of having an XSS, it is just as difficult to do a cost-benefit analysis on fixing XSS vulnerabilities.

Why should merchants spend money on remediating their XSS vulnerabilities when there is no supporting evidence of attacks occuring?

Until more web applications are compromised through XSS vectors and there is more evidence to support this happening, not much security budget will go towards remediating Cross-Site Scripting vulnerabilities.

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.

Information Gathering: A Way to Identify Who Uses Social Sites

Information gathering on targets is key for attackers. They need to understand their targets to construct more successful attacks.

Recently, I came across http://namechk.com/ I was blown away with the amount of information this site reveals.

The site promotes itself as a way to "check to see if your desired username or vanity url is still available at dozens of popular Social Networking and Social Bookmarking websites."



From an attackers standpoint, lets say I want to identify all of the resources that Jeremiah Grossman, the CTO of WhiteHat Security uses. I simply type in his blogspot id, "jeremiahgrossman" and I identify that in addition to blogspot he also posts to delicious and youtube. This is great!

For an attacker, this resource provides a way to identify additional paths of research.

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

Verizon's 2009 Data Breach Investigation Report

Verizon's annual data breach investigation report came out last week, and I finally had a chance to read through it. I read others security bloggers synopsis of it but none of them seemed to point out anything that was interesting to me.

Here is the interesting bit that I found: Verizon actually recorded someone using XSS as an attack vector.

Typically, it is very difficult to find anything online that points to people using XSS maliciously. Most of the time, XSS is used to increase page views (recent Mikeyy worm) or for popularity (Sammy Worm).

We, the security community, now have some type of hard evidence to explain how XSS could potentially be an issue for companies. Is this enough to bring awarness to management?


Technorati Tags: Verizon 2009 Data Breach Investigation report 2009 XSS Sammy Worm Mikeyy

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