Cross-Site Scripting has been one of the most abundant attacks on the Internet, and has been for the last decade. It is a danger that is almost impossible to detect as a user and could be a problem of the past in a perfect world. What makes them so hard to detect is because scripts are not returned visually to the web browser, they are instead ran silently in the background. Sadly, many websites are still vulnerable to this attack due to negligence, ignorance, or vulnerable plugins.
How Cross-Site Scripting Works
Cross-site scripting attacks rely on the trust inherent in modern browsers and operating systems. In order for a cross-site scripting attack to work, an attacker first has to find a vulnerable website, web application, web server, or website/web application plugin, in which malicious code can be injected.
Once the attacker finds a vulnerability in one of these platforms or plugins, they are then able to inject or insert their malicious code in with the rest of the content being delivered to the web browser. Since this malicious content is delivered to the browser from a “trusted” source–or the originating source–it is executed with the full, inherited permissions of the browser.
This inherent trust is what allows a malicious, injected script to view other open websites, steal cookies (which could allow session hijacking), or even install unwanted programs or browser plugins. All of this is done transparently to the victim. That is why this attack is so dangerous.
Types of Attacks
Cross-site scripting attacks are generally considered to be in one of three domains, non-persistent, persistent, and DOM.
Non-Persistent (Reflected)
Non-persistent cross-site scripting attacks are a one-time use type of attack. This attack relies on a vulnerable website or web application that returns information which has been submitted to it, thus making a direct reflection of the submitted code present in the returned content from the web server.
In the past, vulnerable search engines would reflect submitted scripts back to the web browser, at which point they would be executed against the victim. If a victim clicked an obfuscated link which pointed to a vulnerable search engine, which also submitted a script to the search engine through the link, the script would automatically be reflected back to the victim’s browser in the results page and execute in the background.
And example URL might look like the following:
www.mywebsite.com/search.asp?term=<_script>MaliciousFunction(...)</script_>
There is usually a social engineering aspect associated with this attack, because the specially crafted link has to be delivered to the victim. This can typically be accomplished through email, social media, or even instant messaging.
Persistent (Stored)
The persistent type of cross-site scripting often uses web forms, where data can be directly submitted to the server for long-term storage. Vulnerable web forums (message boards) and message forms for internal correspondence enable this type of attack. If a message is sent to another user with malicious scripts in the submitted content, when the content is downloaded from the server and rendered for the recipient the scripts will be transparently executed in the background. The same is true for web forums, just on a larger scale, affecting anyone who visits the malicious post. The malicious scripts are stored on the web server.
Any website that accepts user input might be susceptible to cross-site scripting attacks if remedial actions are not taken.
DOM Attack (Document Object Model)
Document Object Model cross-site scripting attacks involve the way HTML documents are parsed into the browser. DOM attacks are a client-side variant of non-persistent, reflected attacks. Since HTML pages using JavaScript can store certain variable information in the document object model, such as a page URL, if malicious data is parsed and stored from a malicious URL, a malicious script can be rendered back into the browser and executed.
For example:
First an attacker finds a vulnerable webpage that parses URL information in order to personalize and render the webpage (such as a username); this is key to the vulnerability. The attacker then creates a malicious, obfuscated link, much like the previous example link given above. The victim of the attack is then coerced into clicking the obfuscated link. When the malicious link is parsed by the webpage, instead of, say a username being returned and printed on the page, the malicious script in the URL is ran and executed behind the scenes.
Guarding Against Attacks
There are a few different ways to stop cross-site scripting attacks before they happen. Modern browsers do their part in stopping what they can, but ultimately the decision to stop cross-site scripting is on the administrator’s shoulders.
Same-Origin Policy
One of the first guards against cross-site scripting was the “same origin policy,” a technique of blocking scripts and requests from one website to another unless they share the same “protocol://domain:port”. For example, if someone is has two browser tabs open, one for Gmail and one for Chase Bank, a maliciously written email in the Gmail tab would not be able to access resources on the Chase Bank page. But, this technique is not perfect and should not be the only form or protection a web administrator relies upon.
Input Validation
Input validation, or input sanitation, is a good way to stop non-persistent and persistent cross-site scripting attacks. It stops user-input from being presented back to the browser and executed in the first place. In the process of validation, HTML tags can be removed if they are found not to be necessary.
Redirection
Instead of repeating back the bad script or malicious URL parameters in the page returned from the invalid user input, merely redirect them user to a different URL altogether. This way the bad script is not reflected back into the victim’s browser.
Preventative Measures
It is better to prevent or avoid an attack in the first place, than try to mitigate it.
Do Not Trust Links
One of the best ways to stop non-persistent cross-site scripting and DOM attacks is to not trust links. Do not click links in emails because they can be obfuscated, and do not click links on social media unless they are trusted–proceed with caution even then. Right-click and copy a link location if you are unsure about a link or if it is from an untrusted source and inspect it before proceeding. You can also use a link expander to view where shortened links go before proceeding to them, as well.
Content Security Policy
Another good way to prevent cross-site scripting attacks from happening is to implement the Content Security Policy in your websites. It is a form of whitelisting that prevents unapproved scripts from being able to execute, even if they are part of a client-side DOM attack.
DOM Cross-Site Scripting Prevention Measures
As Document Object Model cross-site scripting is already hard enough for most people to wrap their head around, I will merely provide a link below on other prevention methods. [1]
Remember through all of this, that the website is just the medium through which these attacks are passed. The real target is you and your information.
Consider NOT clicking the links below and copying/pasting them into your URL bar instead.
[1] DOM Cross-Site Scripting Prevention Measures: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
