XSS also known as Cross-Site Scripting. It is a most common vulnerability in web applications. An attacker can inject malicious code into the web and when a user visits that page, the code is executed. If an attacker is able to inject malicious code into a webpage and whenever a user visits the specially crafted link, the code gets executed. An attacker can perform phishing attacks, Steal accounts and cookies of a user session.
Cross-Site Scripting occurs due to two following reasons:
- When the data in the web application enters through an untrusted source, like web requests.
- When the data is entered in the web content and is sent to a web user without validation.
- The malicious code loaded in a web browser is often in the form of JavaScript, or maybe in the form of HTML and Flash.
Stored and Reflected XSS Attacks
Stored XSS Attack
Reflected or Non-Persistent
Dom-Based XSS Attacks
Now Let’s Look at an example of cross-site scripting:
First Of all, we will look at the example of Stored XSS attack. I will be going to perform this attack on BWAPP.
So let’s open up the Mozilla browser and locate to
http://localhost/BWAPP_Location
Now Select XSS(Stored) and put the following malicious code and see the magic.
- First Name: Test
- Last Name: <script>alert("This is a XSS Exploit Test")</script>
- Click Go.
And Here is the result, you can see that XSS pops up. Because the request is not validated properly and this could cause your data to be stolen.
Now Let’s look for the second type of attack that is Stored XSS attack.
After clicking the submit button you can see the result in the following screenshot. The malicious code is stored on the web. Whenever a user visits the site, he will be prompted with the XSS popup.
How To Determine If Your Web App Is Vulnerable To XSS Attacks
It is difficult to identify XSS vulnerability in web apps. You can do the best is to perform a security review of the code of your search places where the input is supplied through HTTP requests. A variety of HTML and Javascript codes could be used to perform XSS attacks on a web app. You can use Nikto, Nesses and some of the latest tools available on the internet to check for the possible XSS flaws in your web app.
How To Protect Against XSS(Cross Site Scripting)
Here are the primary defenses against Cross Site Scripting in the OWASP XSS Prevention Cheat Sheet.
It's really clamorous that you turn off HTTP TRACE support on all web servers. An attacker can steal cookies even if document.cookie is disabled or not supported by the client with the help of javascript.
This attack is executed when a user posts a malicious code into a forum. When a user clicks the link, an asynchronous HTTP Trace call is triggered which collects the cookie information of the user from the server and sends it to the malicious server that collects the information so the attacker can perform session hijack attack. You can temper it by turning off support for TRACE on the web server.
Alternate XSS Syntax
XSS by using Script in attributes:
An attacker can perform XSS attack without using <Script></Script> tags. For Example:
<body onload=alert('test1')>
or other attributes like: onmouseover, onerror.
onmouseover
<b onmouseover=alert('Yoooo')>click me!</b>
Onerror
<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
XSS using Script Via Encoded URI Schemes
An attacker can encode string character in UTF-8 form and use it in IMG tag:
<IMG SRC=jAvascript:alert('test2')>
Many other encoding schemes are available that an attacker can use to encode characters in a different form.
XSS using code encoding
An attacker can encode script into base64 and put it in META Tag
<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">