Monday, March 14, 2011

XSS Awareness #4: The actual dangers of cross-site scripting vulnerabilities

If you missed either of the other articles in this series, they can be found here:

"What's so bad about XSS vulnerabilities anyway?"

... is a question that's repeated wherever and whenever web application security is being discussed.

The potential damage caused by such vulnerabilities largely depend on which specific kind of vulnerability we're dealing with (persistent vs. non-persistent), and also which services are available to the attacker to use without two-factor confirmation, captchas, etc. Generally speaking, however, there's little an attacker cannot do, when given a vulnerability to exploit.

I like to think of cross-site scripting as handing the control of your browser over to a random stranger, telling him or her to do whatever, so long as it happens within the one website you're logged onto. If that one website happens to be your internet banking website, would you not be worried?

Non-persistent XSS vulnerabilities

Non-persistent implies that the XSS would either have to be delivered in shape of a link the user clicks on, through a hidden frame on a site the user visits, or similar. These vulnerabilities most commonly lead to information disclosure.

If you've logged into your account on your bank's site, then move to an evil site, the evil site can potentially copy your data (social security number, transaction statements, etc.), as well as perform operations in your stead (posts to transaction mechanisms, account deletion, etc). This, however, relies either on persistent sessions or visits to the evil site in one window, while you're still logged on in another window.

Persistent XSS vulnerabilities

Persistent implies that the attacker is able to post something to a page oft visited, and have his script executed whenever someone opens the page. This kind of XSS vulnerability can lead to more serious information disclosure:
  • Legitimate looking password popups, which actually pass the username and password to some evil page
  • MITM-style manipulation of user posted data (e.g. banking transactions), which often require two-factor authentication or similar confirmation codes
  • Intercepting credit card information
Worms also most commonly operate within the "persistent" domain. A worm which ravaged Twitter not so long ago relied on users to hover a link; an action which would cause the target to retweet a piece of malicious code, repeating the process.

Phishing attacks combined with XSS vulnerabilities

Phishing attacks also move to a completely different level when mixed with XSS vulnerabilities. The attacker could use the XSS to inject his own evil scripts into the page, and intercept data, passwords, credit cards etc., using the site's own layout and URL.

Combined with the HTML5 ability to rewrite the URL shown in the browser, the conspicuous looking URL which carries the XSS payload would merely flash for a moment. This technique makes it very difficult for the user to see that there's anything nasty going on, and it will be similarly hard to spot for phishing prevention plugins / applications, since the legitimate site is actually being used (rather than trying to hijack

Not just in the browser

The examples above describe that data can be stolen, and in some cases written, on the web. The internet is however overflowing with write-ups on how XSS vulnerabilities have lead to server-side code execution and even client-side native code execution.

How common are these vulnerabilities?

During February 2011 I notified two large banks in Norway (regarding multiple vulnerabilities which made it trivial to extract account information), Opera (regarding a vulnerability in their new mobile appstore), Github, Twitter, Reddit, Digg, Yfrog, TwitPic, Microsoft and quite a few others.

The majority of these vulnerabilities were trivial to find: In fact, many required no effort at all, as they were spotted by the injection-based xss vulnerability scanner I released to Github a few days ago. Other vulnerabilities were research-oriented, and did require some effort. But if I could find them, people who dedicate their lives to exploiting these things most certainly would.

So where does that leave us?

While it's the dead-serious responsibility of web developers to ensure that their webapps are secure, it's also the responsibility of end users to understand how to stay as protected as possible. I've mentioned NotScripts and FlashBlock before -- both good alternatives for Chrome users. Many other alternatives exist for other browsers.

The very best (although arguably more tedious) advice, however:
Never stay logged in.