What is XSS attack?

XSS stands for Cross Site Scripting attack. This attack is the most powerful attack that is used mostly but black hat hackers to deface a website. Nowadays XSS can be performed against IOT devices also.

In this attack the attacker injects their own script code into a trusted website. The website’s vulnerabilities are exposed, usually via JavaScript and sometimes via VBScript.

Types of Cross-Site Scripting

Reflected

  1. Scripts are never stored, they’re just shown in the website
  2. The user is presented with a malicious link, when the unsuspecting user clikcs on the link, the malicious script will get executed by the user’s browser.

Persistent

Scripts are stored by the website database, XML files, log files, user profiles, forums, posts, or message boards. Happens less frequently, but the consequences are far more severe.

DOM-Based

The Cross-Scripting attack happens in the DOM instead of the HTML. The HTML source code and the attackers response will be exactly the same, so the payload can only be found in runtime or if the DOM is investigated.

How to Prevent Cross-Site Scripting Attacks

Validate all inputs on the server side. Don’t use client-side input validation, it can be bypassed by proxies
Safely store and process raw data using methods that prevent injection
Escape and encode output so input is never interpreted

Let’s explore a couple of practical attack scenarios that can be implemented as PoCs to prove the real risk of Cross-Site Scripting (XSS) vulnerabilities.

As a penetration tester, you want your customers to understand the risk of the vulnerabilities that you find. And the best way to do this is by creating a high-impact proof-of-concept (PoC) in which you show how attackers can exploit the vulnerabilities and affect the business.

In this article we will see how to create XSS attack PoCs in order to:

  1. Hijack a user’s session
  2. Perform unauthorized activities
  3. Perform phishing attacks
  4. Capture key strokes
  5. Steal sensitive information

XSS Attack: Hijacking the user session
Most web applications maintain user sessions in order to identify the user across multiple HTTP requests. Sessions are identified by session cookies.

For example, after a successful login to an application, the server will send you a session cookie by the Set-Cookie header. Now, if you want to access any page in the application or submit a form, the cookie (which is now stored in the browser) will also be included in all the requests sent to the server. This way, the server will know who you are.

Thus, session cookies are sensitive information which, if compromised, may allow an attacker to impersonate the legitimate user and gain access to his existing web session. This attack is called session hijacking.

JavaScript code running in the browser can access the session cookies (when they lack the flag HTTPOnly) by calling document.cookie. So, if we inject the following payload into our name parameter, the vulnerable page will show the current cookie value in an alert box.

Also other XSS attacks can be performed by tampering Javascript and also by stolen cookies of current user sessions.

XSS attacks

You May Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *