InjectX to Find XSS Tutorial

Overview

In this tutorial, I will cover a simple technique to identify reflected values in a target web application and easily locate Cross-Site Scripting vulnerabilities. By injecting unique heuristic strings, we can quickly check if the value we are testing is reflected and not being sanitized by the application. I have used this technique in the past and it has helped me find various injection bugs that have paid up to $500 in some cases.

Requirements

In order to use this technique, you’ll need Burpsuite along with the custom grep strings and fuzz lists provided in this tutorial to get started. For more advanced tricks covered at the end of this tutorial, you’ll also need Apache and Beef (Browser Exploitation Framework).

Why is this helpful to me?

Using this technique allows you to do the following:

1. Find reflected values quickly (only 3 requests per injection point)
2. Find the location of all reflected values in the response
3. Confirm XSS vectors via heuristic testing
4. Exploit XSS vectors with certainty

Great! How do I do it?

1. Download the Burp attack configuration or manual payload and grep strings here
2. Load the attack configuration or manual payload lists from the Burp Intruder menu

3. Copy/paste the request to the Intruder screen and add injection points:

– Form fields
– GET/POST parameters
– Header fields
– Cookie values
– URI structure

NOTE: You’ll need to copy/paste the hostname into the “Host” tab of the Intruder configuration for this to work.

4. Run the attack and analyze the results. Is “INJECTX” reflected? If so, are HTML special characters such as <>/()”’ sanitized? If not, XSS is possible.

5. If HTML special characters are reflected in the response, proceed to XSS exploitation

Workflow:

1. Is the injection point reflected in the response? If yes, goto step 2. As seen below, the “INJECTX” string is found which confirms the payload was reflected.

2. If the payload was reflected in the response, where in the response is it reflected? Search for “INJECTX” to find all injection points. Go to step 3.
3. Once reflected injection points are found, which characters are being sanitized? Again, search for “INJECTX” in the response and look for the heuristic test characters to see which are still untampered. At a minimum, we’ll need “‘>” and “(INJECTX)” as your grep strings. If these characters or search strings are found, then XSS is possible. Proceed to step 4.

4. If XSS is possible, inject our “real” XSS payloads either through manual browser attempts, Burp Intruder or Repeater to exploit the XSS vector. In this case, I’m using an < iframe > that’s linked back to my web server.

 

Remote XSS Confirmation

Using a remote payload such as an < iframe > or < img >, you can get remote confirmation via Apache logs which also help keep track of blind and stored XSS vectors. This will also list the referring page the XSS loaded from along with the source IP which helps to keep track of which page and hosts are vulnerable.

Advanced XSS and Client-side Attacks via Beef

Since we control the < iframe > page, we can inject whatever HTML/JS code we want. In this case, it loads a Beef (Browser Exploitation Framework) hook.js which can be used to launch more advanced XSS/client side attacks.

Drawbacks and limitations:

– XSS vectors must be reflected in the static HTML response
– Does not work with DOM XSS injections unless additional plugins such as BurpKit are used or JS is rendered manually using other techniques
– Does not work great for blind XSS vectors
– Does not take into account XSS bypass methods if input is sanitized

Demo Video

https://www.youtube.com/watch?v=NdGGCNjQB2A

Download

https://github.com/1N3/IntruderPayloads

Questions? Comments/feedback?

Twitter: https://twitter.com/CrowdShield
BugCrowd: https://bugcrowd.com/1N3/
GitHub: https://github.com/1N3
Website: https://xerosecurity.com

Bypassing Unvalidated Open Redirect Filters

Overview

A quick PoC/tutorial on bypassing open redirect filters in Infosec Institutes Level 13 CTF challenge. Full details on the challenge can be found here: http://ctf.infosecinstitute.com/ctf2/. All credits go to 1N3 @CrowdShield and full disclosure details can be found here: https://xerosecurity.com/dashboard.php?bug_id=691

Request #1

The request below indicates that the affected page is redirecting all requests sent to the redirect= parameter which may be vulnerable to open redirect attacks.

Response #1

The addition of the Location: header indicates that the value specified in the redirect= GET parameter is being injected into the Location: header field.

Burpsuite Open Redirect Fuzz List

Using Burpsuite Intruder or any other web proxy, we can use the following list to check for open redirect vulnerabilities and possible bypasses. This can be downloaded using Gist here: https://gist.github.com/1N3/de48ab54edd831cb12fb

http://google.com
//google.com
\/google.com
\/\/google.com
/\google.com
/\/\google.com
|/google.com
/%09/google.com
/google.com
javascript:document.location=http://google.com

Bypass Request #2

After fuzzing the redirect= parameter, we can see from the responses that javascript is being executed (levelCompleted(13);) only when the bypass is successful. The application attempts to prevent redirection attacks by blocking absolute redirection targets starting with http:// or https://. However, an attacker can defeat this defense by omitting the protocol prefix from their absolute URL. If a redirection target starting with // is specified, then the browser will use the same protocol as the page which issued the redirection. The application also appears to be blocking the standard protocol-relative sequence (//). However, an attacker can defeat this defense by using backslashes instead. Some browsers (notably Chrome and Safari) accept these non-standard protocol-relative sequences.

Bypass Response #2

Bypassing HTML5/Javascript XSS Restrictions

OVERVIEW:

A quick PoC/tutorial on bypassing client-side HTML5/Javascript XSS filters in Infosec Institutes Level 1 CTF challenge. Full details on the challenge can be found here: http://ctf.infosecinstitute.com/ctf2/. All credits go to [email protected]

STEP 1: Inspect the Site Name element

Since the application performs character encoding for the “<” and “>” characters, we will need to check the code to see if the sanitization is occurring at the server level, or client side. If it’s client-side (ie. HTML5/Javascript), this can be altered and bypassed by the user. To do this, use any web browser and right-click on the “Site Name” form element and click the “Inspect Element” option. This will open developer tools which will allow us to edit the properties.

STEP 2: Remove client side restrictions

Replace the existing input field to increase the maxsize field and remove the characters allowed property as follows:

<input type="text" placeholder="Name of site" maxsize="100" class="form-control" required="" name="name">

STEP 3: Edit the ex1.js file to remove character encoding

Since the web application also appears to be sanitizing the “<” and “>” characters via ex1.js (Javascript), we will need to edit the client side javascript first to bypass this. This can be done in web developer tools by clicking the Sources” tab and editing the ex1.js to remove the HTML character encoding:

var siteName = $(".ex1 input[type='text']").val().trim().replace(/</g, "<").replace(/>/g, ">");
var siteURL = $(".ex1 input[type='url']").val().trim().replace(/</g, "<").replace(/>/g, ">");

STEP 4: Enter the XSS payload

After the client side validation and sanitizing is removed, enter the following payload into the “Site Name” field and click “Submit”.

<script>alert('Ex1')</script>

RESULT:

The result is that our Javascript alert window was successfully injected into the page after all client-side code was altered and bypassed. To prevent these types of attacks, validation should be done from a server side component that the user cannot control or edit.