XSS for dummies!
XSS attack also called ‘Cross-Site Scripting attack’, is one of the most popular client-side injection attacks, which is a piece of code that could enable the attacker to do whatever he wants with the website. It’s an end-user oriented attack that basically hijacks the user control compared to other data-oriented attacks like SQL-injection that access the database directly.
Let’s break it down first!
Let’s suppose that we are creating a very basic sign-in page for a blogging site, that supports multiple users to signup and writes blogs on our website. Pretty basic job, if you even have basic experience in web development!
For that, we would start with a basic frontend.
The frontend of every website is written in a language called HTML — hypertext markup language. It’s made up of a large number of tags that instruct the browser how the information between the tags should be rendered. For example,
<p> This is a paragraph </p>
is an HTML command that informs the browser that the line This is a paragraph should be displayed as a paragraph on the website. <b></b> indicates that the line between the tags should be bold, <h1></h1> indicates that the text should be a heading element etc. There are a lot of tags! (But HTML is pretty basic and easy to learn).
In our code, the login details are sent to a server that authenticates the user. If the user is not authenticated, then it displays the failed username. Cool!
Now, where does the problem lie?
It’s with JavaScript!
Javascript is a client-side scripting language with Dynamic Translation (also called just-in-time compilation) that allows the code to be compiled during execution. It’s extremely popular in frontend web development and in some backend technologies like NodeJS.
The example code here calculates the sum of the first five natural numbers. When inserted between the tags, this value can be used to change the way certain things are rendered.
Javascript allows the client-application, i.e. the website, to process information that it either receives from the server or it wishes to send, like for example, posting a message, sending user credentials for login, etc., or even to render games. Therefore, it’s extremely powerful and it’s used by almost all the major websites that are hosted. But, this opens up a major vulnerability that, when left unchecked, can prove disastrous.
As a user of the website, you can inject javascript code in data-request blocks like forms.
So, how does that work?
Javascript is added to HTML pages through, you guessed it, tags! A script tag is added that either has the link to the javascript code or has the code directly added between the tag, which is <script></script>
However, since the JS code has enormous control over the website, a user can insert an entire JS code with script tags included, into an entry field that the website, instead of understanding as just plain text, executes it as a JS code part of the website. This can change the way things are rendered.
Let’s get back to our over-arching example.
If we enter <script>window.alert(“You have been spoofed by XSS”)</script> as our USERNAME and provide any password, it will result in this:
As you can see, the script got executed even before the username got displayed. This is because, while displaying the username, the script gets executed first when it’s inserted into the DOM and then is displayed. This is how XSS works!
Is that it !?
There are various versions of the same, but at the simplest level, that is how it is. There are, as stated, many variations of XSS like Reflective XSS that embeds js code in the HTTP request, so when the user clicks the link, the code gets executed, like for example:
https://hckrmann.com/items?search=<script>/*+I + can + attack +you…+*/</script>
When you, then display the search field in the query,
<p>You have searched:<script>I can attack you…</script></p>
The script will get executed!
Persistent XSS is one where a malicious string originates from the website’s database. There are many more such XSS variants that you can look into.
XSS vulnerability has been exploited to do all sorts of shady, malicious activities without the knowledge of the user. XSS is commonly used in stealing cookies and passwords saved locally in your browser. As the attacker can manipulate the browser through Javascript, he can access the local storage (browser-specific storage that stores cookies or auth tokens). This seriously compromises the user’s session cookie that allows the attacker to take over their accounts. The user will be oblivious to this. Not only this, in extreme cases, but they can also get access to the user’s local files and can also download malicious files to their systems.
One of the best examples is when Twitter forgot about this.
When TweetDeck was launched on Twitter, the developers had forgotten to handle XSS vulnerability. A user by the name *andy understood this and quickly wrote a tweet that displays the vulnerability present in the system. He wrote a small script that alerts and retweets itself whenever the tweet is inserted into the website’s DOM for any user. As a result, in a matter of minutes, the tweet became very popular and was pushed as a recommended tweet to all users as it garnered a huge number of tweets and tricked the algorithm. The developers quickly found about this and brought it down.
SO, HOW TO FIX THIS? Every data coming from the website needs to be sanitized to prevent the website from being tricked. Many backend technologies have means to overcome XSS in a simple way, and there are also ways to implement the fix in frontend. It is a simple process and seems trivial but quite important.
To conclude,
XSS is still a problem in the industry, and even the most prominent companies tend to gloss over this. As developers, we must be responsible so that the users have a safe and wonderful time using our websites!
I hope this article provided an insight into the world of XSS. I have attached a few articles for further insight into the same. Prevent XSS as and when you develop and protect those sweet cookies!
References:
Happy coding!!
This article is published as a part of the Hacker Series under Spider Research and Development Club, NIT Trichy on a Web Wednesday!
