March Intensive: XSS Exploits Patrick Dyroff

Sudikoff This past week, I worked at the Sudikoff building in Dartmouth which is the computer science department. More specifically, I worked in the computer science lab everyday and spent my time researching and learning about a very popular technique of web hacking called XSS. http://www.ists.dartmouth.edu/images/Sudikoff_Lab.JPG

Sergey Bratus ISTS' Chief Security Advisor and a Postdoctoral Research Assistant Professor in the Computer Science Department at Dartmouth College Taught the “Computer Security and Privacy” course Undergraduate education at the Moscow Institute of Physics and Technology (AKA, Moscow Phystech), and his Ph.D. at Northeastern University (1999). I have been learning from a man named Sergey for the past couple months and thought I would take this opportunity to work full time on a project with him. We have been working completely on computer security, whether it was network or hardware. I asked him what I could spend a week working on and he offered this topic and I found it very interesting. So I worked on researching and coding my own examples of cross site scripting on a website that I hosted locally on my computer. http://www.ists.dartmouth.edu/people/fellows/bratus.html

What is XSS? Cross-Site Scripting Webpage vulnerability Simple, Used often Code Injection Three types: Type 1, 2 … 0? Cross-site scripting is a type of computer security vulnerability typically found in web applications. They allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML, JavaScript and client-side scripts. An exploited cross-site scripting vulnerability can be used by malicious users to bypass access controls. Recently, vulnerabilities of this kind have been exploited to craft powerful phishing attacks and browser exploits. There are three types: type 1, type 2, and type 0. These names have been coined off http://www.xssed.com/xssinfo and are a great way to think about each type, but are not the universal name for each. http://cdn.memegenerator.net/instances/400x/15481816.jpg

Type 1 Known as non-persistent or reflected. The most common type. Arises when server-side scripts generate a page of results using the data from the web client for the user. An attacker could embed this URL in an email, posing a situation and enticing the victim to click on it This type of vulnerability is known as non-persistent or reflected. This is the most common type. This vulnerability arises when server-side scripts generate a page of results using the data from the web client for the user. In layman's term, it’s when the website uses the victim’s information, in many cases the URL, to generate a page for them. If invalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. Using this technique and a little social engineering, an attacker could embed this URL in an email, posing a situation enticing the victim to click on it and receiving all the commands that the attacker wants.

Type 2 Known as stored, persistent, or second order Most powerful type of XSS attack Can be made when data provided to a web app by a user is stored in a database or file system and can be accessed later by different users Forums are a Type 2 targeted victim examples This type of vulnerability is also known as stored, persistent, or second order. This is the most powerful type of XSS attack. This exploit can be made when data provided to a web application by a user is stored in a database or file system and can be accessed later by different users. An example of this: A malicious user logs onto a blogging site and there is a forum viewed by many others. The user writes a response on the forum that looks very normal, with text similar to other responses, but then puts code that will be executed on viewing her post. This can be used to affect a large number of people with a single injection.

Type 0 Known as DOM-based or Local XSS Very similar to the type 1 vulnerability The problem is also within a page’s client side script There is one key difference between the two This attack goes around the client-side sandbox, not only the cross domain, like other XSS attacks do This type of attack is known as DOM-based or Local XSS. It is very similar to the type 1 vulnerability. The problem is within a page’s client side script. If a piece of JavaScript accesses a URL request parameter and uses this in its HTML code, XSS exploitation is available. In other words, almost completely the same as type 1. There is one key difference between the two. The browser, such as Internet Explorer, treats client-side script in object locally, like in the hard drive of the client. This can result in remote execution vulnerabilities. An attacker could inject a script with privileges of the users browser on their own system. This attack goes around the client-side sandbox, not only the cross domain, like other XSS attacks do.

How can it be used? Cookies!! Allows access to previous sessions Certain logon information Worms, Phishing, Spamming, Oh My! It is used frequently to steal a victim’s cookies. Cookies are small pieces of data sent from a website and stored in a users browser while the user is browsing a website. When the user is browsing the same website in the future, the data can be retrieved by the website. They are designed to remember the state or activities that the user had before leaving. This can include clicking buttons, logging in, or a record of what pages you visited in the past. If an attack got this he could impersonate his victim and use it to log into his previous session. The main reason to use XSS is to obtain data from the victim to use at the attacker leisure. http://meowcheese.com/files/lolpics/2010/06/ok-ok-i-stole-a-cookie.jpg

Patches All these examples can be patched relatively easily Many possibilities that keep being found HTML or JavaScript escape function All these examples can be patched relatively easily, but there are many possibilities that keep being found, so it’s a constant battle. Usually, the owner can put a HTML or JavaScript escape function that escapes the script indicators such as <> or “”. Even then, some hackers have gotten around the HTML and Java escape.

Thanks for listening! http://mimmoo.wordpress.com/2011/06/19/xss-persistent-and-xss-non-persistent/ http://www.xssed.com/xssinfo http://www.webappsec.org/projects/articles/071105.shtml http://4.bp.blogspot.com/__5OawHFd3c4/TTGDPgLjRMI/AAAAAAAAAB4/mcHw3--TsVo/s1600/teaser_xss.png http://images.sodahead.com/profiles/0/0/2/8/9/6/8/4/1/Jazz_Hands_Cat-79814272162.jpeg