Popular frameworks such as the Browser Exploitation Framework (BeEF) allow us to demonstrate how an XSS flaw can be turned into a scanner, be used to profile users, steal browser cookies, and even cause browsers to exploit themselves.
This makes the power of XSS much more apparent. Doing basic exploitation of XSS flaws doesn’t require a framework, but products such as BeEF http://beef.
What is XSS?
XSS, like most Web application vulnerabilities, exists because of poor input sanitization. There are two types of XSS, stored and reflected. Stored XSS exists in things such as blogs or forums where users can make comments or submit information, and that information is rendered in the browser.
The information, when displayed back to viewers, ends up being rendered instead of only output because HTML characters aren’t processed out by the application. These values are stored in the backend, and as each viewer views the page, he or she will be affected by the XSS code.
Reflected XSS takes place typically in phishing attacks where someone sends a link with input that is rendered back to the user when the link is clicked. This is common in search engines and other types of forms that echo back the results when we enter data. The data isn’t persistent, so it’s harder for the administrators to pick up on unless they are looking at logs.
These types of attacks are usually more targeted as they require a user to fetch the content instead of the content being presented while the browser is doing normal operations.
We will investigate the shell of a search engine application where the author has tried to prevent XSS, but has missed one field. By taking advantage of this reflected XSS vulnerability, we will target an individual who we know has admin access on the site, and steal the user’s cookies.
For this shell of an application, this won’t provide any special access, but this type of attack is used by attackers to steal sessions or other important information from victims in the real world. As this is a real-world attack, it’s important to be able to detect, understand, and explain this type of attack in the scope of a penetration test.
First, let’s look at the vulnerable application. This application takes a search option and says what we searched for along with prepopulating the search box with our last query.
When we print out the information we searched for, the html special chars function is used to generate safe HTML.
However, when populating the field for the search box, no escape functions are used. This would be okay as long as the input doesn’t have a ” symbol in it. However, once we place a quotation symbol in the search box, the HTML output will now have the value corrupted within the tag.
Figure shows the output of search.php when the query test”>xss is submitted.
We can see in Figure that the quote and greater-than sign have closed out the INPUT tag in the source and the xss phrase is displayed to the screen. We can take advantage of this vulnerability with our scripts. When we convert our input into a valid HTML script, we can introduce our own functionality into the Web page. In Figure we have sent the query “><script>alert(‘xss’)</script> and have gotten a pop-up box verifying that we can run scripts successfully. Our goal is to be able to steal the cookies from our target. Building a script will not do much good without a way for us to automatically receive the data. To do that,we need a basic logging script somewhere. This script needs the ability to accept data via a GET request and then save the data for future processing. To do this, we can create another basic PHP script.
Our script will open an output file in append mode and write the cookie variable that is submitted via a GET request. Once the file is closed, we will be able to take the data and add those cookies into our browser using a tool such as the Web Developer Toolbar. We don’t have any cookies yet, though, so our next step is going to be to create aWeb page that will set cookies for us.We want to generate two cookies: one for an admin flag because it’s always fun when we get an admin flag and a session cookie as they are more real-world.
Next part will written soon 🙂 Give us your feed back and stay tuned for part 2