When you search for Cross Site Scripting(XSS) on the web, you come across multiple articles explaining the attack, its types, ways of prevention and how they are actually carried out. No wonder any developer building a website has to think and take care of the scenarios that can happen due to such attacks.
But let me talk about it for my readers who don’t belong to developer’s community and how this affects them. So for anyone reading this article has access to the Internet. In such cases, every one of us provides a variety of data to the web companies in the form of the name, birthdate as well as your relationship status. But what concerns a layman, is the use of the Internet for banking.
Background
Let’s discuss how so “easy to overlook” mistake of a developer costs a fortune to a simple man. To understand how XSS can affect you, let’s understand how a website works behind the curtain. Like any machine run application, in this case, a ‘website’, uses a language. The language here used is HTML - Hypertext Markup Language. In HTML, we define instructions using <> tags. So everything you see on a webpage is contained within these tags <>, for example, a paragraph like the one you are reading, will be encoded as <p>Let’s discuss how “easy to overlook” mistake …</p>.
Everything was good in the hood until javascript came into the woods. Javascript, another mighty language for the web, which empowered website developers to do wonders. The buttons you click, colours that change, images that you are seeing and a hell lot of functionalities, are the boon of javascript. The game changed for the developers, now they could do so much more in a simple HTML by just using a simple tag <script>Do wonders for me!</script>. But this was a gateway for the bad guys too. How?
This can be explained using a very simple example without sounding too techy! To get started, let’s understand the simple concept of cookies on the web. So when you access a website, it stores a “cookie” for you on your browser/computer. This cookie helps the website to know that it’s you every time you visit the webpage. Suppose you use internet banking, you will have your username and password to login into the account. So when you login, the site creates a secure authorised session with a “cookie”, to know that it’s you throughout the session and allow only you to perform banking for your login. Let’s consider an appearing to be, a secure website, where behind the story looks all good and safe. Let’s assume this happens when you click the login button.
<html>
<input type="text" name="username" required> /* Get Username*/
<input type="password" name="psw" required> /*Get invisble password*/
<button onclick="doWonders()">LOGIN</button> /*LOGIN button*/
<script>
function doWonders() {
1. get username and password from the form
2. Do to the database, search the username in database
3. If not present, Send Error “Invalid Username and Password”
4. If present, get the encrypted password, decrypt it and match it with the given password
i) If matches, redirect to http://xyzbank.com/user=username
ii) If not, Send Error “Invalid Username and Password”
}
</script>
</html>Preparing the attack
It looks like a good flow of validation and a user check. When redirected, you can do anything only if you have the cookie for that session and for the username used for redirection. Where’s the issue? Let’s think like bad guys! Now I can access your bank online account if the session is open and I have the needed cookie. Right? In this case, what will I do is, I will use my superpower... “The <script>”.
The attack I plan can be in this way, I send you a mail which says increase your credit card monthly limit which is almost identical to the original mail.
So you will log in to your bank account and create a new session for say, 10 minutes. You come back to your mail, to click on the hyperlink and then the attack begins, the link triggers a javascript command to send your stored cookies for the bank website to a particular location, from where I will copy the cookies into my machine and connect to your bank account during those 10 minutes, with username in the cookies, as redirect URL is simply http://yourbankwebsite.com/user=username. And you will not notice a thing as you land upon the same page. Till now it looked perfect, but with a combination of your overlook and developer’s mistake, you have handed over your bank account to fraud. Congratulations!
Conclusion
With time, developers have made this a habit to sanitize every user’s input. By sanitize, I mean take care of such javascript tags. This was just an example of a decades-old attack, which is popularly known as Session Hijacking. Still, over these decades, this is relevant and we can find such attacks in the cyber-world even today. This site has a good collection of news reporting XSS attacks - https://portswigger.net/daily-swig/xss and you will get to know how innovative the attacks are!
This article was intended to give anyone an idea of XSS and not to get into its technical details. If you want me to write a related article, let me know in the comments and I will have a detailed discussion on XSS on technical terms. To know more about XSS, visit: https://owasp.org/www-community/attacks/xss/, It’s a corporate community-owned website where the information is posted by tech leaders in the security industry. Till then, watch out for more exciting articles!
Sure, I will get a full attack simulation with code for the next article. Keep looking for space!
Good one Pranay, explained well in Layman's terms, surely must be understandable to the non-tech audience. I would like a more technical discussion on the same.