Cross Site Scripting (XSS) Attack info. tutorial and prevention
Cross-Site Scripting (XSS)
What is cross-site scripting?
Cross-site scripting is commonly known as XSS which is a web-based security vulnerability that allows an attacker to interfere between vulnerable web application and user.
If a web application is vulnerable with cross-site scripting (XSS) and user using it with privilege access or even normally using data and connecting with a web application. an attacker can exploit a cross-site scripting (XSS) to masquerade as a victim user and perform and access all user's data and also can get full control over applications functions and all the data.
so you can understand how dangerous this vulnerability can be if exploited.
we will know more about cross-site scripting (XSS) with its types.
Types of cross-site scripting attacks (XSS Attacks)
- Reflected Cross-Site Scripting ( Reflected XSS)
- Stored Cross-Site Scripting ( Stored XSS)
- DOM-based Cross-site scripting ( DOM XSS)
1. Reflected Cross-Site Scripting ( Reflected XSS Attack)
Reflected XSS can arrive when a vulnerable web application receives scripts or data from the user and present it back to web application response in unsafe ways. As the word suggests Reflected, the input data or script can reflect back to the application without a change in it.
for better understanding, I am using DVWA for practical use.
If you don't know how to install DVWA check out
Reflected XSS in DVWA (XSS example)
As we can see in DVWA reflected cross-site scripting (XSS) is functional with parameter input fields such as search bar and other input fields shown in the image.
here in DVWA 'what's your name?' is parameter field is present so we can use lots of payloads to test if it's vulnerable or not but first we will be using
<script>alert('Hello')</script>
payloads are scripts used in XSS which can be modified or used as per application is validating our input. using the above script shows the following pop-up.
that script simply says web application to alert 'Hello'. and as you can see in the application it popped-up 'Hello' without validating anything.
this script won't work with all web applications because each has different factors that are validating the input and present that validated input via a web application.
you will get it in the next example.
XSS in input Validating application
In this example, we will be going to see another example of Reflected XSS.
we have the same screen in DVWA as before but this time it's different let me show you how.
As you can see we injected the same payload in there but instead of pop up we got our validated script back.
As shown in the image our web application validating <script> tags this time.
sometimes it's difficult to find what application is validating because it totally depends on the developer to set validations.
to find it, simply keep trying different payloads or modify payloads with our needs.
Don't worry about XSS payloads I will link it in the end.
Now get back to this Reflected XSS, we need to execute our script without or with getting validated right..?
so we will nest this script tag with another. means we will insert one more script tag in there so if one gets validated by the application then another will be there and execute that script.
modify that script as nested.
<scr<script>ipt>alert('XSS vulnerable')</script>
this will clear you what nested really is so let's see what happens..
we got a pop-up this time so we can say this web application is vulnerable to XSS but validating <script> tag. so our approach to further exploitation will be using payloads without <script> tag or nest the tag as we did above.
so this is how you can get an idea about how web application validated or process inputs determine which type of payload is required and the impact of that vulnerability.
2. Stored Cross-Site Scripting ( Stored XSS)
Stored XSS basically is, an attacker can inject malicious script or payload in parameter input like a comment field or review application field.
but the catch here is as you can see name Stored, means that the script or payload gets stored in the application execute every time the user visits that page.
The user is fully compromised if an attacker can control scripts that can be executed in the victim's browser. which makes it more dangerous than reflected XSS because the attacker can get full control over the user's data and access.
we will know more about stored XSS using an example.
Stored XSS in DVWA ( Stored XSS example)
first, we can see a parameterized input field in there this sign in for guest book is the place where we will be using our payloads.
In this example, we will be using payload.
<a onmouseover="alert(1)">test</a>
this payload pop up an alert when the mouse cursor is hovered over on the text simple and effective to trigger stored XSS.
just sign in using this payload and you will see an entry named test is made up there. as we hover over the mouse curser there the pop-up will show like in the image.
as you can see unlike reflected XSS, stored XSS does not need active user interaction. payload stored in a vulnerable web application can execute when the user interacts with that page and the attacker can have full control over the user's session and data which makes stored XSS more dangerous than reflected.
3. DOM-based cross-site scripting ( DOM XSS)
In DOM-based cross-site scripting (DOM XSS) attackers can use javascript in web applications using controllable sources this code will further arbitrarily execute in a sink that supports dynamic code execution.
in this attack, the payload can be bound with query strings and fragment portions of the URL so whenever that URL will be opened by the user payload will execute and all user data and session can be accessible to an attacker.
DOM-based cross-site scripting using DVWA (DOM-based XSS example)
In DOM-based XSS we need to construct an input field which is a URL that can manipulate to sending any javascript to the sink of the web application.
as in the image above we can construct the URL by simply adding javascript after default=' ' and removing the parameter English given by the web application.
we will try the same alert javascript.
in this image I used javascript
<script>alert('XSS Vulnerable')</script>
and Web application is given pop-up which means it is vulnerable to DOM-based XSS and this javascript executed arbitrarily.
this way attackers can construct a link with payload in it and send it to a victim also do this to websites 404 page and other breadcrumbs so the victim can open it and javascript will arbitrarily execute in that page and victims session and data is accessible by an attacker.
There are 3 types of cross-site scripting (XSS) and these are very common web security vulnerabilities found.
Impact of cross-site scripting
impact of XSS can be range from minimal to critical depending on a web application.
in an application where users are anonymous and public information is the present impact of XSS can be minimal here.
if the site is storing sensitive data of users then the impact can be serious.
if an attacker can privilege escalated within the application then he can have full control of the application and this will be critical.
How to Prevent cross-site scripting
prevention of XSS attacks can depend on how applications handle user-controlled data and the complexity it.
prevention of XSS attacks can be done using the following security measures.
1. By filtering user inputs - as based on valid input user input should be validated correctly and strictly using input filters. expected input only allows to processed further and unnecessary input such as scripts and payload can be validated to some extend.
this you can see in the example above, where we used nested script.
2. Output data needs to be encoded - output data that is generated by user-controllable data can be encoded first before showing it on web pages. data encoding can make it very difficult for an attacker to find the output because it's encoded. also using a different encoding such as javascript, HTML, CSS, URL can make it tough to get output from web application.
3. response headers - response headers such as content-type and x-content-type-options can be used to prevent XSS in HTTP responses which can be interpreted by the browser. it simply disables HTML or javascript contains in response.
cross-site scripting (XSS) cheat sheet-
this XSS cheat sheet contains tons of payloads you can use while testing cross-site scripting. also, modified payloads can be used taking inspiration from this XSS cheat sheet.
