Cross-Site Scripting (XSS)

Hello, first of all, thank you for your great responses and feedback, Let’s start with the first topic of this series which will be my favourite one, Cross-Site Scripting commonly known as XSS. So this is how it’s going to be, we’ll discuss what XSS is in both theoretical and practical ways, but one thing that we’ll discuss here that you won’t find on any other web security courses is how XSS and its types look like in a piece of code, which will help you in source code review assessments and will make your job much easier.

What is Cross-Site Scripting?

A cross-site scripting (XSS) attack injects malicious code into vulnerable web applications. XSS does not target the application directly. Instead, XSS targets the users of a web application. A successful XSS attack can cause reputational damages and loss of customer trust, depending on the scope of the attack. XSS attacks can reveal session cookies, which allow cyber criminals to impersonate real users and use their accounts.

How does an XSS attack work?

Cross-site scripting is when an attacker manipulates a vulnerable website so it returns malicious scripts to the user. This process typically involves JavaScript, but an attacker can use any client-side language. XSS primarily targets JavaScript due to the language’s integration with many browsers.

The weaknesses that allow XSS attacks to occur are widespread. XSS attacks can exploit vulnerabilities in different environments – examples include Flash, VBScript, JavaScript, and ActiveX. The ability to exploit widely used platforms makes XSS attacks a severe threat.

Types of XSS attacks

Reflected XSS Attacks
Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Stored XSS Attacks
Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

DOM-based XSS Attacks

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

Reflected XSS Code Example

The following definitions and examples were provided by Owasp project:

The following code segment reads the eid parameter from the HTTP request and displays it. There is no validation in the code to verify that that value of eid is alphanumeric text. An attacker can replace this value with malicious source code, and it will execute in the browser.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

The danger of this vulnerability is that attackers can email the URL with the malicious code to a user and cause them to click it, thus running malicious code on their own device.

Stored XSS Code Example:

The following code is a database query that reads an employee’s name from the database and displays it. The vulnerability is that there is no validation of the value of the name data field. If data in this field can be provided by a user, an attacker can feed malicious code into the name field. This malicious code will then be stored in the database, and whenever the name is displayed in a browser, the malicious code will execute.

<%…
 Statement stmt = conn.createStatement();
 ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
 if (rs != null) {
  rs.next();
  String name = rs.getString("name");
%>

Employee Name: <%= name %>

404 page XSS Attack Code Example

Consider a traditional 404 error page that displays the URL the user attempted to access and informs the user that it does not exist.

<html>
<body>
<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>
</body>
</html>

Because the code does not validate the REQUEST_URI, an attacker can manipulate this data value to execute a malicious script. Attackers can use this, for example, to hijack a session cookie.

http://example.com/<script>alert("TEST");</script> The result is: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Exploiting Cross-Site Scripting

Now, we’re done with the theoretical explanation of XSS, now let’s move to the most interesting part which is going to be how to exploit web applications vulnerable to XSS. As I mentioned in my series introduction post, you need to sign up at PortSwigger’s Academy if you haven’t done that click here. They also got a blog post for cross-site scripting do check it out.

Reflected XSS Labs
LAB 1:

After Signing up go to All Labs sections and browse to Cross-Site Scripting Arz has done a great walkthrough for XSS Lab 1.

LAB 2:

This lab contains a reflected cross-site scripting vulnerability in the search blog functionality where angle brackets are HTML-encoded. To solve this lab, perform a cross-site scripting attack that injects an attribute and calls the alert function.

Click on “Access Lab” to start your instance, you’ll see a blog page like this:

search anything into the search bar and you’ll observe something that it’s been reflected inside a quoted ” ” attribute, to escape the quoted attribute we’ll have to adjust our payload like this:
"onmouseover="alert(1) you can do this with Burp after intercepting the search request and modifying the search request with our payload. You will get an alert box of “1” when you mouseover on the search bar, and congratulations you solved this lab!

Stored XSS Labs

LAB 1

This lab contains a stored cross-site scripting vulnerability in the comment functionality. To solve this lab, submit a comment that calls the alert function when the blog post is viewed.

After accessing the lab you’ll see a blog post like this:

Click on “view post”‘ and then you’ll be redirected to a blog post, then browse through the comments section and modify the comment section with this payload <script>alert("xss")</script> and since the comment section was vulnerable to Stored XSS your payload will get stored in the comment and will keep seeing alert whenever you refresh the page!

LAB 2

This lab contains a stored cross-site scripting vulnerability in the comment functionality. To solve this lab, submit a comment that calls the alert function when the comment author name is clicked.

After clicking on “Access Lab” you’ll see a blog page just like the last Stored XSS challenge that we did, but in this challenge, we have to make the application show the alert box when clicking on the author’s name, and we’ll also have to modify our payload in the “Website:” field because if you observe there when author name is clicked it redirects us to the website URL we put, so to make it appear dialogue box on when clicking, what JavaScript event we’ll have to use to make it like that? any guesses?

We’ll use onclick event to make it appear alert box when clicked. After posting the comment click on that comment author for me it’ll be “darth”

DOM-Based XSS Labs

LAB 1

This lab contains a DOM-based cross-site scripting vulnerability in the search query tracking functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from location.search, which you can control using the website URL.

To solve this lab, perform a cross-site scripting attack that calls the alert function.

After accessing the lab you’ll see a search bar, search with any string,

after clicking on the search button, go to Inspect Element (F12), you’ll see that your random string has been placed inside an img src attribute. So we’ll use "> to breakout from that attribute and our payload will be:
"><svg onload=alert(1)>

Conclusion

So, we’ve covered the basic theoretical and practical knowledge to understand What XSS vulnerability is and how to exploit it hands-on, we covered only the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.