Cross Site Scripting

Cross Site Scripting

Cross site scripting, or XSS, involve a website including unintended Javascript code which is subsequently passes on to users who then execute that code via their browsers. A harmless example of this is:

Cross Site Scripting

This will create the Javascript function alert and create a simple popup with the letters XSS. Now, in previous versions of the book, I recommended you use this example when reporting. That is, until a very successful hacker told me it was a “terrible example”, explaining that often the receiver of a vulnerability report may not understand the severity of the issue and may award a lower bounty because of the harmless example.

So, on that note, use the example to determine if a Cross Site Scripting vulnerability exists, but when reporting, think through how the vulnerability could impact the site and explain that. By that, I don’t mean tell the company what Cross Site Scripting is, but explain what you could achieve with this that directly impacts their site.

Also Read This Sql Injection, Session Hijacking, Facebook Hack

Part of that should include identifying which kind of Cross SIte Scripting you are reporting, as there’s more than one:

  • Reflective XSS: These attacks are not persisted, meaning the XSS is delivered and executed via a single request and response.
  • Stored XSS: These attacks are persisted, or saved, and then executed when a page is loaded to unsuspecting users.
  • Self XSS: These attacks are also not persisted and are usually used as part of tricking a person into running the XSS themselves.

When you are searching for vulnerabilities, you will often find that companies are not concerned with Self XSS, they only care when their users could be impacted through no fault of their own as is the case with Reflective and Stored XSS. However, that doesn’t mean you should totally disregard Self XSS.

If you do find a situation where Self XSS can be executed but not stored, you need to think about how that vulnerability could be exploited, is there something you could combine it with so it is no longer a Self XSS?

One of the most famous examples of a Cross Site Scripting exploitation was the MySpace Samy Worm executed by Samy Kamkar. In October, 2005, Samy exploited a stored XSS vulnerability on MySpace which allowed him to upload Javascript code. The code was then executed whenever anyone visited his MySpace page, thereby making any viewer of Samy’s profile his friend. But, more than that, the code also replicated itself across the pages of Samy’s new friends so that viewers of the infected profile pages now had their profile pages updated with the text, “but most of all, samy is my hero”.

While Samy’s exploitation wasn’t overly malicious, XSS exploits make it possible to steal usernames, passwords, banking information, etc. Despite the potential implications, fixing XSS vulnerabilities is often easy, only requiring software developers to escape user input (just like HTML injection) when rendering it. Though, some sites also strip potential malicious characters when an attacker submits them.

POC : –

Shopify Wholesale
Difficulty: Low
Url: wholesale.shopify.com
Report Link: https://hackerone.com/reports/106293
Date Reported: December 21, 2015
Bounty Paid: $500

Summary :-

XSS vulnerabilities represent real risk for site developers and are still prevalent on sites, often in plain sight. By simply submitting a call to the Javascript alert method, alert(‘test’), you can check whether an input field is vulnerable. Additionally, you could combine this with HTML Injection and submit ASCII encoded characters to see if the text is rendered and interpreted.

When searching for XSS vulnerabilities, here are some things to remember:

  • Test Everything

Regardless of what site you’re looking at and when, always keep hacking! Don’t ever think that a site is too big or too complex to be vulnerable. Opportunities may be staring you in the face asking for a test like wholesale.shopify.com. The stored Google Tagmanager XSS was a result of finding an alternative way to add tags to a site.

  • Vulnerabilities can exist on any form value

For example, the vulnerability on Shopify’s giftcard site was made possible by exploiting the name field associated with an image upload, not the actual file field itself.

  • Always use an HTML proxy when testing

When you try submitting malicious values from the webpage itself, you may run into false positives when the site’s Javascript picks up your illegal values. Don’t waste your time. Submit legitimate values via the browser and then change those values with your proxy to executable Javascript and submit that.

  • XSS Vulnerabilities occur at the time of rendering

Since XSS occurs when browsers render text, make sure to review all areas of a site where values you enter are being used. It’s possible that the Javascript you add won’t be rendered immediately but could show up on subsequent pages. It’s tough but you want to keep an eye out for times when a site is
filtering input vs escaping output. If its the former, look for ways to bypass the input filter as developers may have gotten lazy and aren’t escaping the rendered input.

  • Test unexpected values

Don’t always provide the expected type of values. When the HTML Yahoo Mail exploit was found, an unexpected HTML IMG attribute was provided. Think outside the box and consider what a developer is looking for and then try to provide something that doesn’t match those expectations. This includes finding innovative ways for the potential Javascript to be executed, like bypassing the onmousedown event with Google Images.

Checkout the Cheat-Sheet at OWASP XSS Filter Evasion Cheat-sheet.

Related posts

6 Thoughts to “Cross Site Scripting”

  1. […] Good hacking is a combination of observation and skill. Knowing how encoded characters can be used to expose vulnerabilities is a great skill to have. %0D%0A can be used to test servers and determine whether they may be vulnerability to a CRLF Injection. If it is, take it a step further and try to combine the vulnerability with an XSS injection. […]

  2. […] Also Read This Wifi Hack, Bluetooth Hack, Cross-site-scripting […]

  3. […] script activates in the background to hijack the user’s session cookie. This results in a reflected XSS attack, giving the perpetrator privileged access to the university […]

Leave a Comment