XSS Attacks continues Haunting Biggies

Cybercriminals are always on the move, looking for newer ways to exploit various websites and applications. We have mentioned several times, that their attacks are becoming more focused and sophisticated, but does this mean that they have stopped using the old and tested methods of attack? Not really. One of the most common examples of this is XSS. Cross-Site Scripting or XSS is one of the most eminent and prevalent web application layer vulnerabilities. Indusface’s study on the State of Application Security in India, related to an analysis of vulnerabilities data collected by Indusface Web, found that Cross-Site Scripting (XSS) tops the high vulnerabilities list. One would assume that if a vulnerability is well-known, people will be more equipped to deal with it and therefore be least affected by that particular vulnerability. Unfortunately, XSS has continued to infect many applications, including several well-known websites, despite being around as late as the 1990s. Is XSS extremely difficult to fix? Or is protecting against it impossible? Well, the case is neither of the above. Cross-site scripting is easy to find and easy to fix, and in spite of this, cross-site scripting has managed to grace the OWASP Top 10 list, by staying amongst the top 3 threats, 3^rd time in a row.

What is Cross-Site Scripting (XSS)?

XSS or Cross-site scripting is a type of injection problem. XSS is a web application layer vulnerability but is different from other web application layer attacks in the sense that it does not attack the application or server, but the application user.

An XSS attack occurs when a malicious user is able to inject your website with malicious inputs. So basically, your website allowed a user to dynamically input data without properly validating it.

XSS attacks are of three kinds:

Stored XSS

Reflected XSS

DOM Based XSS

You can read more about these on our blog “XSS – The Burning Issue in Web Applications”.

Is Underestimation of XSS causing trouble for big brands?

In early September, this year, security consultant Benjamin Mussler had warned that the Kindle e-book library was vulnerable to a Cross-Site Scripting vulnerability. It came to light that Amazon was aware of this vulnerability and had fixed it earlier, but in July, Amazon introduced a new version of the “Manage Your Kindle” web application. It seems, that they re-introduced the vulnerability in this version, which surprisingly should have been fixed long ago. The cross-site scripting flaw allowed malicious users to inject the victim’s account through e-book metadata with malicious code, which would be executed as soon as the victim accessed the Kindle Library Web page. The hackers could then access and steal the victim’s Amazon account cookies.

This came as a huge reputational blow to a company like Amazon, with experts raising concern on the fact that they ignored addressing this problem way earlier. Even though this problem affected only the user using free versions of e-books from random torrents or malicious websites, Amazon had to face a lot of heat for coming out as a vendor unable to keep its customer’s personal information secure.

WordPress was another recent victim to an XSS flaw, which they patched in November this year. The XSS vulnerability in the comment boxes of WordPress posts and pages could be exploited by an attacker to create comments with malicious JavaScript code embedded in them. These would then get executed by the browsers of users seeing these comments.

“In the most obvious scenario the attacker leaves a comment containing the JavaScript and some links in order to put the comment in the moderation queue,” said Jouko Pynnonen, the security researcher who found the flaw, in an advisory. “When a blog administrator goes to the Dashboard/Comments section to review new comments, the JavaScript gets executed. The script can then perform operations with administrator privileges.”

The 3.9.3, 3.8.5, and 3.7.5 updates from WordPress addressed this XSS vulnerability.

How to protect yourself from XSS attacks

There are many ways in which a web application can be protected from XSS attacks:

1. Proper validation of headers, query strings, cookies, hidden fields, and all other parameters, to decide what to be allowed. Positive input validation is recommended here as opposed to negative input validation. I.e it should be checked what inputs are allowed, rather than focusing on what inputs are not allowed.
2. In the event of displaying user-supplied data, the data should be encoded.
3. You can use tools to test code for XSS vulnerability, before deploying it on the live site.
4. Developers should refer to security control libraries like OWASP’s Enterprise Security API.
5. WAFs help in detecting and blocking attacks against cross-site scripting attacks. They block keywords that lead to XSS, therefore a hacker trying to cross-site scripting a site inputs JavaScript or other similar scripts is stopped by blocking these scripts.

For more information on this, please refer to our blog “Am I Vulnerable To ‘Cross-Site Scripting’ (XSS)?”

XSS is a very well-known vulnerability, which has been studied in depth by security researchers. It’s not very difficult to protect web applications against it, therefore instances of popular sites being compromised due to cross-site scripting attacks are extremely disappointing and websites should proactively act to protect themselves.