Cross-Site Scripting (XSS) is a Code Injection attack executed on the client-side of a Web Application.

• The attacker injects malicious scripts through the web browser.
• The malicious script is executed when the victim visits the web page or web server.
• Steals Cookies, Session tokens, and other sensitive information.
• Modify the contents of the Website.

HOW DOES IT WORK?

A hacker can inject a malicious code on the website which is then sent either to the victim or to the webserver depending on what kind of cross-site scripting you’re using and when this happens the malicious script is executed either when the victim visits our web page or when the victim tries to access a piece or access some data from the webserver and when all this is happening a hacker can inject a code which can be used to steal the credentials or any sensitive information and by this logic, a hacker can inject a malicious script that can be used to steal the credentials or any other sensitive information of the victim either from the web browser or the webserver so this is the logic behind cross-site scripting attack.

There are mainly three types of cross-site:

1. Reflected XSS (non -persistent)

In this case, the script is executed on the victim side, and data or script is not stored on the webserver.
It is mainly executed on the browser so the script is not sent to the server or even if it sent depending on the API calls or the requests the script is not stored on the browser side and that’s why it’s called reflected cross-site scripting because the malicious script is reflected on the victim side and it’s not really stored on the server.

The attacker’s payload has to be a part of the request that is sent to the webserver. It is then reflected back in such a way that the HTTP response includes the payload from the HTTP request.

It can be dangerous when attackers use the script tag and create a pop-up and try to access the cookies for this web application.

what is a session ID basically?
A session ID is a unique string assigned to a particular user when the session is going on by the webserver to identify that particular user.

Now developer increases the security with low to medium so the web application will do something to eliminate this script tag and the end script tag.

Now attacker will do nested script for by pass this security <scr<script>ipt>alert(document.cookie)</script>
again it will popup :

what the web application did is it looked at the input it found the script tag here and it eliminated the script tag and because I had nested a script tag even when it eliminated the main script tag there was another script tag that was formed and this is how you could see the pop-up so basically when you nested tag the script tag is eliminated and when the script tag is eliminated the divided part of the script tag is concatenated as a string like you can see here and then this code is executed so this is how we can use cross-site scripting if the web application is designed to eliminate the script tag.

Now develop increase the security with medium to high: It will give the same output for both of the previous scripts as”

It is because code is used to sanitizer input on this web application

Here is this code is making use of regular expression and wherever there’s a script tag found or wherever there’s a script tag formed it is replacing that with a blank space or with an empty character so basically this means that we cannot use the script tag in any way.

what we can do is give a malicious script or give a malicious input without using a script tag

<img src=x onMouseOver=alert(document.cookie)>

here we are using img tag and onMouseOver function and x are source dummy values.

2. Stored XSS (Persistent)

An attacker uses Stored XSS to inject malicious content (referred to as the payload), most often JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored (persisted) by the target application, for example within a database. For example, an attacker may enter a malicious script into a user input field such as a blog comment field or in a forum post. When a victim opens the affected web page in a browser, the XSS attack payload is served to the victim’s browser as part of the HTML code (just like a legitimate comment would). This means that victims will end up executing the malicious script once the page is viewed in their browser.

Input as a name and message and then it stores that so even if I refresh this you can see that the data is still present because this is stored in a database and it is being fest every time, I access this web page.

Now if we put this <script>alert(document.cookie)</script> in message filed then it will pop up the session id every time I user visits this web page the malicious script executes so it’s the same in the case of applications that store data from the user.

If the developer increases the security, we can do the same thing as we have done before, here we can do it in the name and the message field.

3. DOM (Document object model)
It makes use of the document object model to inject the malicious script.
It is a client-side attack.
The script is not sent to the server.
Legitimate Server script is executed followed by Malicious script.

Cross-site scripting we mainly manipulate the URL that is being used or the URL that is being generated

If we increase the security it will not allow the malicious script because

we choose English as the option this part is executed so instead of the webpage closing this for me, we adding another option tag and I’m adding another select tag so what happens is this part of the code does not execute because I am closing it here and then I’m typing my malicious script here

In URL we going to close the tag right here the option tag and the Select tag and we goanna use the body tag here and the function onload which has to create a pop up that sessid

<option></select><body onload=alert(document.cookie)>

If it also blocks then
so, what we going to do is we going to use a pound symbol or the hash # symbol and then use my malicious script after that so because the pound symbol is used to index or to point to a certain page on the same website this web page will not consider it as the input it will just think that we are trying to point to a particular part in the web page.

HOW TO PREVENT CROSS-SITE SCRIPTING?

• User input Escaping

Escape the user input so there are special characters like greater than symbol smaller than symbol which is generally used in tags or in malicious script or maybe the percentage symbol so the first thing you can do is escaping these characters which mean is that you take off the special feature of this character and make it just another text character

• Consider all input as a threat

Consider all input as a thread because the user has complete control on what input he gives you have to assume that every input is a thread and sanitize and handle every input with care the next.

• Data Validation

Data validation suppose you have a field of login where you can enter user name and password what you can do is use data validation especially in the case of email IDs because you know the generic format for an email ID they should be a username they should be an at the rating symbol than something then calm or dot something so you can scripting attacks.

• Sanitize data

sanitizing data, they were eliminating the script tags or they were eliminating any script tag found and they were also using regular expressions to eliminate all the script tags that can be generated so this is how we can sanitize data the input data

• Encode output

Encode the output so what happens is when I gave the script tag and alert as the input as the malicious the arrow symbols were being treated as the arrow symbols what he can do is you can URL encode them so the arrow symbol will be something like percent is 25 so when you encoded it’s no longer a malicious script so you can use encoding URL encoding for the input or for the output.

• Use right response headers

Response headers you can decide what the response header should be you can decide what data can be sent or what data can be received through the response headers.

• Use Content Security Policy

Content security policies so this is a standard it is also known as CSP standards so you can use a content security policy to avoid cross-site scripting

● Find some common pages such as — Contact Us | Search bar |Comment Box | Forums |Signup | Login Page |, etc Give any input There. If your input reflects or is stored anywhere there may be XSS

● Try to execute any JavaScript code there, if you succeed to execute any JavaScript there then there is an XSS

● Try to Inject any JavaScript there

● Exploitation of XSS