What are Cross Site Scripting (XSS) attacks?
What XSS attacks are and how attacks take place.
What XSS attacks are and how attacks take place.
Cross-site scripting attacks are a form of attack that aims to get unauthorized JavaScript (JS) running on other clients. Simply put, when a website is vulnerable to a cross-site scripting (XSS) attack, it means that an attacker can potentially submit (send) a snippet of code, usually through a vulnerability in HTML/JS sanitization, to the server. The snippet of code is then executed on other client browsers; for example, in the hypothetical situation where YouTube comments were vulnerable to XSS attacks, it would become possible for an attacker to post comments on a user’s behalf; or even worse, permit an attacker to gain access to thousands (if not more) accounts in an instant.
Having said that, the two most common attack vectors are:
Reflected XSS attacks operate on the principle of “temporary” data — this might not seem intuitive at first but an example could be the following:
(there is no actual vulnerability, but if it did exist, the page would need to print a user's input for the video URL)
As seen in the exampe above, such attacks are quite primitive — they require little-to-no effort on the part of an attacker, are hard to trace and often mislead even tech-savvy users. You might not think twice about clicking on a “trusted” website such as Google, YouTube, or et cetera: this is why such an attack is so effective, particularly when sent through messaging platforms where links are often trimmed.
As you might imagine, “persistent” XSS attacks involve attacking a vulnerable website. In particular, snippets of JavaScript can be sent to a victim’s server. Once the vulnerable server “ingests” the data, it can have varying effects: if the data is only ever shown back to the user, then the attack is of limited use — however, should the code be placed on a publicly accessible page, that is when an attack becomes particularly dangerous: an attacker can, for example, read the cookies on your current page (which could potentially compromise accounts), or even scrape personal information. Simply put: webmasters should be always be weary of any user input; assuming an input from a user is not sanitized, anything can be sent to a server.
For example, the “biography” field of a blog website that fails to remove JS or special characters might be vulnerable to a simple snippet of code like:
<script type=”text/javascript”>
alert(“XSS!”);
</script>
On the vulnerable website, loading your “biography” will display the alert (message: “XSS!”).
While there are other forms of XSS attacks, the two most common include “reflected” and “stored” XSS attacks. Attacks can run after a victim visits a compromised (user inputs being parsed in ‘raw’ without any sanitizing) page or clicks on a seemingly trustworthy link (with JS embedded into, say, the query parameter). Regardless of what an attacker does, it is important for users to avoid clicking on content that they do not trust. It is a shared responsibility; a “zero-trust” approach to user input should be taken with any secure web application.
XSS stands for Cross Site Scripting.