Let’s start by setting up the lab environment needed for practicing XSS, and upcoming articles will cover the theory and step-by-step approach for identifying the vulnerability.

Kurukshetra- An XSS-vulnerable app by design

In the author’s own words, “Kurukshetra is a vulnerable lab geared towards practicing XSS challenges.”

The app’s motto is to give you hands-on experience in identifying the XSS vulnerability in different ways and also keep you updated about the theory and basics needed.

Check out the GitHub - D4rk36/Kurukshetra for more info.

All the content here provided is only for the educational purposes. Authors, Application Creators or Web Site Owners are not responsible for misuse of your knowledge. You are responsible for your own actions!.

Kurukshetra app isn’t for production use! Only for testing and learning on a host machine.

Preparing Environment

A couple of things must be done to start working on the “Kurukshetra” XSS vulnerable application.

1. Docker & Docker Compose must be installed and working
2. A working OS(Linux/Windows/Mac) with network connectivity
3. Git installed

Feel free to skip to the next section if all the required tools are pre-installed.

For users whose Docker is not installed, please visit the Get Docker page and follow the instructions as specified.

Once installed, make sure the Docker is working. The output of the command should be something similar to the below output.

Docker check:

docker --version

Output:

Docker version 20.10.17, build 100c701

After installing the Docker, you can set up the docker-compose by referring to the given link. It is needed to build up the environment on the go.

Make sure the docker-compose is working by verifying the version information.

Docker Compose check:

docker compose version

Output:

Docker Compose version v2.12.2

Hopefully, “git” is installed on most of them. If you think you don’t have one, just go ahead and install it from your package manager or the link given below.

Git - Download

Lab-Setup - “Kurukshetra” Application 💻

Let’s clone the application from the GitHub repository and copy it onto your system.

git clone https://github.com/D4rk36/Kurukshetra.git

Navigate to the downloaded directory.

cd ./Kurukshetra

Inside the directory, you will find a “docker-compose.yml” file, which contains the instructions for running the application. You have to run “docker compose up” to bring up the environment.

docker compose up

Once the environment is up, let’s verify by accessing the app environment by clicking on the following URL: http://localhost:8066/ or paste it into your browser.

💡In case you are facing any errors. Please re-verify all the steps from the docker installation.

The page will be displayed below.

Bringing up the Docker instance might take a couple of minutes, based on your network speeds. You should also be able to see the log as displayed below while starting up.

During any time in the lab, you can run “Ctrl - c” to stop the running environment.

Additionally, to completely remove the “Kurukshetra” containers running from your system, run the remove command from the same directory where the docker-compose.yml file is present.

docker compose rm

Now that our lab environment is up and working, you are good to proceed to the next step of identifying the XSS vulnerabilities.

Summary

The setup is straightforward for users who are familiar with Docker. For other users who are new to docker, you might need to get adapted to using it. Most of the tools are now being containerized to avoid the installation process. Just download and run with docker.

Ensure your lab environment is working to jump-start learning about cross-site scripting vulnerability. The next articles will cover types of cross-site scripting vulnerabilities and techniques used to identify them. 😃

Additional References for XSS Practice:

• XSSy Labs

A single technique cannot mitigate XSS vulnerability completely. Using the right defenses can help in preventing XSS attacks.

One of the best practices is “Defense-In-Depth”, Enabling multiple layers of defense so even if a layer fails, other layers of protection can minimize the impact of an XSS attack.

Use Frameworks

In modern development practices, developers like to code faster and avoid recreating the wheel.

Rather than building applications from scratch, using the frameworks can protect the application from lots of vulnerabilities. As security features are in-built into frameworks and just need to enable.

For example input validation checks, XSS prevention, preventing access control issues, etc. (Some PHP frameworks include laravel, CodeIgniter,etc.)

Additionally, these frameworks do address the security vulnerabilities when discovered, all you need to ensure is that you are using the latest version of the application framework.

Validate Client Data

One of the most crucial steps is to validate each and every input received from the client.

As we have demonstrated throughout our articles, any data coming from the client side can be modified with the help of intercepting proxies.

For the same reason, each and every piece of data coming from the client must be validated then must follow through next steps of verification.

Output Encoding

Output encoding is one of the techniques used to take user-controlled data and safely display it without interpreting it as code, and considering it as text.

Below is an example XSS payload.

<script>alert(document.domain);</script>

HTML-encoded text of XSS payload will be displayed as shown below.

<script>alert(document.domain);</script>

• “<” changed to “<”
• “>” changed to “>”

As the browser parses HTML, JavaScript, CSS, and URL differently. Each much be encoded depending on the requirements.

Another good example in PHP, the “htmlspecialchars” function will convert the “<” less than, “>” greater than symbols to HTML entities such as “<” for less than, “>” for greater than respectively. This again makes the application treat all as text without breaking the syntax.

URL, HTML, JavaScript, and CSS can be encoded.

Sanitization

In some cases, the users need to retain HTML code as it is. In this case, the output encoding will break the document structure.

To retain the data as it is, the sanitization technique is used.

As part of the sanitization, it produced a new HTML document that contains only the “safe” or allowed HTML tags. This prevents XSS, this is performed in combination with the whitelist and blacklist approach.

Example, In PHP we used a “strip_tags” function is used to filter out all the HTML tags, the “addslashes” function escapes the special chars like a quote, and a double quote with backward slashes to retain it as text without breaking code syntax.

XSS Header

The X-XSS-Protection response header is one of the features used to prevent the reflected XSS from executing.

Below is an example of enabling the XSS protection header by completely blocking script execution.

X-XSS-Protection: 1; mode=block

The following can be ignored if the strongly protected “Content-Security-Policy” is being used.

HTTPOnly - Cookie Attribute

This is another cookie flag that helps in reducing the XSS impact. Enabling the “HTTPOnly” flag for session cookies can prevent the javascript code from accessing it.

Content-Type

Content-Type is one of the response headers which specifies the type of content delivered. It is recommended to set the script content to “application/json” than “text/html”

Content-Type: application/json

Setting the content type to “application/json” prevents the execution of script tags.

Content Security Policy (CSP)

Content Security Policy is an added layer of security protection. This helps in detecting and mitigating the XSS and other code injection attacks.

CSP instructs the browser on how to deal with the content. On CSP-enabled websites, it becomes very hard to exploit the XSS vulnerability.

A Content-Security-Policy header is appended by the server with policy configuration.

Content-Security-Policy: default-src 'self'; img-src *; script-src userscripts.example.com

Above is an example of CSP, instructing the browser to permit only content from the same site, images from anywhere, and execute scripts only from “userscripts.example.com”

Whitelisting rather Blacklisting

Whitelisting or allowing a known good is an approach of letting only what you trust and rejecting all the rest.

Whitelist is one of the supporting steps adding to all the above defense layers. Even in the case of unknown payloads as well whitelist defends well.

Let’s say allowing the trusted characters upper case, small case letters, numerics, and some special characters based on need.

Limit usage of the blacklist only for reasonable business requirements.

Use Web Application Firewalls (WAFs)

Configuring and using Web Application Firewalls, protects web applications from a wide range of attacks like XSS, Brute Force attacks, Denial of Service attacks, Malicious input filtering, etc. a lot more.

Say AWS WAF, Cloudflare WAF, etc.

Additional References:

More information on mitigating XSS attacks can be found on the OWASP site.

• Cross Site Scripting Prevention - OWASP Cheat Sheet
• DOM based XSS Prevention - OWASP Cheat Sheet

This post will start with what an XSS vulnerability is and then will try to analyze the XSS challenges on the vulnerable app.

Ensure your lab is up and running if you have not set up your lab yet.

What is Cross-Site Scripting?

Cross-site scripting is also referred to as “XSS.”

Cross-site scripting is an application flaw that takes a malformed input from the client (i.e., Browser or Proxy) and the server without verifying appends, then sends the input as it is back in an HTTP response without proper validation.

If you are not familiar with what HTTP is, check out the following HTTP Basics Tutorial to help you get started.

The malformed input lets an attacker inject malicious code(like HTML or JavaScript ) into the server’s HTTP response and can change the application’s behavior.

XSS vulnerability can be used to deface the landing pages of websites, which is called defacement. Stealing user sessions and gaining access to user accounts. Secretly log and monitor the victim’s keystrokes, Control the victim’s web browser, retrieve user-saved passwords from the browser, Or even redirect victims to a malicious page, and much more.

Additionally, XSS, combined with other security vulnerabilities, makes the attack more severe.

In total, there are three types of XSS vulnerabilities, as detailed below.

Stored XSS - Walkthrough

After setting up the lab, Visit http://localhost:8066. The vulnerable Kurukshetra application should be loaded as shown below.

Take some time to understand how the application functionality works before we start assessing.

Try adding a simple “HelloWorld” string, and check how the input is appended to the below comments.

From the above behavior, we can understand that the given input is stored and displayed back.

💡 This is one of the signs where you can check if it can accept any malformed input as well. Let’s go ahead and try out the classic XSS payload.

*<script>* tag in HTML is used to extend the page capabilities and include interactivity, which will be used to test if it is possible to inject the code snippets.

alert() function in JavaScript is used to display the popup window.

I will insert the script code to make things visually appealing, as displayed in the image below. When we see the popup window, it means our script code got injected and executed successfully.

Inject the script code in the input field and click the “Submit” button.

Immediately, a popup message will be displayed, as shown below, to confirm our script execution.

Click the “OK” button, and the application usually loads the page.

To further understand our script injection, Right-click, select “View Page Source,” and then search for the above-injected script code.

The script code was injected as it was given. This confirms we could inject the malformed script code in the user input field.

Revisit the following page: http://localhost:8066/ch01.php. Observe the popup message will be displayed again.

This is what a stored cross-site scripting vulnerability is. Once the malformed input is injected, it will be executed every time the page is loaded. If multiple users are using the same application, then the script code will also be executed for each and every individual victim as well.

Attackers can use the above type of functionality to deface the page and completely change it based on malicious intent using JavaScript and HTML code. Similarly, write a malicious piece of code to steal all the authenticated users’ session tokens and reuse it for accessing the user’s account without passwords. Or even redirect victims to a malicious page, etc.

🎉 This type of behavior is called Stored Cross-Site Scripting vulnerability. Yay! We found a stored cross-site scripting vulnerability and solved XSS Challenge 1.

About XSS Payloads

The above example demonstrates a simple XSS code snippet.

You might be wondering how I would ever be able to create those script payloads, and I am not even familiar with JavaScript and that stuff.

Well, lots of security researchers have already done most of the work related to payloads for you. You all need to know when to use it and what needs to be changed based on your scenario. As the experience grows, you will be able to write your own custom payloads for yourself.

Here is a repository of “PayloadsAllThings” that you might need to bookmark it.

You will find a lot of information on different vulnerabilities and their payloads. Just search for “XSS Injection”.

Go ahead and try out with a wide range of XSS payloads and see how the application behaves.

💡Practice Makes perfect.

Clean up - XSS Data

It might become annoying if we keep getting too many popups, which can even impact usability.

Click on the “Purge Database” button to eliminate the annoying popups and start fresh.

Conclusion

I hope you learned about the different types of cross-site scripting vulnerabilities. Organizations are using the most secure coding frameworks and best practices, but they might still miss out due to complex application ecosystems, which can give way to XSS vulnerabilities. The above example demonstrates how improper coding practices can be used to exploit stored XSS vulnerabilities, and fixing them as soon as possible as part of security assessments can reduce the huge impact on production systems.

In this article, we shall learn about the reflected XSS and how it differs from the stored XSS.

Before we start, ensure the lab is running if you have not set up your lab yet.

Types of Cross-Site-Scripting (XSS)

How Reflected XSS Work?

The server processes the malicious input code supplied from the client side, and the same malicious code is injected and then returned to the client in an HTTP response without proper validations.

The browser renders the response content, assuming it was supplied by the application server, which can be trusted, and the injected malicious code also gets executed.

The significant difference that can be observed when compared to stored cross-site scripting is, in reflected XSS, the malicious code is just appended back in the HTTP response and executed immediately. It is not stored anywhere in the database.

For the same reason, the impact of reflected XSS is reduced compared to the stored cross-site scripting vulnerability.

Practicals - Reflected XSS

Post setting up the lab, visit http://localhost:8066. The application should be loaded as shown below and Navigate to “XSS Challenge 2.”

Before you start assessing, take some time to understand how the application functionality works.

Let’s go ahead and give it a try with the similar payload used in the stored XSS.

Once appending the payload, click the “Submit” button, as shown in the screenshot below.

Immediately observe the alert pop-up message, which will be displayed below.

Click “OK” and observe the page loads normally.

To verify and confirm the vulnerability, right-click and select “view page source” and search for the above-injected payload.

The proof-of-concept script code aligns correctly with the HTML response received, and all the characters are displayed back as given in the input field.

Yay!! Now, we can confirm we have successfully exploited the reflected XSS.

Now, a point to remember here is that as this is not stored in the database, it gets executed only when the malicious code is injected. At all other times, the application usually behaves as expected.

In Stored XSS, the malicious payload gets executed whenever any user visits the injected application functionality.

Summary

This article covered how to identify reflected XSS and how it works, including reusing the same XSS payload without much tweaking.

Keep learning!! :D

Before we start, ensure the Kurukshetra lab is up and running if you have not set up your lab yet. Feel free to refer back to the below link.

We walked through stored and reflected XSS in a previous couple of articles. In today’s article with those foundations, let’s dive into the practical labs and start learning.

Practicals - Reflected XSS

Post setting up the lab, visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 3”.

Let’s try it with the XSS payload used in our previous articles and observe how the application behaves.

Payload Try 1: Classic

Output:

From the above observations, the application no longer gives pop-up messages but instead prints out the partial string from our given payload. Which indicates that our XSS payload is no longer working.

To evaluate further, click “View page source” to understand how our injected payload string is loaded in the HTML response body.

I can see that there is some kind of filter kept in place by the application that removes the word “script,” which breaks the HTML syntax, and the browser treats the following data as just text and displays back the partial string.

Can we assume that the vulnerability is fixed? No

The developer leveraged a technique called “Blacklisting” to secure the application from exploiting the XSS vulnerability. However, this approach has limitations, and it can still be bypassed.

1. TIP - 1

   HTML is case-insensitive, which means we can try it by changing it to upper case or small case letters or even combining small and upper case letters together, as given below.

   

Payload Try 2: Case-Insensitive

Output:

It looks like this technique also failed. The application seems to be filtering out the lowercase and uppercase script tags that were inserted.

1. TIP - 2

   Javascript functions can be triggered for execution in multiple different ways, not necessarily that only the HTML script tag is needed all the time.

   One of the ways to execute the javascript “alert()” function is using the HTML SVG tag, which is generally used for loading the vector graphics file on the HTML pages.

   Example:

   

   The HTML Attribute “onload” is one of the special words used to control the behavior.

   In the above example, the HTML attribute “onload” is assigned to a javascript function “alert()” which runs immediately when the HTML SVG tag is loaded.

   Let’s go ahead and check out the things in action.

Payload Try 3: HTML5 Tags

Output:

This attempt also failed, as the application filters out multiple HTML tag strings. i.e., svg, script, img, etc.

From the above example, we can see that the HTML attribute “onload” is being loaded without any filters and displayed back as keyed in.

1. TIP - 3

   Not all HTML tag strings can be blacklisted. Some might break the entire HTML page itself and application functionality.

   For example, the HTML Body tag is needed most to load the page’s content. HTML Style tag, which is used to beautify the page, etc.

   We shall improvise the previously used payload with the HTML Body tag.

Payload Try 4: HTML5 Tags

Output: pop-up message

yay!!! 🎉 This time, our XSS payload worked, and the application displayed the pop-up message.

To further confirm, Click “OK,” then right-click and select the “View page source” code to see how our payload was injected and aligned with the HTML response code.

You should be able to find out that our injected payload is rightly aligned, HTML attribute onload event is triggered immediately. Therefore it indeed executed the javascript code.

Through this, we have successfully solved the XSS challenge 3.

Summary

In this article, we learned how poorly implemented validations can still be bypassed by improving the payload and trying different possible combinations. The blacklisting approach is helpful for a quick fix but is not foolproof, which must be updated whenever a new payload has been reported. Additionally, we covered many tips and techniques that can help you improvise your XSS identification skillset.

Keep learning!! :D

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

XSS Challenge Walkthrough

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 14“.

The above input field labeled “Try your XSS payload here?” is displayed.

Key info is in the classic XSS payload, which has been used throughout while testing for XSS, and click on the “Submit” button.

XSS Payload

Output:

The application doesn’t display any info on the page. Right-click and select “View page source” to analyze how the appended payload got reflected in the HTML response.

Viewing HTML Source

In the above output, the javascript “alert()” function is missing.

Let’s go ahead and give it a try with an HTML body tag-based XSS payload to confirm if the “alert()” function is being filtered in the script tag itself or from all inputs.

XSS Payload 2

HTML Source Output:

From the above output, it can be confirmed that the JavaScript “alert()” is being filtered out in all the inputs given.

In the current scenario, the JavaScript function “alert()” is commonly used by attackers to execute arbitrary code. This type of blacklisting approach used to prevent XSS attacks involves identifying and blocking specific strings or functions that could be used by attackers to inject malicious code into a web application.

The major drawback of this approach is the developers need to update the impactful functions/commands to the blacklist continuously.

By removing or disabling these functions, web developers hope to prevent attackers from exploiting XSS vulnerabilities in their applications. However, this approach is often ineffective, as attackers can simply use alternative methods to execute their payloads, such as using “confirm()”, “prompt()”, “console.log()” or constructing their own functions.

Demo – XSS Challenge 14

For the following demo, we will be using the JavaScript “confirm()” function.

The “confirm()” function in JavaScript is a built-in method that displays a dialog box with a message and two buttons: “OK” and “Cancel”. It is often used to prompt the user for confirmation before performing a potentially destructive action, such as deleting data or navigating away from a page.

I will go ahead and replace the “alert()” function with the “confirm()” function and update our XSS payload accordingly.

Confirm XSS Payload

Now, let’s go ahead and input the above XSS payload in the “XSS Challenge 14” page.

Immediately after clicking on the “Submit” button, a pop-up message will be displayed, as shown below.

The above screenshot demonstrates the javascript “confirm()” prompt. Which looks very similar to the “alert()” dialog box with the added button “Cancel” as a difference.

This also confirms that the application is vulnerable to cross-site scripting vulnerability.

To verify further, click on the “OK” button in the dialog prompt, right-click, and select “View page source”.

Viewing HTML Source

Observe the injected XSS payload is reflected in the HTML source and executed perfectly.

By this, we can confirm that XSS challenge 14 is successfully solved.

Summary

In this article, we demonstrated one of the impacts of the blacklisting approach where the “confirm()” or other alternative javascript functions can be abused by attackers in XSS attacks, as they can use it to trick users into executing arbitrary code or disclosing sensitive information.

To prevent XSS vulnerabilities in web applications, it’s important to validate and sanitize all user input and implement appropriate content security policies.

Congratulations to all our readers who completed the learning XSS with the Kurukshetra series! I hope that you enjoyed our vulnerability series and learned a lot in the process. If you’d like to learn more or have any feedback or suggestions, please don’t hesitate to reach out. We’d love to hear from you!

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

XSS Challenge Walkthrough

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 13”.

An input field labeled “create a link?” is displayed.

1. In the above input field, give a URL (say “http://localhost:8066/ch13.php“) to which you want the application to create a link for us.

2. Click on the “Submit” button.

Observe the application generated an HTML link for the given URL displayed above.

From the above application, we can understand that with any given input text, the application generates a clickable HTML link.

Feel free to try out all the XSS techniques learned so far. You should be able to solve this challenge right away. 😃

XSS in Anchor Tag

Going ahead, we will cover how the HTML anchor tag can be used to craft a customized XSS payload.

From the above HTML link generated, right-click and select “View page source“, then search for the appended text in the HTML response.

From the above screenshot, we can see the given input text is placed between the “href” in an anchor tag, and the same text is placed again as the name of the anchor tag.

Output:

I will go ahead and create a crafted XSS payload which is generally attackers used to trick victims into a trap.

XSS Anchor Payload

Breaking down the above XSS payload in detail:

1. Leaving the “href” tag empty without a link and closing it with another pair of double quotes to ensure HTML syntax is maintained.
2. The “onclick” is an HTML5 attribute used within HTML tags that specifies a JavaScript function to be executed when the user clicks on the element. In this case, the function being executed is “alert(‘xss')“, which displays the alert dialog with the message “xss“.
3. “Click for XSS POC” a text message will be displayed for the anchor tag.
4. Closing the HTML anchor tag with “</a>“.
5. The start of the HTML comment with “<!–” then comments out all the code after this is parsed as text with no special meaning.

Overall the above XSS payload creates a clickable element that, when clicked, will execute a JavaScript alert dialog with the message “xss“.

XSS Demo

Go ahead and give it a try with the above-crafted XSS payload.

In the above screenshot, key in the XSS payload and click on the “Submit” button.

From the given payload, the application generates an HTML link and displays it, as shown above. Now click on the “Click for XSS POC“.

Immediately, a pop-up box is loaded, and a message named “xss” is displayed. Thus, we have solved XSS challenge 13.

Note: One of the many techniques is covered here. The XSS payload can be crated in multiple other ways as well.

Lastly, right-click and select “View page source” to understand how it’s reflected back in the HTML response.

From the source code, the XSS payload is appended inside the anchor tag, and all the HTML code is commented out after the anchor tag.

As mentioned above, the XSS payload allows the attacker to execute arbitrary JavaScript code on the victim’s browser when the element is clicked. This can result in the theft of sensitive information, such as session cookies or user credentials, or the takeover of the victim’s account.

By this, we have successfully solved the XSS challenge 13.

Summary

The following article demonstrates how the customized XSS payload allows an attacker to execute arbitrary JavaScript code.

The code also includes an HTML comment “<!--”, an attempt to prevent the malicious code from being easily detected. This technique is known as “comment hiding”, and attackers often use it to obfuscate their payloads and evade detection.

To prevent XSS attacks, input validation and output encoding should be applied, and a Content Security Policy can also be used to mitigate the risk of the above XSS vulnerability.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

‌XSS Challenge Walk-Through

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 12“.

1. Click on “XSS Challenge 12” on the left side menu.
2. Input the XSS CSP bypass payload which was used in the previous demonstration and will observe how the application behaves.

1. Click on the “Submit” button.

Application Output:

1. The application loads normally and displays a text message, “Your XSS Payload”, without any pop-ups.

2. Right-click and select “View page source“, then search for the injected XSS payload. The HTML response code will be displayed below.

1. At the bottom of the HTML response, the XSS payload was injected as provided and also aligned rightly with the HTML syntax. But the javascript code wasn’t executed.

2. You might have guessed right! The application’s Content Security Policy might be blocking our payload. Let’s go ahead and review the current CSP policy set.

Analyzing the CSP policy

On the following XSS challenge page, Press the “F12” button on your keyboard and a new browser debugger window will be launched.

In browser debugger mode navigate to “Console” and observe the CSP violation messages will be displayed as shown below.

As expected, the browser blocks script code due to CSP violations and prevents execution.

Will try to understand the application CSP policies, In debugger mode switch to “Network” and reload the challenge page.

Select the “ch12.php” page and scroll to the “Response Headers” section. Observe, the Content-Security-Policy header which was set by the application server.

Understanding the CSP Policy Implemented

Breaking down the CSP rules:

1. “script-src“: This directive restricts the sources from which scripts can be loaded. In our case, it allows scripts to be loaded only from the same origin as the page (i.e. “self“),
2. Secondly, the scripts can be loaded from https://facebook.com, https://google.com, any HTTPS sources (“https“), the “data” scheme, and any source (*).
3. child-src: This directive restricts the nested frame contents from loading.
4. report-uri: This directive specifies a URL to which policy violation reports should be sent.

Overall, CSP policy allows scripts to be loaded only from trusted sources, including the same origin as the page and specific external sources like Facebook, Google, and other HTTPS domains.

Why is “data:” directive-based XSS not working?

Content-Security-Policy: script-src 'self' https://facebook.com https://google.com https: data *; child-src 'none'; report-uri /Report-parsing-url;

This is because the CSP policy explicitly disallows scripts to be loaded from the “data:” scheme, except for the page’s own origin (i.e., ‘self‘ same domain).

In the script-src directive, the “data” scheme is listed as a source along with the wildcard *. However, the wildcard “*” here does not override the previous ‘self’ directive, meaning that scripts can only be loaded from the page’s own origin via the “data:” scheme but not from the user-injected external scripts.

Therefore, the “data:” scheme tries to load an external script, which was blocked by the CSP policy, and the “alert(‘XSS')” payload doesn’t execute.

Is it possible to bypass the limitations set?

Well, the more you get familiar with the technologies, the more options you will be able to find.

Closely observe there is another directive named “https:” in script-src. It is configured in such a way that scripts can be loaded from any of the HTTPS sources.

Content-Security-Policy: script-src 'self' https://facebook.com https://google.com https: data *; child-src 'none'; report-uri /Report-parsing-url;

Yes, one option is setting up your own HTTPS site and pushing an XSS javascript file onto the server and using it for testing purposes.

It’s a long process, but I will be using the publicly available one for the proof of concept.

Security researchers from Cure53 have provided the needed resources that can be directly used for security assessment. The reference link can be found below:

https://github.com/cure53/H5SC

Demo – CSP Bypass

Let’s use the remote “https” javascript payload taken from the H5SC report, the payload URL is given below.

https://html5sec.org/test.js

Javascript source code in the “test.js” file contains only the alert() function as given below. If worked, will display a pop-up message “1“.

alert(1)

Will append the above URL to the script code so we can key it into the input field.

Visit the XSS Challenge 12, paste the above payload in the input form field, and click on the “Submit” button.

Immediately observe a pop-up box will be loaded with the message displaying “1”. By this we can confirm we have successfully exploited the misconfigured CSP.

In all XSS payloads, we used “alert(‘XSS')“, an alert() function to display text message ‘xss‘ so far, in the above case, the same alert function was used to display the numeric digit in a pop-up window.

Click “OK“, then Right-click and select “View page source” to verify the injected payload.

Post review can confirm that the XSS payload reflected as given and executed successfully.

By this, I can say that XSS Challenge 12 has been successfully solved. Yayy!!! 🎉.

Use of the “https” sources from any domain can be problematic from a security perspective, as it allows arbitrary javascript code to be loaded from any external source and executed directly on the page, which is generally abused by attackers to perform cross-site scripting (XSS) attacks.

\

Summary

A Content Security Policy (CSP) can prevent cross-site scripting (XSS) attacks by limiting the sources from which scripts can be loaded.

However, if a CSP policy is misconfigured, it can potentially allow XSS attacks to occur. In the above case, allowing the javascript code to load from any remote “https” resources can enable attackers to inject malicious scripts directly into a web page, potentially leading to XSS attacks.

Therefore, a well-configured CSP policy can block all XSS attacks, and it is important to ensure that CSP policies are correctly configured and free from insecure directives.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

‌XSS Challenge Walk-Through

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 11“.

1. Click and select the XSS Challenge 11 from the Kurukshetra app.
2. Fill out our classic XSS payload in the given input field.
3. Click on the “Submit” button.

Output:

1. The application loads the page as usual and displays a text message, “Your XSS Payload” without any pop-ups.

2. Right-click and select “View page source“, then search for the injected XSS payload. The HTML response code will be displayed below.

1. At the bottom of the HTML response, the payload was injected as provided and also aligned rightly with the HTML syntax. But our javascript didn’t execute.

What might be happening in the background?

In the above screenshot, if the HTML output encoding is used, then the output must be displayed as “<” or “>” etc. Doesn’t look so. Also, if slash-escape is being used, then the prefix slashes must be displayed. Even that is not present.

Seems like our XSS payload is injected rightly but unable to execute. A possible guess is there is some sort of other XSS defense in place.

The web application might have enabled the Content Security Policy or other XSS protection headers. Let’s verify and understand what’s happening in the background.

On the following XSS challenge page, Press the “F12” button on your keyboard and a new browser debugger window will be launched.

In browser debugger mode navigate to “Console” and observe the CSP violation messages will be displayed as shown below.

Web Browser clearly indicates some script code tried to execute but it’s not compliant with the CSP policy set. Therefore it was blocked by the browser from executing.

In debugger mode, switch to “Network” and reload the challenge page.

Select the “ch11.php” page and observe on the right side in “Response Headers” the Content-Security-Policy header, which was set by the web application.

Understanding the CSP implementation

Breaking down the CSP policy defined by the web application

1. script-src: specifies the sources from which scripts can be loaded.

• https://facebook.com: allows scripts to be loaded from the domain facebook.com.
• https://google.com: allows scripts to be loaded from the domain google.com.
• unsafe-eval: This allows the eval() javascript function and the Function() constructor to execute dynamically created script code.
• “data:”: allows the execution of inline scripts (one which is directly embedded in the HTML) with data URIs.
• “http://*”: Wildcard “*” means allows scripts to be loaded from any HTTP sources (poses a security risk).

2. child-src: specifies the sources from which nested browsing contexts (such as iframes or embedded objects) can be loaded. In this case, ’none’ specifies that no sources are allowed.

3. report-uri: specifies the URL where a browser should send violation reports if the policy is breached.

Overall, this CSP allows scripts to be loaded from trusted domains (facebook.com and google.com), as well as inline scripts and HTTP sources (which are generally not recommended due to security risks). It also allows the use of eval() and Function(), which can be used to exploit XSS attacks. Additionally, it prohibits the loading of nested browsing contexts and specifies a URL to which violation reports should be sent.

The above CSP policy clearly has some limitations and is not foolproof. That said, “data:” provided an entryway for us to try creating XSS inline scripts or load the XSS script code from any of the HTTP domains, tricking the application by loading from Google, etc.

Exploiting XSS using Inline scripts

(i.e., using data directive)

Let’s go ahead and find a way to bypass the misconfigured CSP defenses. For the following demonstrations, we will be using the script-src’s “data:” attribute to craft an XSS payload.

From the documentation script source “data:” can be used for inserting inline scripts directly into HTML documents.

The “data:” URI scheme allows data to be embedded directly in a URL or document, using a specific syntax that includes the “data:” prefix followed by the MIME type of the data, and the data itself.

Below is an XSS inline script using the “data:” URI scheme, which can be included directly, with the MIME type set to “text/javascript” and an “alert(‘xss’)” data.

Above code will pop up with an “XSS” message when the javascript code is loaded and executed directly on the page.

Visit the “XSS challenge 11” page.

Enter the XSS inline script code in the input field and click on the “Submit” button.

Output:

Immediately, we can see a pop-up message displayed on the web page. By this, we can confirm that we have successfully exploited the XSS vulnerability. :D

To further confirm, click on the “OK” message, then right-click and select “View page source”. Search for the injected XSS inline script code.

HTML Page Source:

Observe this time, our injected script code is reflected back as given without any output being filtered.

The execution script code confirms we have successfully solved the XSS challenge 11. Yayy!!!.

Use of the “data:” URI scheme for inline scripts can be problematic from a security perspective, as it allows arbitrary code to be executed directly on the page, which is generally abused by attackers to perform cross-site scripting (XSS) attacks.

Summary

A Content Security Policy (CSP) policy restricts the types of content that can be loaded by a web page. When implemented correctly, a CSP can prevent cross-site scripting (XSS) attacks by limiting the sources from which scripts can be loaded.

However, if a CSP policy is misconfigured or contains errors, it can potentially allow XSS attacks to occur. For example, if a policy includes insecure sources, such as “unsafe-inline” or “data:”, it can enable attackers to inject malicious scripts directly into a web page, potentially leading to XSS attacks.

Therefore, a well-configured CSP policy can block all XSS attacks, and it is important to ensure that CSP policies are correctly configured and free from insecure directives.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

‌XSS Challenge

You reached “XSS Challenge 10”. Great to see your consistent progress. In the past article, we covered how the XSS vulnerability does not always need to be exploited using the same parameter. XSS can also be looked at in other parameters, which might depend on the param, or it can also be an appending parameter.

Let’s get started with XSS Challenge 10. Visit: http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 10“.

1. Click and select the XSS Challenge 10 from the Kurukshetra app.
2. Will fill out some random string saying “ABC” in the input field provided.
3. Click on the “Submit” button.

Output:

Feel free to experiment with your XSS ideas before going ahead with the next steps.

Hope you have partially or successfully exploited it.

Viewing the Page Source

In the above screenshot, I have keyed the text “ABC” in the input field. Let’s verify how the text is being reflected back in the HTTP response code.

To do that, “Right-click” and select “View Page Source”, then search for the inserted string “ABC”.

Injected text is being reflected back at the bottom of the page, and this time, it’s inserted between the HTML div tags with double quotes appended.

Remember from the previous lessons, we can keep trying out the different XSS payloads, but at the same time need to gather the list of allowed characters as well which can help in crafting an XSS payload.

Going ahead, will be trying out all the payloads and narrow down to the allowed characters.

Payload 1 – Simple XSS

Browser Output:

Page Source – Output:

Closely observing the closing </script>, a “\” backslash is appended and turned the closing script to <\/script>. This breaks the HTML syntax, as it’s expecting the closing script tag.

About Slash-Escape

The backslash escape is a technique used to prevent special characters from being interpreted as code in web applications. Currently, this application is using the same to block XSS attacks.

The above technique is good when used in combination with multiple XSS prevention techniques. (i.e., Defense in Depth).

Also, note that in the above case, the backslash “\” is only being appended to the slash in the closing script tag, not for any other special characters, which is an indication of poor XSS mitigation.

TIP – 10 Try HTML tags that work without closing tags

Yes, as mentioned in the heading. Not all HTML tags need to have a compulsory closing tag, and there are some HTML tags that work even if the closing tag is not provided. (say <IMG>, <SVG> etc.)

This time for a change will go ahead and try the HTML image tag payload than using the same routine one.

XSS Payload – HTML Image Tag

Breaking down the above payload into detailed steps.

• “<img>” is an HTML tag used for embedding images on a web page.
• “src” is an attribute of the HTML “<img>” tag that specifies the URL of the image file from where it needs to be loaded.
• “x” is a random value assigned to the “src” attribute forcibly. As there is no image file named “x“, the browser will fail to display/load the image.
• “onerror” is another attribute of the “<img>” tag that is called if an error occurs while loading the image.
• “alert(‘XSS')” is a JavaScript function that displays an alert dialog box with the message “XSS”.

Putting it all together, when the web page containing this XSS payload is loaded in the browser, the browser will try to load the image file “x”. As the image file cannot be loaded due to non-existent, the onerror attribute is triggered and the JavaScript code alert(‘XSS’) is executed, which displays a pop-up message “XSS”.

Demo – HTML Image Tag XSS Payload I will go ahead and insert the “<img>” tag-based payload and verify how the application behaves.

Output:

Wow!! 🎉 an XSS pop-up message. This confirms that our payload worked.

Lastly, let us go ahead and further verify by viewing the page source. Click “OK”,

Right-click on the page and select “View Page Source“. Then, search for the injected string.

HTML Response

Observe, the payload is rightly aligned between the div tag and backslash and is no longer breaking the HTML syntax. By this, we have successfully solved the XSS challenge 10.

Summary

The following article covered one of the poorly implemented XSS fixes of escaping using backslash for special characters. That, too, only escapes the closing script tag. These limitations can be bypassed using HTML image tags and other ways. Therefore a “Defense-in-Depth” approach is needed to mitigate XSS vulnerability at multiple layers.

In today’s article, let’s check out how the XSS can also be exploited in hidden input parameter fields.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

The previous article covered how the limited character set can be leveraged to exploit the XSS vulnerability and why the single defense mechanism might not fully mitigate XSS vulnerability.

Practicals

Visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 9“.

The above page looks similar to the challenges we solved earlier.

Take some time and give it a try with all the XSS skills acquired so far before going any further.

As you guessed, I will go ahead and try out the classic XSS payload to verify how the application responds.

Payload Try 1: Classic

Output:

Input the XSS payload and click on the “Submit” button. Immediately, the application echoes out the output as given, and there are no pop-up messages this time.

This confirms that our payload didn’t work. Right-click and select “View page source” to understand how our payload is being reflected back in the HTML response.

HTML Page Source:

Referring to the above screenshot, an HTML input tag named “xss” accepts the value and echoes out at the bottom of the code after encoding the special chars.

You might be thinking from the previous article that we used the built-in “HTML attributes” to bypass the encoding and execute the XSS payload. The same logic can be applied here.

A big No. Why?

Challenge 8 – HTML Output:

Challenge 9 – HTML Output:

The major difference between XSS Challenge 8 and Challenge 9 is that in Challenge 8, the encoded output was injected inside the HTML input tag, while in Challenge 9, the encoded output is displayed outside of form HTML tags.

As shown in the above challenge 9 screenshots, even though the HTML attributes can be injected, as they fall outside the HTML tags, the web browser would just consider it as text without any special flags.

Therefore, the XSS payload will not work here.

TIP – 9 Try other params or check for appending values

Yes, the XSS need not always need to be exploited in the same param value location, it could be checked on the other supporting param which may use the same value for processing. Also, it can be located in param values where input values are appended or depended on.

Challenge 9 – HTML source Output

Paying a bit more attention to our Challenge 9 HTML response, we can see there is another HTML input tag used of type “hidden”.

In HTML, the hidden input type stores pieces of user data without displaying it to the user on the frontend. Web browsers generally hide it, and you can find this data by viewing page sources or by using intercepting proxies like BurpSuite or OWASP ZAP.

Let’s go ahead and try the XSS payloads in the hidden fields.

It can be done in multiple ways, as covered in previous articles, such as using a browser debugger or using intercepting proxies. I will be using the BurpSuite proxy for usability.

Execution Steps

1. Configure and Launch the Burpsuite tool.
2. Navigate to the “XSS Challenge 9” page.
3. Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite “Proxy” -> “Intercept” -> Toggle the “Intercept is off” button to enable “Intercept on”.
4. On the Challenge 9 page, key in the random input value(say “Test XSS”) and click on the “submit” button.
5. The intercepted request will be displayed as shown below:

1. Observe that in line 22, the input param and its values are being passed in the request body section.

2. Replace the “hidden” param value from “Is that it” with classic XSS payload.

The modified request will be displayed below.

1. Toggle off the “Intercept is on” button to disable the request interceptions for now and forward the modified request to the server. Then, switch back to the web browser.

2. Immediately observe an XSS pop-up message, which will be displayed as shown below. then click on the “OK” button.

1. Wow!! It worked out, and we were able to successfully exploit XSS challenge 9. 😄

Lastly, always verify the HTML response code. Right-click and select “View page source” to verify how the injected XSS payload is appended.

I can confirm that the injected XSS payload in the hidden parameter value field has been passed to the server and reflected back in the response without any encodings this time.

Hence, our payload was executed. ☺️

Summary

In this article, we’ve seen how other parameters can be utilized to exploit XSS – it doesn’t always have to be done within the same param field.

Before we start, ensure the lab is up and running. If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

Hope by now you are familiar with what an XSS is and how it can be identified. In this article, you will be learning about how to exploit XSS when limited characters are allowed.

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 8”.

From the above screenshot, I can see that the application is requesting the input value in the “Try Your XSS payload?” field.

Feel free to try and experiment with different payloads.

Initially, I will go ahead and try out our classic XSS payload, which has been used throughout our series.

Payload Try 1: Classic

Output:

After keying in the payload value and clicking on the “Submit” button. Looks like nothing happened.

No pop-ups and no partial or filtered messages. Interesting!

Let’s go ahead and view the HTML source code received from the server to understand what is happening in the background.

Right-click and select “View page source”, then search for the injected payload string.

From the above screenshot, it could be understood that output encoding has been applied to injected XSS payload which prevents execution of the script tag.

Try out and verify all the XSS payloads which have been discussed throughout the series. Using IMG tag XSS, SVG tag-based XSS, etc.

Tip 8 - Use allowed characters to build XSS payload

As the heading says, you can keep on trying out any number of HTML tags and verify which XSS payload works. Or another better option could be to find out the list of allowed characters with multiple trials and errors and craft one using the allowed list of characters.

Identifying Allowed Characters

Using previous XSS payload output can confirm the javascript alert() function is allowed, next single quotes “’” are allowed, “/” slash is allowed, and lastly alphabets are allowed too.

Now need to find out, how the allowed list of characters can be used and make the XSS payload work.

Remember the XSS payload used in “Challenge 4”, Using HTML5 Attribute.

In the above XSS payload, can see that most of the characters are allowed, but we haven’t verified double quotes “”.

Quickly will go ahead and verify if the double quotes are allowed in the input field. By injecting and viewing the page source code.

Output 2:

Now, can confirm that double quotes are also allowed as injected without any encoding or escaping. Nice!

Let’s understand the XSS payload before trying it out.

Our motto is to rightly align the XSS payload in HTML response code and make it executable.

All the injected payload characters are inserted within the HTML input tag within the value field.

If the input is keyed in like onmouseover=alert(‘xss’) without quotes, it would be treated as text, and all the HTML attributes will not be of much help here. For the same reason, we use the extra quotes to properly align inside the input value field.

1. A double quote for closing the value section
2. onmouseover is one of the HTML attributes that can be used with HTML tags. The moment the mouse hovers over the code, the given javascript alert() function gets triggered.
3. Another double quote to make sure the remaining double quote of the value field is aligned with HTML syntax.

Enter the above-improvised payload in the input field and click on the “Submit” button.

Output 3:

For a moment, things seemed like nothing had happened, and the application behaved normally as expected. As seen before.

Hover over your mouse onto the input field and observe, immediately a pop-up message is prompted as shown below.

Waah!! 🎉 Our XSS payload worked. Let’s verify the HTML response code to confirm how the XSS payload is aligned further.

Right-click on the “View page source” and search for the injected XSS payload string.

The given payload got rightly aligned and only the allowed list of characters and HTML attributes have been used to exploit it.

We have successfully solved the XSS challenge 8.

Summary

This post demonstrates how generally output encoding is used to prevent XSS, but that itself is not enough to prevent the XSS vulnerability. The input HTML attributes and allowed characters can be carefully used to craft a working payload. To prevent the XSS vulnerability a Defense-In-Depth approach needs to be leveraged. Like performing output encoding, sanitizing, using CSP, etc. Which would be covered later.

Keep learning! 😃

Before we start, ensure the lab is up and running, If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Recap

The previous article covered reflected cross-site scripting scenarios where poor input validation checks can be exploited further.

Also, it demonstrated the impact of missing input validation checks on the server side. Therefore the input validations must be implemented well on both the client & server sides.

Practicals

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 7”.

Coming to XSS Challenge 7, an input field is given to key in the text and a drop-down menu option needs to be selected before clicking on the “Submit” button.

Will try out all the things techniques learned so far about identifying the XSS vulnerability.

Payload Try 1: Classic

Output:

Using our classic payload, select the default option in the drop-down menu “India”, then click on the “Submit” button.

Immediately, observe that the payload keyed in is displayed as it is. Right-click and select “View page source” to understand how the payload is being embedded in the HTML response.

Scrolling to the bottom of the page, I can see that our tags like ‘<’, ‘>’ etc.. have been replaced. This changes the meaning of the HTML format, and the browser considers it as text and displays it back without executing it as a script.

1. HTML Output Encoding

   The above output that we are seeing is called HTML output encoding.

   Output encoding is one of the mitigation techniques used to take user-controlled data and safely display it without interpreting it as code and considering it as text.

   Below is an example XSS payload.

   <script>alert(document.domain);</script>
   

   HTML-encoded text of the XSS payload will be displayed below.

   <script>alert(document.domain);</script>
   

   • “<” changed to “&lt;”
   • “>” changed to “&gt;”

   As the browser parses HTML, JavaScript, CSS, and URL differently. Each must be encoded depending on the requirements.

   URL, HTML, JavaScript, and CSS can be encoded.

   The input text field in the application seems to be handled properly, but we need to find another way to exploit it.

   ---

   

   Tip 7 - Try exploring other param values

   XSS need not be present all the time in the input text fields, it can be found in other parameters as well which are parsed and used by the server.

   ---

   

2. Trying XSS in the “location” param

   I will be using the “BurpSuite” proxy tool going ahead with the demo. Please make sure your browser is preconfigured with the BurpSuite and working as expected.

   Visit the Challenge 7 page.

   Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite “Proxy” -> “Intercept” -> Toggle the “Intercept is off” button.

   

   Fill up the input field value with “Test XSS” and then click on the “Submit” button.

   

   Now in the “BurpSuite” proxy tool, observe the request being transmitted to the server, is intercepted, and displayed as shown below.

   

   Observe at the bottom of the request the “xss”, “location” and “submit” params are being passed to the server.

   Remember, in the previous article Challenge 6, we sent the modified XSS payload to the server.

   In a similar way, this time in the “location” param value append our classic XSS payload, which will be displayed as shown below.

   

   Next, toggle off the “Intercept is on” button to disable the request interception for now. Immediately switch back to the web browser.

   

   Immediately observe that an XSS pop-up message will be displayed, as shown below.

   

   YAY!! 🎉 by this, we can confirm the application is still vulnerable to the cross-site scripting vulnerability.

   Click the “OK” button to continue, then right-click and select “View page source” to very our payload injection. Search for the payload inserted.

   

   You can find the inserted payload at the bottom of the page. This time, you can see that our payload is displayed as given without any output encoding.

   By this, we have successfully exploited the XSS challenge 7.

   ---

   

Summary

The key takeaway from this article is XSS need not necessarily be exploited from the user input form fields, the XSS vulnerability can be tested in any param header and value fields that are parsed by the server.

Keep learning! 😃

Before we start, ensure the lab is up and running. If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 6”.

I hope by now you are familiar with what an XSS is and how it can be exploited. In this article, we shall learn more about identifying XSS vulnerabilities.

Without much waiting, let’s try our classic XSS payload on “Challenge 6” and understand what the result we are getting.

Payload Try 1: Classic

Output:

The output seems to be something familiar. We have seen this type of output earlier as well.

Yes, we have seen this type of output when learning about the reflected cross-site scripting vulnerability in Challenge 3. We. Almost the same, with a slight change.

Let’s explore it.

Understanding Application Behaviour

Below is the output that we received when trying to use a classic XSS payload.

Right-click and select “View page source” to view the HTML source code. I search and scroll down through the HTML code to understand what is happening with our input field. You will be able to find the code snippet as shown below.

The HTML input tag seems very similar as seen in previous challenges.

Taking a closer look, whenever we click on the “submit” button, the HTML form is running a “filter()” javascript function.

JavaScript is used for adding dynamic capabilities to the page making it user-friendly.

In the same HTML code, will search for the javascript code.

Scrolling through the top of the page, I can see a javascript file named “ch06.js” has been included. Clicking on the file, the javascript code opens, as shown below.

We found the “filter()” function javascript code. A blacklisting approach of input filtering is being used.

You can see the script, svg, and img HTML tags being stripped out on the client side by the javascript filter() function.

The above code is an example that demonstrates that the client-side validation check is in place. Remember from the previous article

Input validation checks need to be applied on both the client and the server side.

Tip 6 - Client Side validations can be bypassed

Yes, you are hearing right. Every piece of instruction sent from the client side browser can be tampered with or removed or new data can also be added.

One way is through using browser addons like i.e. Tamper Data for Chrome etc. Available for firefox as well.

Another way is using the interceptor proxy tools like BurpSuite or OWASP ZAP. Once configured with the web browser, they can help to view/modify every request before it is sent to the server.

In our demonstrations going ahead, I will be using the “BurpSuite Community” edition. Please refer to the tool documentation which can help you in getting started.

1. Bypassing Client Side validation

   Hope by now your web browser is configured and ready to use with the BurpSuite.

   Step 1. Navigate to “XSS Challenge 6”

   

   Step 2. Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite “Proxy” -> “Intercept” -> Toggle the “Intercept is off” button.

   

   Step 3. In the XSS challenge 6 page, key in with the classic XSS Payload, then click on the submit button.

   

   Step 4. Observe the intercepted request from your web browser, which will be displayed below.

   

   Don’t worry about the overwhelming information. This is the RAW format in which the web browser and server exchange HTTP messages. The underlined text indicates our input text is being sent in a URL-encoded format.

   Decoded text is nothing but the filtered input value.

   

   This explains why JavaScript validations strip out our XSS payload on the client side.

   Step 5. Replace the underlined text with our classic XSS payload, as shown below.

   

   Step 6. Toggle off the “Intercept is on” button to disable the request interceptions for now. Immediately switch back to the web browser.

   

   Step 7. Immediately observe that an XSS pop-up message will be displayed, as shown below. then click on the “OK” button to continue loading.

   

   The application load back the challenge page normally. To further confirm click on the “View Page Source” for our injected XSS payload.

   

   YAY!! 🎉 By this, we can confirm the application is still vulnerable to cross-site scripting vulnerability.

   ---

   

   The XSS payload still worked because the input field validation is only implemented on the client side using JavaScript but not on the server side.

   As there were no filters on the server side, our XSS payload passed through as an HTTP request to the server and reflected in the HTTP response as keyed-in.

   ---

   

Summary

The important lesson to take away from this article is that for the developers, the input validations need to be implemented both on the client side as well as on the server side. For security researchers, make sure to verify the validation checks are equally implemented on the server side as well.

Keep learning! 😃

Before we start, ensure the lab is up and running if you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 5”.

Give it a try with all the payloads we have learned so far.

I will go ahead and give it a try with our classic XSS payload.

Payload Try 1: Classic

Output:

Observe that we cannot enter any characters after “<sc”. All the characters typed after are no longer considered.

What might be happening in the background?

Let’s go ahead and view the page’s HTML source code to understand further. Type “Ctrl + u” or right-click and select “View page source”.

In the HTML source code, scroll down to the input field and you should be able to see the code similar to the one below.

For the current input field where we are trying to enter the values, the “max length is set to 3”. For the same, we are not able to enter more than 3 characters in the input field.

Can we bypass the length limitations? Possible. let’s give it a try.

Tip 5 - Client/Server Side validation bypass

In general, input validations for the applications will need to be validated both on the client side and on the server side.

In some cases, the input validations might be missing on either side.

1. Tampering Client Side validation

   In our current scenario, we surely know that the length limitations for the characters are set on the client side. (i.e. maxlength=“3” )

   There are many ways to do it, in this article we shall be using a simple technique using the browser’s inbuilt functionalities.

   Output:

   

   On the current output page, right-click on the input field and select “inspect”. (In some cases, you might need to right-click on the input field and select “inspect” twice to narrow down to the exact position of the input HTML code)

   Output from the “inspect” will be displayed below.

   

   Double click on the maxlength=“3” value field and change it to 200 or some bigger value.

   

   Observe, now the length limitations on the client side are updated and then click on cross “x” to close the browser debugger.

   Let’s go ahead and re-try out the classic XSS payload.

   

   Output:

   

   Yay!!! 🎉 we got an XSS pop-up.

   Yes, We have successfully exploited the XSS vulnerability again by tampering with client-side validation checks.

   One thing to take away from this article is all the validation checks applied on the input field need to be applied on both client side and on the server side.

   ---

   

Summary

In this article, we learned how client-side validation can be tampered with and bypassed to execute the XSS payload. Also, learned that the input validations need to be equally applied both on the client/server side.

Keep learning! 😃

Before we start, ensure the lab is up and running. If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

After setting up the lab, visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 4”.

Give it a try with all the payloads you have learned so far.

I will go ahead and give it a try with our classic XSS payload.

Payload Try 1: Classic

Output:

Enter the XSS payload in the input field and click on the “Submit” button.

This time, we haven’t gotten any pop-up messages indicating that our XSS payload didn’t work.

Right-click and select “View page source”, then search for the given payload to understand what exactly is happing with injected payload.

Observe, that our script code given as input, is reflected in the HTTP response and is correctly placed in between the input value quotes. Which is working as expected.

All the payload is being treated as a text value and is no longer able to control the behavior of HTML code.

Can we assume that the vulnerability is fixed? May be

Closely observe that all the characters typed in the input payload are being injected and reflected in the HTML response without much filtering or encoding.

It is worth to give a try with other possible ways of exploiting XSS before we can confirm whether it is fixed or not.

TIP - 4

The XSS payloads may not work as given all the time. We need to learn and find what allowed characters are and a working payload needs to be carefully crafted out from the allowed list of the character set.

Previous HTTP Response Screenshot:

In the above, all the given XSS payload is being placed inside the double quotes. Let’s improvise the payload by appending a double quote before the script tag and see if it can control the HTML response behavior.

Improvised Payload 1:

Enter the above payload in the input field, then click on the “Submit” button.

Browser Output:

For the immediate response, click on the “View page source” and search for the injected payload and how it’s being reflected in the HTTP response.

Interestingly, the double quote gets injected and aligns well with the HTML response code. As we can control the HTML response behavior, This gives us hint that there is a possibility to exploit reflected XSS further.

We now have most of the information to craft a working XSS payload.

The XSS payload here can be crafted in a couple of ways.

1. Trying to use the available/allowed HTML5 event attributes to execute the reflected XSS. As used in the previous article.
2. Closing the HTML input form tag, injecting our classic XSS payload, and commenting out the rest of the code.

One way to choose this type of scenario is based on the length limitations set by the application.

Let’s use the first way mentioned above to craft the XSS payload.

Improvised Payload 2: Using HTML5 Attribute

onmouseover is one of the HTML attributes that can be used with HTML tags, the moment the mouse hovers over the code, the javascript alert() function gets triggered.

Enter the above-improvised payload in the input field and click on the “Submit” button.

Output:

For a moment, things seemed like nothing happened, and the application behaved normally as expected.

Take your mouse, hover over the input field, and observe. Immediately, a pop-up message is prompted, as shown below.

yay!!!, our XSS payload worked and the application displays the pop-up message. This confirms that the application is still vulnerable to the reflected cross-site scripting vulnerability.

Will view the page source code to check how our payload got injected and changed HTTP response behavior. Right-click and select “View page source”, then search for the injected payload string.

Observe that the double quote has closed the value field, then appended the HTML attribute element for the input tag with the “onmouseover” event along with the javascript code, then closed the double quote to further align with the HTML code.

We have successfully confirmed that the application is still vulnerable to cross-site scripting vulnerability.

Let’s continue and try out the second method mentioned above to craft the XSS payload.

Improvised XSS payload 3: Classic XSS with syntax correction

The above payload is the same as we used earlier but with minor modifications.

In prefix, a double code followed by a greater than arrow mark to close the input form field. Then at the end of the script code append the HTML comment code, this will comment out all the next code after our HTML script tag.

Enter the above payload in the input field and give it a try.

Output:

Immediately, a pop-up message is displayed confirming that the XSS payload still works.

Click “OK”, then Right-click and select “View page source”, then search for the injected payload string.

As expected, observe the HTML input tag is closed, then injected with our classic XSS payload and followed by commenting out all the rest of the code after the HTML script tag.

By this, we have successfully exploited the cross-site scripting vulnerability challenge 4.\

Summary

In this article, we learned how poorly implemented validations can still be bypassed by improving the XSS payload and trying different possible combinations. Also, there is no need that the default XSS payload needs to work out of the box, the payload needs to be tweaked based on the scenarios to make it work.

Keep learning! :D