Skip to content ↓ | Skip to navigation ↓

Recently, I identified and disclosed several cross-site scripting (XSS) vulnerabilities within a website I’ve recently started using.  In case you don’t know, an XSS vulnerability basically means that an attacker can provide new scripts to execute within the context of the vulnerable web application.

The application vendor, let’s call them ‘Company X’ for now, advertises that their sites serve millions of users in over a half dozen countries.   A quick Google search for the ‘This site is provided by Company X’ returns 32,000+ results.

I looked at a few of these sites, including Company X’s own online demo site, and this cursory examination revealed the same set of persistent and non-persistent XSS vulnerabilities.

This means Company X is probably putting a huge number of their users at potential risk with these vulnerabilities.

In order to do my part in helping to secure the users of this service, I started with a friendly email to the local site admin.   I also created a few benign, proof-of-concept example links to do a JavaScript alert of the active user’s plain text username and password — these values are stored in a cookie making it trivial to reveal.

Along with this information, I explained to the admin that a malicious attacker could just as easily inject script content to silently upload the credentials or even embed exploit code.  The response I got back was unconcerned.

The admin told me that, “we do not store private information,” and that users have the “ability to change their login and password as often as they would like.”

This unsatisfactory response was what triggered my decision to write this post. Cross-site scripting vulnerabilities should never be discounted on the grounds that a web site has nothing worth protecting.

It seems that these vulnerabilities are commonly undervalued due to a general lack of education regarding the risks of a successful XSS attack.  This mindset is dangerous because every web site has something worth protecting!

For the moment let’s ignore the tendency of most web users to recycle credentials–even without the value of stolen passwords an unprotected web site puts its users at risk. Each time a user browses to a site with a persistent cross-site scripting vulnerability, they are inviting malicious code to execute in their browser.

Even if a web site has no information of value, successful browser exploitation puts all of the data on the website users’ computer at risk.

After  I elaborated on this aspect a bit more, the admin eventually agreed to pass the disclosures onto the vendor, but due to the breadth of these issues it will likely be a while before the issues are addressed.

Users are, arguably, a website’s greatest asset. It’s every website owner’s responsibility to make sure that their site sanitizes input so as to avoid putting their users at risk of infection and exploitation via cross-site scripting.


Image courtesy of ShutterStock