#32 Trust No Input: The Dangers Of Cross-Site Scripting (XSS)
Trusting user input can lead to attackers taking control of your customers' machines. Protect them from invisible threats that could empty their bank accounts or steal their identities.
Imagine you have built an e-commerce web application that allows customers to buy products and leave reviews for their purchases.
The review can be typed into a text field and, once submitted, is stored in a database. However, the text is neither validated nor encoded.
Other users can view these reviews immediately on the product page, where many potential customers rely on them to decide whether to purchase the product.
An attacker exploits this by entering a malicious script into the review text field instead of regular text. For example, they might insert a simple script that displays an alert on the page.
The attacker submits the review with the malicious script. Since the review text is neither validated before storage nor encoded when displayed to customers, the script is executed every time someone views the product reviews page. Every customer will see an alert box.
Of course, this is a trivial example, and it is unlikely that anyone will use this attack to show the alert box. What else can happen?
The attacker could embed a script that secretly interacts with the user’s browser to redirect them to malicious pages. These pages might prompt the user to enter sensitive information, such as banking details or social media credentials. The victim would only need to visit the page with the malicious script—such as the legitimate product reviews page—without any obvious indicators or alerts that something is wrong.
From then on, the attacker has complete control over the victim’s browser. After the user enters their data, the attacker immediately sees it and can use it to wipe out all the money from the account or steal their identity.
It is important to understand that XSS (Cross-Site Scripting) attacks come in different categories. The most common types are:
Reflected XSS. The attacker prepares a malicious link that contains the XSS payload like http://yourApp/search?query=<script>alert('You are hacked!')</script>. This link might be sent to the victim via SMS or social media with a message like Your package was lost. Please click on the link to take action. Alternatively, the link could be embedded in a page, enticing the victim to click it.
Stored XSS. Similar to the review example described earlier, the attacker injects a malicious script into a data field (e.g., a review), which is then stored on the server. The script executes every time a user visits the page containing the stored script. This type of XSS is more dangerous because it doesn’t require the victim to click anything; simply visiting the compromised page is enough.
There are several reasons for XSS attacks. First, end users often trust the information they see. For instance, if they receive a message stating that a package has been lost and are asked to click on a link, they may do so without hesitation. This trust can be exploited by attackers to gain control of their browsers.
The second reason is the presence of insufficient security features in the application. This could be due to a lack of expertise or penetration testing on the vendor side. These gaps expose users to unnecessary risks and can lead to severe consequences.
To protect your customers from potential XSS attacks, first, you should validate all the inputs the user can define. The validation rules should be as strict as possible in each case.
Next, encode the output before rendering it on the web page. This way, your browser won’t interpret it as a code. For example, the following text could be stored in the database:
<script>alert(‘You are hacked!’);</script>
Luckily, it was encoded before rendering the page to the user, and the text looks like:
<script>alert('You are hacked');</script>
As a result, no malicious script will be executed, as the browser won’t be able to interpret it as such.
A common misconception is to place too much trust in users. It is especially noticeable when building internal applications for organizational use.
After all, all users are our employees, aren’t they?
Of course, they are. However, their accounts can be compromised, laptops stolen, or they may not have the best intentions. Therefore, adopting a zero-trust policy in security practices is key to protecting against potential threats.
If you are interested in the topic of XSS, I can recommend watching this video:
Have a good read/watch and enjoy the weekend!