Cross-Site Scripting | Web application Vulnerability

In Order to learn web application security, we have to learn about web application vulnerabilities. And the first vulnerability we are going to discuss about is Cross-Site Scripting.

So, let’s see what is cross-site scripting?

What is Cross-Site scripting?

Cross-Site scripting also known as XSS is one of the most popular web application vulnerabilities out there.

XSS at its core takes advantage of the web application using scripts on the users’ browsers. Any dynamically created scripts that are executed put’s the website at risk because the scripts being executed can be contaminated or modified in a way to harm the user.

If the code is unsanitized and allowing all the characters in all the fields, so if any HTML or Javascript is present in such field can be executed without any consideration.

Cross-Site scripting can be categorized in several ways, But the big three ways in which the XSS can be executed are.

• Stored XSS
• Reflected XSS
• DOM-Based XSS

we are going to cover these three types in this article.

Stored XSS

So, let’s talk about stored xss first

Stored XSS is persistent in nature. It means if the payload is inserted in the page, It will stay and execute permanently on the page. Stored XSS is the easiest to detect, and yet they are more dangerous.

Stored XSS—malicious script uploaded by a user that is stored in a data‐
base and then later requested and viewed by other users, resulting in script execution on their machines

Reflected XSS

Reflected XSS are more difficult for new hacker to find and take advantage compare to stored xss.

It is also one of the most exploited web application vulnerabilities. The application takes one or more parameters as input, which is reflected back to the web page generated by the application.

Let’s see an example of reflected XSS on DVWA also known as damm vulnerable web application, where you can test almost all the basic vulnerabilities of the web application.

This is the main page of the reflected XSS testing on DVWA.

So to see reflected xss we have to reflect one or more parameter.

Fill the name field with your name and check the url. and insert a script in the url

like “<script>alert(“XSS”);</script>”

Now let’s execute it !

And this is how a reflected XSS looks like .

So, Now we know what is reflected XSS.

Basically, This is how reflected XSS works.

DOM-Based XSS

DOM-based XSS can be either stored or reflected but makes use of browser
DOM sinks and sources for execution. This XSS differs from others because it is executed with a user-supplied input from the DOM of the browser.

These type of XSS are much difficult to take advantage of.

Let’s see a practical DOM based XSS on DVWA.

This is the main page of the DOM XSS testing on DVWA.

Here, we have to select the language, Let’s go with English and analyse the URL.

The URL looks like this.

Now let’s try adding the same XSS script we have used in reflected in the end of the URL and see what happens.

We have added the script. Let’s try to run it and see what happens.

Here we go, We got the XSS popup. That means we have successfully executed the DOM-Based XSS.

Basically, In DOM-Based XSS The attacker can manipulate this data to include XSS content on the web page, for example, malicious JavaScript code.

Now we’ve seen all the major types of Cross-site scripting and how to do it.

How to prevent XSS?

1. Filter Input on arrival
2. Encode the data on the output.
3. Use appropriate response header to prevent XSS.
4. Always Sanitize the users’ input.

So, These are some ways to prevent cross site scripting.