SSRFing External Service Interaction and Out of Band Resource Load (Hacker's Edition)

External Service Interaction & Out-of-Band Resource Loads

Host Header Exploitation // SSRF Primitives // Infrastructure Pivoting

SSRF Host Header Injection CWE-918 OWASP A10:2021 Cache Poisoning Updated 2026

In the recent past we encountered two relatively new types of attacks: External Service Interaction (ESI) and Out-of-Band Resource Loads (OfBRL).

1. An ESI [1] occurs only when a web application allows interaction with an arbitrary external service.
2. OfBRL [6] 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).

Taxonomy Note (2026): Both ESI and OfBRL are now classified under OWASP A10:2021 — SSRF and map to CWE-918 (Server-Side Request Forgery). ESI also maps to CWE-441 (Unintentional Proxy or Intermediary).

The Problem with OfBRL

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 (when OfBRL is applicable) or a one-way proxy (when ESI is applicable). 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.

The Problem with ESI

External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions 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.

Figure 1 — ESI (one-way) vs OfBRL (two-way) attack paths

The Verification

We do not have ESI or OfBRL when:

1. In Collaborator, the source IP is our browser IP (the server didn't make the request).
2. There is a 302 redirect from our host to the Collaborator (i.e. our source IP appears in the Collaborator logs, not the server's).

Below we can see the original configuration in the repeater, followed by the modified configuration for the test. In the original request, the Host header reflects the legitimate domain. In the test request, we replace it with our Collaborator payload or target host.

Original request

GET / HTTP/1.1 Host: our_vulnerableapp.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Malicious requests

GET / HTTP/1.1 Host: malicious.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

GET / HTTP/1.1 Host: 127.0.0.1:8080 Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

If the application is vulnerable to OfBRL, the reply is going to be processed by the vulnerable application, bounce back to the sender (the attacker) and potentially load in the context of the application. If the reply does not come back to the sender, then we might have an ESI, and further investigation is required.

The RFCs Updated

It usually is a platform issue and not an application one. In some scenarios when we have, for example, a CGI application, the HTTP headers are handled by the application (i.e. the app is dynamically manipulating the HTTP headers to run properly). This means that HTTP headers such as Location and Host are handled by the app and therefore a vulnerability might exist. It is recommended to run HTTP header integrity checks when you own a critical application that is running on your behalf.

For more information on the subject, read RFC 9110 (HTTP Semantics, June 2022) [2] and RFC 9112 (HTTP/1.1 Message Syntax and Routing) [2b], which supersede the obsolete RFC 2616. The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI. The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.

RFC Update: RFC 2616 was obsoleted in 2014 by RFCs 7230–7235, which were themselves superseded by RFCs 9110–9112 in June 2022. All references in this article now point to the current standards.

When TLS is enforced throughout the whole application (even the root path /), an ESI or OfBRL is significantly harder to exploit, because TLS performs source origin authentication — as soon as a connection is established with an IP, the protocol guarantees that the connection will serve traffic only from the original certificate holder. More specifically, we are going to get an SNI error.

SNI prevents what's known as a "common name mismatch error": when a client device reaches the IP address of a vulnerable app, but the name on the TLS certificate doesn't match the name of the website. SNI was added to the IETF's Internet RFCs in June 2003 through RFC 3546, with the latest version in RFC 6066. The current TLS 1.3 specification is RFC 8446 [10].

ECH Warning (2025+): Encrypted Client Hello (ECH), specified in RFC 8744 and actively being deployed by major browsers and CDNs, encrypts the SNI field within the TLS handshake. This means that SNI-based filtering and inspection at network perimeters becomes ineffective when ECH is in use. Security teams should account for this when relying on SNI as a defensive control.

Figure 2 — TLS/SNI protection mechanism (and its ECH caveat)

The option to trigger an arbitrary external service interaction does not constitute a vulnerability in its own right, and in some cases it might be the intended behavior of the application. But we as hackers want to exploit it — what can we do with an ESI or an Out-of-Band Resource Load?

The Infrastructure

Well, it depends on the overall setup. The highest-value scenarios are the following:

1. The application is behind a WAF (with restrictive ACLs)
2. The application is behind a UTM (with restrictive ACLs)
3. The application is running multiple applications in a virtual environment
4. The application is running behind a NAT
5. The application runs in a cloud environment with metadata endpoints accessible from localhost
6. The application runs in a containerized environment (Docker/Kubernetes) with internal service discovery

In order to perform the attack, we simply inject our host value in the HTTP Host header (hostname including port).

Figure 3 — Host header injection pivoting through infrastructure (including cloud/container targets)

The Test

Burp Professional edition has a feature named Collaborator. Burp Collaborator is a network service that Burp Suite uses to help discover vulnerabilities such as ESI and OfBRL [3]. A typical example would be to use Burp Collaborator to test if ESI exists.

Burp Collaborator request

GET / HTTP/1.1 Host: edgfsdg2zjqjx5dwcbnngxm62pwykabg24r.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: keep-alive

Burp Collaborator response

HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ X-Collaborator-Version: 4 Content-Type: text/html Content-Length: 53 <html><body>drjsze8jr734dsxgsdfl2y18bm1g4zjjgz</body></html>

The Post Exploitation

As hacker-artists, we now think about how to exploit this. The scenarios are: [7] [8]

1. Attempt to load the local admin panels.
2. Attempt to load the admin panels of surrounding applications.
3. Attempt to interact with other services in the DMZ.
4. Attempt to port scan localhost.
5. Attempt to port scan DMZ hosts.
6. Use it to exploit IP trust and run a DoS attack against other systems.
7. Access cloud metadata endpoints to extract IAM credentials or instance identity tokens.
8. Probe Kubernetes API or container sidecar services (e.g. Envoy admin on localhost:15000).

A good tool for automating this is Burp Intruder [4]. Using Sniper mode, we can:

1. Rotate through different ports, using the vulnapp.com domain name.
2. Rotate through different ports, using the vulnapp.com external IP.
3. Rotate through different ports, using the vulnapp.com internal IP, if applicable.
4. Rotate through different internal IPs in the same domain, if applicable.
5. Rotate through different protocols (may not always work).
6. Brute-force directories on identified DMZ hosts.

Burp Intruder — scanning surrounding hosts

GET / HTTP/1.1 Host: 192.168.1.§§ Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Burp Intruder — port scanning surrounding hosts

GET / HTTP/1.1 Host: 192.168.1.1:§§ Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Burp Intruder — port scanning localhost

GET / HTTP/1.1 Host: 127.0.0.1:§§ Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Modern Attack Vectors New 2026

Since the original publication of this article, several high-impact attack surfaces have emerged that directly exploit ESI/OfBRL primitives:

Cloud metadata endpoint exploitation

Cloud providers expose instance metadata via link-local addresses. When a vulnerable application can be coerced into making requests to these endpoints via Host header injection, an attacker can extract IAM credentials, service account tokens, instance identity documents, and network configuration details.

GET / HTTP/1.1 Host: 169.254.169.254 # AWS IMDSv1 — returns IAM role credentials GET / HTTP/1.1 Host: metadata.google.internal # GCP — returns service account tokens GET / HTTP/1.1 Host: 169.254.169.254 Metadata: true # Azure — requires Metadata header (may not work via Host injection alone)

Mitigation: AWS IMDSv2 mitigates this by requiring a PUT request with a TTL-bounded token (hop limit = 1). GCP Compute VMs support a similar metadata concealment mechanism. Ensure your cloud instances enforce these protections.

Container and Kubernetes exploitation

In containerized environments, the application server often has network access to internal Kubernetes services that are never meant to be internet-facing:

GET / HTTP/1.1 Host: kubernetes.default.svc:443 # K8s API server — may leak secrets, pod specs, RBAC config GET / HTTP/1.1 Host: 127.0.0.1:15000 # Envoy sidecar admin — config dump, cluster endpoints, stats GET / HTTP/1.1 Host: 127.0.0.1:9090 # Prometheus metrics — may expose internal service topology

Practical cache poisoning (Kettle, 2018)

James Kettle's 2018 PortSwigger research on practical web cache poisoning significantly expanded the attack surface understanding for Host header injection. His work demonstrated that unkeyed HTTP headers (including Host, X-Forwarded-Host, and X-Forwarded-Scheme) can be used to poison shared caches (CDNs, reverse proxies) at scale, affecting all users served by the poisoned cache entry. This research formalized the technique that was previously theoretical into a repeatable, high-impact attack chain.

Figure 4 — Cache poisoning via Host header injection

What Can You Do

The full exploitation analysis — this vulnerability can be used in the following ways:

1. Bypass restrictive UTM ACLs
2. Bypass restrictive WAF rules
3. Bypass restrictive firewall ACLs
4. Perform cache poisoning
5. Fingerprint internal infrastructure
6. Perform DoS exploiting IP trust
7. Exploit applications hosted on the same machine (multiple app loads)
8. Extract cloud IAM credentials via metadata endpoints
9. Map Kubernetes cluster topology via internal service discovery
10. Exfiltrate data through DNS-based out-of-band channels

The impact of a maliciously constructed response can be magnified if it is cached either by a shared web cache or the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers or CDNs, then all users of that cache will continue to receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, that user will continue to receive the malicious content until the cache entry expires [5].

What Can't You Do

You cannot perform XSS or CSRF exploiting this vulnerability, unless certain conditions apply (e.g. the poisoned response injects attacker-controlled JavaScript into a cached page, or the application reflects the Host header value into HTML output without encoding).

The Fix Updated

If the ability to trigger arbitrary ESI or OfBRL 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 [6]. Running host integrity checks is also recommended.

Review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, 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.

More specifically, we can:

1. Apply egress filtering on the DMZ
2. Apply egress filtering on the host (iptables/nftables rules, or cloud security group outbound rules)
3. Apply whitelist IP restrictions in the application
4. Apply blacklist restrictions in the application (not recommended — incomplete by nature)
5. Validate and normalize the Host header at the reverse proxy layer before it reaches the application (e.g. Nginx server_name directive with explicit hostnames, reject requests with unknown Host values)
6. Use X-Forwarded-Host with strict allowlisting rather than trusting the raw Host header — and ensure the reverse proxy strips any client-supplied X-Forwarded-* headers before adding its own
7. Enforce IMDSv2 on cloud instances (hop limit = 1, PUT-based token acquisition) to block Host header SSRF to metadata endpoints
8. Apply Kubernetes NetworkPolicies to restrict pod-to-pod and pod-to-service communication to only what's necessary
9. Deploy egress proxies for any application that legitimately needs to make outbound HTTP requests — force all outbound traffic through a proxy with domain allowlisting

---

References

1. portswigger.net — External Service Interaction (DNS)
2. RFC 9110 — HTTP Semantics (June 2022) — supersedes RFC 2616
3. RFC 9112 — HTTP/1.1 Message Syntax and Routing (June 2022)
4. portswigger.net — Burp Collaborator
5. portswigger.net — Burp Intruder
6. owasp.org — Cache Poisoning
7. portswigger.net — Out-of-Band Resource Load (HTTP)
8. CWE-918: Server-Side Request Forgery (SSRF)
9. CWE-406: Insufficient Control of Network Message Volume
10. CWE-441: Unintentional Proxy or Intermediary
11. RFC 8446 — TLS 1.3 (August 2018)
12. RFC 6066 — TLS Extensions (January 2011) — SNI
13. cloudflare.com — What is SNI?
14. portswigger.net — Practical Web Cache Poisoning (Kettle, 2018)
15. OWASP Top 10 2021 — A10: SSRF

Web DDoSPedia a million requests

Web Application Denial of Service Next Level

In this tutorial we are going to talk on how to cause maximum down time (including operational recovery processes) in anything that uses the word Web, this is also known as a Denial o Service Attack. Using this knowledge for malicious purposes is not something I am recommending or approve and I have zero accountability on how you use this knowledge. This is the reason I am providing also with countermeasures on the end of the post.      

What Is The Landscape

In the past we have seen many Denial of Service attacks, but most of them were not very sophisticated. A very good example would be the Low Orbit Ion Cannon (LOIC). LOIC performs a DoS attack (or when used by multiple individuals, a DDoS attack) on a target site by flooding the server with TCP or UDP packets with the intention of disrupting the service of a particular host. People have used LOIC to join voluntary botnets.[2]

All these attacks as stated in previous post do not really take advantage of the 7th layer complexity of the Web and therefore are not so effective as they could be. A very good post exists in the Cloudflare  blog named Famous DDoS Attacks [3].  

A few of the famous attacks are:

• The 2016 Dyn attack
• The 2015 GitHub attack
• The 2013 Spamhaus attack
• The 2000 Mafiaboy attack
• The 2007 Estonia attack

Improving DoS and DDoS attacks

In order to improve or understand better what is possible while conducting a DoS attack, we have to think like a Web Server, Be a Web Server, Breath like a Web Server!!

Well what does a server breath? But of course HTTP, so what if we make the Web Server start breathing a lot of HTTP/S, that would be amazing.

This is how we can over dose with HTTP a web server:

1. HTTP Connection reuse
2. HTTP Pipelining
3. Single SSL/TLS handshake  

But lets go a step further and expand on that, what else can we do to increase the impact? But of course profile the server and adjust the traffic to something that can be processed e.g. abuse vulnerable file upload functionality, SQLi attacks with drop statements etc.   

 HTTP connection reuse

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair.

The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

HTTP 1.0, connections are not considered persistent unless a keep-alive header is included, although there is no official specification for how keepalive operates. It was, in essence, added to an existing protocol. If the client supports keep-alive, it adds an additional header to the request:

Connection: keep-alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: keep-alive

Following this, the connection is not dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

In HTTP 1.1, all connections are considered persistent unless declared otherwise. The HTTP persistent connections do not use separate keepalive messages, they just allow multiple requests to use a single connection.

If the client does not close the connection when all of the data it needs has been received, the resources needed to keep the connection open on the server will be unavailable for other clients. How much this affects the server's availability and how long the resources are unavailable depend on the server's architecture and configuration.

Yes dear reader I know what are you thinking, how can you the humble hacker, the humble whitehat reader can use this knowledge to bring down your home web server for fun? Well there are good news. 

In Python there are various functions provided for instantiating HTTP keepalive connections within urllib3 library, such as ConnectionPools.

Here is a code chunk to look through:

from urllib3 import HTTPConnectionPool

[...omitted...]

urllib3.connectionpool.make_headers(keep_alive=None, accept_encoding=None, user_agent=None, basic_auth=None)¶

[...omitted...]

Parameters:

• keep_alive – If True, adds ‘connection: keep-alive’ header.
• accept_encoding – Can be a boolean, list, or string. True translates to ‘gzip,deflate’. List will get joined by comma. String will be used as provided.
• user_agent – String representing the user-agent you want, such as “python-urllib3/0.6”
• basic_auth – Colon-separated username:password string for ‘authorization: basic ...’ auth header.

Note: If you are a proxy person, you can use the Match and Replace functionality on Burp Pro Suite to add or replace a the keepalive header. Bur then, your client (aka. the browser would have to know how to handle the received content). Better to write a Python template to handle the interaction.

HTTP Pipelining

HTTP pipelining is a technique in which multiple HTTP requests are sent on a single TCP (transmission control protocol) connection without waiting for the corresponding responses. The technique was superseded by multiplexing via HTTP/2, which is supported by most modern browsers.

See following diagram for pipeline :

HTTP pipelining requires both the client and the server to support it. HTTP/1.1 conforming servers are required to support pipelining (Pipelining was introduced in HTTP/1.1 and was not present in HTTP/1.0). This does not mean that servers are required to pipeline responses, but that they are required not to fail if a client chooses to pipeline requests. Interesting behavior!!!!!!!!!

Note: Most of the servers execute requests from pipelining clients in the same fashion they would from non-pipelining clients. They don’t try to optimize it.

Again, yes dear reader I know what are you thinking, how can you the humble blackhat hacker, the humble hacktivist reader can use this knowledge to bring down your home web server for fun? Well there are more good news. 

Some Python frameworks do support HTTP/2 aka HTTP pipelining , Mouxaxaxa. As of late 2017 there are two Python frameworks that directly support HTTP/2, namely Twisted and Quart with only the latter supporting server-push.

Quart can be installed via pipenv or pip:

$ pipenv install quart
$ pip install quart

This requires Python 3.7.0 or higher (see python version support for reasoning).

A minimal Quart example is:

from quart import make_response, Quart, render_template, url_for

app = Quart(__name__)

@app.route('/')
async def index():
    result = await render_template('index.html')
    response = await make_response(result)
    response.push_promises.update([
        url_for('static', filename='css/bootstrap.min.css'),
        url_for('static', filename='js/bootstrap.min.js'),
        url_for('static', filename='js/jquery.min.js'),
    ])
    return response

if __name__ == '__main__':
    app.run(
        host='localhost', 
        port=5000, 
        certfile='cert.pem', 
        keyfile='key.pem',
    )

Also another library that supports Python HTTP/2 connectivity is hyper. hyper is a Python HTTP/2 library, as well as a very serviceable HTTP/1.1 library.

To begin, you will need to install hyper. This can be done like so:

$ pip install hyper

From the terminal you can launch a request by typing:

>>> from hyper import HTTPConnection
>>> c = HTTPConnection('http2bin.org')
>>> c.request('GET', '/')
1
>>> resp = c.get_response()

Used in this way, hyper behaves exactly like http.client classic Python client. You can make sequential requests using the exact same API you’re accustomed to. The only difference is that HTTPConnection.request() may return a value, unlike the equivalent http.client function. If present, the return value is the HTTP/2 stream identifier.

In HTTP/2, connections are divided into multiple streams (due to pipelining). Each stream carries a single request-response pair. You may start multiple requests before reading the response from any of them, and switch between them using their stream IDs.

Note: Be warned: hyper is in a very early alpha. You will encounter bugs when using it. If you use the library, provide feedback about potential issues and send to the creator.

Making Sense

By dramatically speeding up the number of payloads per second send to the server we increase the chance to crash the system for the following reasons:

• Multiple HTTP/2 connections sending requests such as the following would cause significant  resource allocation, both in the server and the database:
• File upload requests, with large files to be uploaded.
• File download requests, with large files to be downloaded.
• POST and GET requests containing exotic Unicode Encoding e.g. %2e%2e%5c etc.
• POST and GET requests while performing intelligent fuzzing.  
• Enforcement of single  SSL/TLS Handshake: 
• Not much to be said here. Simply enforce a single TLS handshake if the malicious payloads are going to consume more resources than the handshake it self. This will cause the server to consume resources.

Note: Such type of an attack can also be used to as a diversion to hide other type of attacks, such as SQLi etc.

The diagram below demonstrates where potentially system is going to crash first:

Other Uses of The This Tech

We can use this knowledge to perform the following tasks:

• Optimize Web App Scans
• Optimize directory enumeration
• Optimize online password cracking on Web Forms
• Optimize manual SQLi attacks 

Useful Tools 

There are some tools out there that make use some of the principles mentioned here:

• Turbo Intruder - https://github.com/PortSwigger/turbo-intruder - Turbo Intruder is a Burp Suite extension for sending large numbers of HTTP requests and analyzing the results. It's intended to complement Burp Intruder by handling attacks that require exceptional speed, duration, or complexity.
• Skipfish - https://code.google.com/archive/p/skipfish/ - Skipfish is an active web application security reconnaissance tool. It prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes.

Countermeasures

Things to do to avoid this type of attacks are:

• Firewall HTTP state filtering rules 
• Firewall HTTPS state filtering rules  
• Firewall HTTP/2 blockage - Although not recommended
• WAF that checks the following things - 
• User Agent - Check for spoofing the agent 
• Request Parameters - Check for fuzzing 
• Request size check.

That is it folks have fun.......

References: 

1.  https://stackoverflow.com/questions/25239650/python-requests-speed-up-using-keep-alive
2.  https://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
3.  https://www.cloudflare.com/learning/ddos/famous-ddos-attacks/
4. https://en.wikipedia.org/wiki/HTTP_persistent_connection 
5. https://2.python-requests.org/en/master/user/advanced/#keep-alive
6. https://urllib3.readthedocs.io/en/1.0.2/pools.html.
7. https://stackoverflow.com/questions/19312545/python-http-client-with-request-pipelining
8. https://www.freecodecamp.org/news/million-requests-per-second-with-python-95c137af319/
9. https://www.python.org/downloads/
10. https://txzone.net/2010/02/python-and-http-pipelining/
11. https://gitlab.com/pgjones/quart?source=post_page---------------------------
12. https://gitlab.com/pgjones/quart/blob/master/docs/http2_tutorial.rst
13. https://hyper.readthedocs.io/en/latest/

Hacking "Temporal Locality"

Introduction

The reason for this blog post is to analyse certain types of attacks that relate to cache manipulation and recently resurfaced by various BlackHat and Defcon presentation. More specifically we are interested in the following type of attacks:

• Web Cache Poisoning Attacks 
• Web Cache Deception Attacks

About the cache

Many people fail to understand what exactly what is a Web cache, and therefore, I am going to invest a lot of time to analyse and explain what is a cache from Hacker/Security Professional perspective, when conducting a pentest or simple hacking a site.

The cache

In computing, a cache is a hardware or software component that stores data so that future requests for that data can be served faster [1]. Hmm interesting, very interesting, also the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere [1]. So data might be replicated to other locations within the system that serves the content. A cache hit occurs when the requested data can be found in a cache, while a cache miss occurs when it cannot. Cache hits are served by reading data from the cache, which is faster than recomputing a result or reading from a slower data store; thus, the more requests that can be served from the cache, the faster the system performs.

Some companies host their own cache using software like Varnish, and others opt to rely on a Content Delivery Network (CDN) like Cloudflare, with caches scattered across geographical locations. Also, some popular web applications and frameworks like Drupal have a built-in cache. [3]

The diagram above we have a simplified scenario, were the user has two different paths:

• 1 blue - 2 blue - 3 yellow and 4 yellow 
• 1 blue - 2 blue - 3 orange 

The path to be followed (aka. user flow interaction with the target web system) depends on the cache device internal decision process. Cache device internal decision process, simplistically speaking is the the cache device algorithm used to make decisions on what content would be served, and the part we would be interested in hacking or subverting.     

Cache manipulation

The following diagram demonstrates how someone can potentially manipulate the web cache to extract sensitive information:

The legitimate user in Step 1 interacts with the web cache system (aka. the web server and the front end web cache system) and submit/retrieve sensitive content (which should not be cached in the first place). The hacker assesses the rules the cache server is using to store local user content (e.g. identify through experimentation which URL paths are being stored in the cache server etc.) copies and start retrieving sensitive information.

Web caching is a core design feature of the HTTP protocol meant to minimize network traffic while improving the perceived responsiveness of the system as a whole. Caches can be found at every level of a content's journey from the original server to the browser. [6]

Web caching works by caching the HTTP responses for requests according to certain rules. Subsequent requests for cached content can then be fulfilled from a cache closer to the user.

What usually is cached?

Certain content lends itself more readily to caching than others. Some very cache-friendly content for most sites are:

• Logos and brand images
• Non-rotating images in general (navigation icons, for example)
• Style sheets
• General Javascript files
• Downloadable Content
• Media Files
• HTML pages
• Rotating images
• Frequently modified Javascript and CSS
• Content requested with authentication cookies[6]

Putting things in perspective

In order to understand the importance/complexity of the attack it is better to elaborate that high traffic systems (e.g. media content servers etc.)  use multiple cache servers. Usually these type of systems assign web cache servers to whole regions (e.g. USA Region cache, EU Region cache etc.). These regions might be whole countries or even continents. Therefore  the significance of the impact depends on the following two factors:

• The scope of the vulnerable cache servers
• The content exposed through the cache servers

The following diagram demonstrate the issue:

The following diagram demonstrates a complicated infrastructure on cache management:

Note: In order for an attacker to attack the system she would have to assess the set of the rules of all the intermediate cache proxies.

Web cache criteria 

Web cache is achieved through the the "web cache keys". A web cache key is an identifier of a resource located on the web server. As a study case we will refer to the Akamai community posts to see how web cache keys as configured.

The following section is community post describing the concept of the Akamai Cache Key. This information is deduced from several Akamai configuration settings posted in the past. Issues discussed are:

• How does the Edge Server knows which File needs to be cached?
• How does the Edge Server retrieve the cached object from the “Cache Store”?

Note1: Content is cached on the so called “Cache Store”. The “Cache Store” does represent either the Memory (RAM) or Hard disk of a certain Edge Server.

Note2: An Akamai Edge server, is a cache server delivering content. To retrieve an object from the Akamai Platform, users must connect to an Akamai Edge server first. The server must apply a set of rules to the request, and then either locate the object in its cache or retrieve it from the origin. [12]

Note3: Also see sources [9] and [10].

The following diagram demonstrates a simple topology of an Akamai network:

To store an object on the Edge Server “Cache Store” we need to create the “Cache Key” first. The EdgeSuite Configuration Guide does mention that the Akamai Edge Server forms the “Cache Key”  based on parts of the "Request ARL".[11]

The ARL (Akamai Resource Location) is similar to an URL.The primary function of an ARL is to direct an end user’s request for an object to the Akamai network [13]. The ARL also contains the object’s caching properties.. The difference being that the ARL is specifically defined for objects to be served via the Akamai Network. There are two types of ARLs:

1. ARL v1: This is the original ARL used in the earlier days of Akamai. It contains instructions for the Edge Server coded into its structure
2. ARL v2: Instead of coding all instruction into the URL like done for ARL v1, ARL v2 does reference a Configuration File hosted on the Edge Server.

ARL Components which form the Cache Key:

• Typecode
• Forward [fwd] path (origin server, pathname, filename and extension)
• Query string (Optional)
• Secure Network Delivery Indicator
• HTTP Method (GET, HEAD, etc.)

Note: The following description count mainly for ARL v2, we are not going to elaborate on ARL v1 as this are not used that often nowadays.

The following diagram breaks the ARL format:

The following section demonstrates the web cache keys using sample HTTP requests:

Request:

GET /products.jsp?productId=1 HTTP/1.1host: shop.edgegate.deUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0Accept: */*Pragma: akamai-x-get-cache-key

Response:

HTTP/1.1 200 OKContent-Type: text/html; charset=iso-8859-1Server: Google FrontendCache-Control: private, max-age=0Expires: Thu, 17 Dec 2015 00:00:06 GMTDate: Thu, 17 Dec 2015 00:00:06 GMTContent-Length: 1127X-Cache-Key: /L/1168/78685/1m/edgegatecpinotossi.appspot.com/products.jsp?productId=1Connection: keep-alive

Note: The text marked in red designate the web cache key. 

The following table explains the values used as web cache keys:

Name	Value
Typecode	L
Serial	1168
CPCode	78685
TTL	1m
fwd Path	edgegatecpinotossi.appspot.com/products.jsp
Query String	?productId=1

Before the attack: Reconnaissance

Before progressing with any type of cache manipulation it does worth the trouble to review the route path the targeted web server. Running a query on Robtext on google.com will give us a lot of information that can be used to see if a cache proxy is used.

Below you can see en extract of the output in Robtext (https://www.robtex.com/dns-lookup/google.com#owhois):

Note: Using also other manual tools to see if there is a cache proxy in front of the webservice.


Finally the attack: Web Cache deception

Web cache deception occurs when the target website is configured to be "flexible" about what kinds of paths it can handle (aka. URL(s)). For more information on what a URL is see https://www.rfc-editor.org/info/rfc1738 . This make sense from usability perspective e.g. by the product being tolerant on certain types of inputs becomes more user friendly. Also this has to do how each software vendor interprets the RFC related to the URL structure.

In particular, the issue arises when requests to a path that doesn't exist (say /x/y/z) are treated as equivalent to requests to a parent path that does exist (say /x). For example, what happens if you get a request for the nonexistent path /newsfeed/foo? Depending on how your website is configured, it might just treat such a request as equivalent to a request to /newsfeed. For example, if you're running the Django web framework, the following configuration would do just that because the regular expression ^newsfeed/ matches both newsfeed/ and newsfeed/foo (Django routes omit the leading /): [14]

from django.conf.urls import url
patterns = [url(r'^newsfeed/', ...)]

And here's where the problem lies. If your website does this, then a request to /newsfeed/foo.jpg will be treated as the same as a request to /newsfeed. But a web cache, seeing the .jpg file extension, will think that it's OK to cache this request. Because usually most of the web caches proxies by default store image file extensions. [14]

Below we can see a schematic analysis of the issue:

Note: In the following diagram above we can see the how a malicious user can request the home page of the user. At this point is assumed that the home page contains sensitive information and requires some kind of login. In this example is also assumed that the cache server stores local copies of the site images.

It does also worth saying that this is a simplified, and that is someone would like to perform a more complicated attack would have to:

• Understand the scope of the cache server e.g. region cache server.
• Understand the cache rules of the cache server e.g. Akamai ARL etc.
• Identify target content of interest e.g. sensitive content etc.   

Note: It does also worth mentioning that identifying how both the web and cache server "understand" the URL structure is also important e.g. experimenting with malicious paths, such as mangled back slashes etc. This also relates to what is considered acceptable also from the browsers.


Finally the attack: Web Cache poisoning 

The objective of web cache poisoning is to send a request that causes a harmful response that gets saved in the cache and served to other users. The following diagram shows the process to follow:

James Kettle (aka. @albinowax) has done an amazing job documenting the vulnerability and wrote about multiple scenarios and ways to exploit the specific vulnerability. More specifically described the following scenarios:

• Selective Poisoning
• DOM Poisoning
• Hijacking Mozilla SHIELD
• Route poisoning
• Hidden Route Poisoning
• Chaining Unkeyed Inputs
• Open Graph Hijacking
• Local Route Poisoning
• Internal Cache Poisoning
• Drupal Open Redirect
• Persistent redirect hijacking
• Nested cache poisoning
• Cross-Cloud Poisoning

A simplified version of an attack scenario would be to:

a simple example of Web Cache poisoning would that assuming that the cache key is the X-Forwarded-Host HTTP header. we can Inject our own variable and then echoed it back in a cache level.

This is taken from https://portswigger.net/blog/practical-web-cache-poisoning :

Request:

GET /en?cb=1 HTTP/1.1

Host: www.redhat.com

X-Forwarded-Host: canary

Response:

GET /en?cb=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: canary

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…

<meta property="og:image" content="https://canary/cms/social.png" />

In the example above we saw that the cache key was echoed back in the html body. The X-Forwarded-Host header has been used by the application to generate an Open Graph URL inside a meta tag. In this scenario we can assume that this can be converted into an XSS, HTML or other type of client side injection attack.

Defending against Web Cache attacks

The best way to defend against this attack is to ensure that your website isn't so permissive, and never treats requests to nonexistent paths. Also that:

• Use the same URL to refer to the same items: Since caches key off of both the host and the path to the content requested, ensure that you refer to your content in the same way on all of your pages. The previous recommendation makes this significantly easier. [6]
• Fingerprint cache items: For static content like CSS and Javascript files, it may be appropriate to fingerprint each item (per user session). This means adding a unique identifier to the filename (often a hash of the file) so that if the resource is modified, the new resource name can be requested, causing the requests to correctly bypass the cache. [6]
• Write your custom cache rules: A web cache server has to be aware of the application content and nature e.g. not caching dynamic content on banking application etc.    
• Avoid taking input from headers and cookie: Simply filter HTTP headers and cookies by running integrity checks.
• Disable cache if not required: Lots of services don't require caching, but because is enabled by default the allow it.

Tools for cache poisoning/deception 

The following section demonstrates tools that can be used to manipulate cache poisoning: 

• param-miner: This extension identifies hidden, unlinked parameters. It's particularly useful for finding web cache poisoning vulnerabilities.[3]
• Burp Suite Free/Pro: Intruder component [16]

References:

• https://en.wikipedia.org/wiki/Cache_(computing)  [1]
• https://portswigger.net/blog/practical-web-cache-poisoning [2]
• https://github.com/PortSwigger/param-miner [3]
• https://www.reddit.com/r/netsec/comments/9668sd/practical_web_cache_poisoning/ [4]
• https://blog.cloudflare.com/understanding-our-cache-and-the-web-cache-deception-attack/ [5]
• https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies [6]
• https://support.cloudflare.com/hc/en-us/articles/202775670-How-Do-I-Tell-Cloudflare-What-to-Cache- [7]
• https://www.smashingmagazine.com/2017/11/understanding-vary-header/ [8]
• https://tools.ietf.org/html/rfc8246#page-4 [9]
• https://tools.ietf.org/html/rfc5861 [10]
• https://community.akamai.com/customers/s/article/Cache-Keys-Why-we-should-know-them?language=en_US [11]
• https://developer.akamai.com/legacy/learn/Overview/Client_Edge_Servers_Origin.html [12]
• https://learn.akamai.com/en-us/webhelp/pulsar-diagnostic-tools/pulsar-diagnostic-tools/GUID-54157798-C972-44C3-9B45-8E09A93A37F0.html [13]
• https://blog.cloudflare.com/understanding-our-cache-and-the-web-cache-deception-attack/ [14]
• https://omergil.blogspot.com/2017/02/web-cache-deception-attack.html [15]
• https://portswigger.net/burp [16]
• https://support.cloudflare.com/hc/en-us/articles/360023040812-Best-Practice-Caching-Everything-While-Ignoring-Query-Strings [17]

Hacker’s Elusive Thoughts The Web

Introduction

The reason for this blog post is to advertise my book. First of all I would like to thank all the readers of my blog for the support and feedback on making my articles better. After 12+ years in the penetration testing industry, the time has come for me to publish my book and tranfer my knowledge to all the intersted people that like hacking and want to learn as much as possible. Also at the end of the blog you will find a sample chapter.

About The Author

Gerasimos is a security consultant holding a MSc in Information Security, a CREST (CRT), a CISSP, an ITILv3, a GIAC GPEN and a GIAC GAWPT accreditation. Working alongside diverse and highly skilled teams Gerasi- mos has been involved in countless comprehensive security tests and web application secure development engagements for global web applications and network platforms, counting more than 14 years in the web application and application security architecture.

Gerasimos further progressing in his career has participated in vari- ous projects providing leadership and accountability for assigned IT security projects, security assurance activities, technical security reviews and assess- ments and conducted validations and technical security testing against pre- production systems as part of overall validations.

Where From You Can Buy The Book

This book can be bought from leanbup. Leanpub is a unique publishing platform that provides a way in the world to write, publish and sell in-progress and completed ebooks. Anyone can sign up for free and use Leanpub's writing and publishing tools to produce a book and put it up for sale in our bookstore with one click. Authors are paid a royalty of 90% minus 50 cents per transaction with no constraints: they own their work and can sell it elsewhere for any price.

Authors and publishers can also upload books they have created using their own preferred book production processes and then sell them in the Leanpub bookstore, taking advantage of our high royalty rates and our in-progress publishing features.

Please for more information about bying the book see link: https://leanpub.com/hackerselusivethoughtstheweb

Why I Wrote This Book

I wrote this book to share my knowledge with anyone that wants to learn about Web Application security, understand how to formalize a Web Appli- cation penetration test and build a Web Application penetration test team.

The main goal of the book is to: 

Brainstorm you with some interesting ideas and help you build a com- prehensive penetration testing framework, which you can easily use for your specific needs. Help you understand why you need to write your own tools. Gain a better understanding of some not so well documented attack techniques.

The main goal of the book is not to:

 
Provide you with a tool kit to perform Web Application penetration tests. Provide you with complex attacks that you will not be able to under- stand. Provide you with up to date information on latest attacks.

Who This Book Is For 

This book is written to help hacking enthusiasts to become better and stan- dardize their hacking methodologies and techniques so as to know clearly what to do and why when testing Web Applications. This book will also be very helpful to the following professionals:

1. Web Application developers.
2. Professional Penetration Testers.
3. Web Application Security Analysts.
4. Information Security professionals.
5. Hiring Application Security Managers.
6. Managing Information Security Consultants.

How This Book Is Organised  

Almost all chapters are written in such a way so as to not require you to read the chapters sequentially, in order to understand the concepts presented, although it is recommended to do so. The following section is going to give you an overview of the book:

Chapter 1: Formalising Web Application Penetration Tests -

This chapter is a gentle introduction to the world of penetration testing, and attempt to give a realistic view on the current landscape. More specifically it attempt to provide you information on how to compose a Pen- etration Testing team and make the team as ecient as possible and why writing tools and choosing the proper tools is important.

Chapter 2: Scanning With Class -

The second chapter focuses on helping you understand the dierence between automated and manual scanning from the tester’s perspective. It will show you how to write custom scanning tools with the use of Python. This part of the book also contains Python chunks of code demonstrating on how to write tools and design your own scanner.

Chapter 3: Payload Management -

This chapter focuses on explaining two things a) What is a Web payload from security perspective, b) Why is it important to obfuscated your payloads.

Chapter 4: Infiltrating Corporate Networks Using XXE -

This chapter focuses on explaining how to exploit and elevate an External Entity (XXE) Injection vulnerability. The main purpose of this chapter is not to show you how to exploit an XXE vulnerability, but to broaden your mind on how you can combine multiple vulnerabilities together to infiltrate your target using an XXE vulnerability as an example.

Chapter 5: Phishing Like A Boss -

This chapter focuses on explaining how to perform phishing attacks using social engineering and Web vulnerabilities. The main purpose of this chapter is to help you broaden your mind on how to combine multiple security issues, to perform phishing attacks.

Chapter 6: SQL Injection Fuzzing For Fun And Profit -

This chapter focuses on explaining how to perform and automate SQL injection attacks through obfuscation using Python. It also explains why SQL injection attacks happen and what is the risk of having them in your web applications.


Sample Chapter Download

From the following link you will be able to download a sample chapter from my book:

Sample Book Download