Photo by Shahadat Rahman on Unsplash
The story of Cross Site Scripting
and why you should never trust your users.
Even with billions of people on the internet, we all understand that growing your following to a million followers on social media is no joke. It takes deliberate effort, consistency, and patience. But what if I told you that someone managed to do that in just one day, not today, but back in 2005?
This is the story of Samy, Cross Site Scripting, and why you should never ever trust user input.
Back in 2005, social media was in its infancy, the Web was transitioning from static read-only websites to Web 2.0, where one could do both, read and write on websites. This was also the time when Myspace was booming and was the fifth most popular website in the world. This presented an opportunity for Samy, a 19 year old tinkerer from Britain.
Myspace allowed a user to customize their homepage, but only to a certain extent. Samy then started tinkering to overcome these limitations, studying what is restricted by Myspace and how they restrict it. This is when he discovered a game-breaking bug. Using Cross Site Scripting (XSS), he managed to create a worm, a program that self replicates to spread itself over a network, which would add Samy’s name to the ‘List of heroes’ of any person who clicks on Samy’s profile. Not only that, this worm then gets copied on the profile of the visitor, and then anyone who clicks on the visitor’s profile would get infected by the same worm, repeating the process.
Samy tinkered further, so that this worm not only adds his name to the heroes list of the visitor, but also adds him as a friend. Due to the self-replicating nature of the bug, the growth was exponential. Samy gained a million friends in a day
This begs the question, what even is Cross Site Scripting? I’m glad you asked.
Open Web Application Security Framework, also known as OWASP, says that Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user.
Basically, in XSS, an attacker injects malicious code into places where a user can provide input. This is a bookish definition, so let’s look at an example.
This is a tweet, which showcases an XSS vulnerability in Tweetdeck, a social media dashboard application for the management of Twitter accounts. Let’s look at it step by step.
First, there’s a script tag (). The script tag tells the browser that whatever is written between these tags is a piece of Javascript code. It’s equivalent to saying, “Hey browser, run this piece of code for me”. Note how the opening script tag says class=”xss”.
Second, there is $.(‘xss’).parents().eq(1). The dollar sign is for using jQuery, a Javascript plugin that was used widely back in 2014 to make Javascript developers' lives much easier. That piece of code tells the browser to search this webpage for anything with the class of “xss”. Well, what belongs to class xss? This tweet itself. This line is telling the browser to find itself. .parents().eq(1) is equivalent to a user clicking on this tweet to select it.
Third, find(‘a’).eq(1).click() . ‘a’ stands for anchor, more commonly known as a link. This bit asks the browser to find all the links in the tweet that we just selected. There are 4 links here, Reply, Retweet, Favorite, and More. .eq(1) selects the second link out of these 4 (because computers count from 0), which is the retweet button. Lastly .click() clicks on this button.
This opens a dialog box saying, asking you if you’re sure you want to retweet. $(‘[data-action=retweet]’).click(); makes sure that you click yes when that box pops up.
The work is done, but Andy still had a few characters worth of space left, and made sure he used it.
The next line is alert(‘XSS in Tweetdeck’), which pops up a dialog box, telling the user exactly what has happened. Lastly, a heart emoji to tie it all together.
This led to this tweet being retweeted by anyone who saw this tweet, racking up an astonishing 63,000 retweets.
How do I avoid XSS in my projects? While building your websites, keep the following things in mind:
Escape user input: Escaping means converting the key characters in the data that a web page receives to prevent the data from being interpreted in any malicious way. It doesn't allow the special characters to be rendered.
Validate user input: Treat anything that originates data from outside the system as untrusted. Validate all the input data. Use an allowlist of known, acceptable, good input.
Sanitize data: Examine and remove unwanted data, such as HTML tags that are deemed to be unsafe. Keep the safe data and remove any unsafe characters from the data.
If you want more information about preventing XSS, you can refer to the OWASP XSS Prevention Cheat sheet. XSS attacks are slowly reducing in popularity, thanks to people using web development frameworks on both frontend and backend, that being said, one can never be too safe when it comes to application security. Happy hacking!
References: