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.
Types of Cross-Site Scripting
- Scripts are never stored, they’re just shown in the website
- 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.
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.
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:
- Hijack a user’s session
- Perform unauthorized activities
- Perform phishing attacks
- Capture key strokes
- 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.