XSS (Cross Site Scripting)

Well i think this topic was covered numerous times but also i want to give it a shot. Seccond of all welcome to my seccond article on the medium platform. I hope you will find this article helpfull in you day to day hacking!

What is Cross Site Scripting

Cross-site scripting (XSS) is a type of cyber attack that enables malicious actors to insert harmful JavaScript code into the frontend scripts of a vulnerable web application. Exploiting this vulnerability can lead to significant and detrimental consequences for the targeted website.

There are several types of XSS you can exploit in the application and those are:

1. Reflected XSS
2. Stored XSS
3. DOM based XSS

We will now delve into an in-depth explanation of each of these pertinent topics, ensuring that you gain a comprehensive understanding of them.

Reflected XSS

Let’s begin by discussing Reflected XSS, which is a specific type of cross-site scripting vulnerability. In instances of Reflected XSS, input provided by a user is immediately echoed or reflected back onto the web page. To illustrate, consider a search field where the input you provide is displayed directly on the page. In this scenario, a potential attacker could attempt to inject malicious code using a specific payload. If the application is indeed susceptible to this vulnerability, executing the payload could trigger a pop-up window to appear.

<script>alert(1)</script>

To illustrate this, I will refer to PortSwigger Labs, a platform that I highly recommend for its educational value and hands-on experience in the field.

Laboratory 1

We can see when we submit some input application includes that in the request and returns it to the application in unsafe manner

We can submit the payload i mentioned before which was <script>alert(1)</script> this will pop up alert window which will indicate that we have XSS present.

If there is good encoding we won’t be able to execute XSS, and that is not the only protection website can have but it is important one. Now there are variations in reflected XSS where we won’t be able to just execute the <script> payload but i wont cover it in this article because that requires in depth analysis and looking for specific paylaod.

Testing for reflected XSS

To test for reflected XSS vulnerability we need to follow couple of steps:

1. Identify all input fields there are in the application you are testing.
2. Send random alphanumeric characters.
3. Look for reflection in the application.
4. Look for candidate payload.

Stored XSS

Stored XSS or persistent XSS is a different story someone will say it has the most impact and i would agree. This type of XSS arises when application is getting input from untrusted source and then including it in every HTTP response in unsafe way.

To provide an example, envision a situation in which a blog page integrates a comment feature. In this scenario, a malicious actor could submit a harmful comment that would then be returned in the users page and executed.

Laboratory 2

When we submit this form and go back we can see that the payload succeded and we got execution.

When searching for Stored XSS vulnerabilities, our attention should be directed towards identifying functionalities within the web application that have the capability to store our malicious payload. This payload would then be executed when a user interacts with the specific function such as opening comment field.

DOM based XSS

Moving on to the final type of XSS, known as DOM-based XSS, there is additional information we need to cover in order to gain an understanding of this concept. Specifically, it’s essential to familiarize ourselves with the terms “sink” and “source.”

In the context of DOM-based XSS, a “source” refers to the origin of user-controlled data that gets processed by the web application. This data could come from various sources, such as the URL query parameters or user input fields.

On the other hand, a “sink” signifies a point within the application’s code where the user-controlled data is utilized in a way that could lead to the execution of malicious code. This could be within JavaScript functions, DOM manipulation, or other similar processes.

In DOM-based XSS, the vulnerability arises when the user-controlled data from a source is improperly handled and then flows into a sink, allowing the execution of harmful scripts within the user’s browser environment. Understanding these concepts of source and sink is crucial for effectively identifying and mitigating DOM-based XSS vulnerabilities.

In order to test for DOM XSS we need developer tools and a browser of course and then we need to go through each source and test it manually.

First as guide said we need to look and find DOM vulnerability. Luckily this lab gives us search functionality so we can play with it. First i will try to submit classical <script>alert(1)</script> payload.

Laboratory 3

We can see here that our payload got reflected inside the <img src=> tag so we first need to escape this tag and create our payload i used “><img src=x onerror=alert(1)>

And we got our pop-up!

Conclusion

Absolutely, the explanation I provided earlier was intended to offer a basic introduction to XSS concepts. If you’re looking to delve deeper into this topic and gain more comprehensive insights, I highly recommend engaging with hands-on exercises available on platforms like https://portswigger.net/. This platform offers a wide range of interactive labs and challenges that allow you to practice and enhance your understanding of XSS and other web security concepts.

See you in the next article and happy hacking!