• Home
  • Hacking & Security
    • Network Hacking
    • Web Hacking
    • Social Engineering
    • Kali Linux
    Submit An Article
  • Courses
    • All Courses
    • Bundles
    • Masterclass
    • VIP Membership
    • FAQ

    Popular Courses

  • Shop
    • Hardware Bundles
    • Wireless Adapters
    • Pentesting Tools
    • Security
    • Accessories
    • Clothing
    • Books
    • All
  • Competition
  • Services
    Penetration Testing
    Consulting
    Code Review
    One on one Training
    Online Courses
    VPN
  • Blog
      • Cart

    VIP Membership Masterclass
    Got a question?
    [email protected]
    RegisterLogin
    zSecurity
    • Home
    • Hacking & Security
      • Network Hacking
      • Web Hacking
      • Social Engineering
      • Kali Linux
      Submit An Article
    • Courses
      • All Courses
      • Bundles
      • Masterclass
      • VIP Membership
      • FAQ

      Popular Courses

    • Shop
      • Hardware Bundles
      • Wireless Adapters
      • Pentesting Tools
      • Security
      • Accessories
      • Clothing
      • Books
      • All
    • Competition
    • Services
      Penetration Testing
      Consulting
      Code Review
      One on one Training
      Online Courses
      VPN
    • Blog
        • Cart

      Hacking & Security

      Exploiting Secondary Vulnerabilities via Web Cache Poisoning Attacks

      • Posted by Lumena Mukherjee
      • Date April 14, 2020

      Web app attacks increased by 52% in 2019 — here’s what to know about how web cache poisoning moved from being a theoretical vulnerability to an exploitable one

      Let’s face it: Nobody likes to wait a million years for a webpage to load. This is why the internet has so many blogs on website speed optimisation and how it influences conversion rates. Web caching is one of those breakthroughs that serves a two-fold purpose — it reduces the load on web servers and also improves the end user experience.

      Compromising the cache was only considered a theoretical scenario — one too complex to be pulled off practically — up until a few years ago. In the following sections, before we dive into exploiting secondary vulnerabilities (like XSS) through web cache poisoning, we’ll break down what web caching is and how it works.

      Let’s get started!

      What Is Web Caching?

      Caching, in general, can refer to a page cache, a browser cache, or a server cache — all of which are components that store data for faster retrieval. But for our purposes, we’ll be looking at server-side caching. In this case, a server-side cache is a repository that sits between one or many clients and server(s). Its goal is to improve response time by delivering locally saved copies of frequently requested resources instead of querying the back-end server.

      The idea here is that by reducing latency (the time lag between when a client requests a resource and when it actually arrives) and delivery speeds, it makes the site seem more responsive.

      How Web Caching Works

      Let’s consider the following example to explain how caching works:

      Suppose there are five users, numbered 1 to 5, who try to fetch the same resource (an image, a webpage, etc.) consecutively, one after the other. What happens is that when user 1 submits the request for the first time, the server-side cache saves a local copy on it. Upon receiving subsequent requests for the same resource from the other users, the response saved on the cache is served instead of having to communicate again with the back-end server. Caching boosts the speed at which the page loads for users, and results in reduced loads on the server, as there are fewer requests to serve.

      This brings us to the question – how does the cache identify whether user 2 or 3 is requesting the same resource as user 1? It’s here that the concept of “cache keys” comes into play. While these cache keys may contain an HTTP host, a query string, or an HTTP scheme, they mostly consist of the request line and the host header

      Consider the request below:

       

      The cache key in the example request above comprises only of the “GET” request line and the host header while the rest of the request is considered as the unkeyed input.

      But what happens when something goes wrong with the unkeyed input? This is where things get really interesting (and dangerous).

      What is Web Cache Poisoning?

      Much like what the name implies, web cache poisoning is a type of cyber attack that involves a hacker “poisoning” the data cache that’s used to respond to other users’ requests. Essentially, it’s turning these caches into exploit delivery systems that can be used to send harmful responses.

      Web cache poisoning relies on unkeyed inputs that are those parts of a request that do not form the “cache key.” James Kettle, Director of Research at PortSwigger, took advantage of the web caches of several websites to turn them into systems that could deliver a payload to other people visiting the site. He says that although cache poisoning has a bad reputation, it’s actually quite simple to exploit.

      A typical web cache poisoning scenario can be broken down, as shown below:

      1. The attacker identifies the unkeyed input either manually or using a tool (like Param Miner, an extension to Burp).
      2. The attacker crafts a malicious request to see whether it gets reflected in the response without being properly sanitized, or if it affects the processing of other data.
      3. After a harmful response is received from the back-end server, it’s time for the next step in the process where the attacker tries to cache the response.
      4. Once that’s done, your exploit gets delivered to any user who accesses the website.

      In the next section, we’ll do a quick review of XSS before we see how to exploit it via web cache poisoning.

      What Is Cross-Site Scripting (XSS)?

      Cross-site scripting flaws have continued to appear in the OWASP Top 10 vulnerability list since its first publication in 2003. Though it moved down in the list in 2017, as other vulnerabilities became more pronounced, it continues to be one of the most common security concerns across applications.

      An XSS vulnerability arises when an attacker manipulates HTTP requests from an otherwise trusted resource in a way that it gets reflected in the response without proper input filtering or sanitization. This leads to the execution of malicious code in the victim’s browser and can be used to steal cookies, hijack sessions, spread malware, etc.

      XSS attacks can be classified into three main types of attacks:

      • reflected,
      • stored, or
      • DOM-based.

      To give you an example, consider the following HTTP request/response to see how a malicious script gets reflected in the response:

      If the application had proper checks (such as input filtering, output encoding, etc.) in place, the input would’ve been discarded as an unexpected input, or the HTML tags would’ve been treated as data upon being encoded. Encoding involves changing the data format from one form to another. For example, characters like “<,” “>,” etc. should always be HTML encoded as “&lt,” “&gt” and so on to prevent them from being executed as code or breaking out of context in other ways.

      And now, we move on to an example scenario of web cache poisoning. Shall we begin?

      Example Scenario Using the Web Security Academy Lab

      The scenario described below is from PortSwigger’s vulnerability labs in their Web Security Academy. You can create an account and try out these labs on your own or attempt the challenge on hackxor. The request/response screenshots are taken from the lab that explains using web cache poisoning to exploit unsafe handling of resource imports.

      In the following example, I’ve attempted to show how the requests can be modified to poison the cache without getting into the details of how to solve the lab step by step. Once you access the lab, it takes us to a dummy ecommerce website containing a web cache poisoning vulnerability in its home page. Let’s take a look:

      1.Once your browser proxy settings are configured to send traffic via Burp, it can be set to capture both requests and responses. The snip below shows the original lab homepage traffic that we’re trying to poison with our malicious payload.

      2. The lab also comes with an exploit server where we can store the payload we intend to deliver.

      3. I’ve sent the original request to the Burp repeater, then added the exploit server URL (which is controlled by the attacker) in the X-Forwarded-Host field. In place of the original host header, the application uses the link mentioned as the X- Forwarded-Host to dynamically generate a URL to download a JavaScript resource. The link mentioned in the X-Forwarded-Host header contains the payload (in this case, an alert pop-up). The request is replayed till we get a cache hit.

       

      (Note: Including the X-Forwarded-Host as a cache key when it does not hold the same value as the Host field, could’ve prevented this vulnerability.)

       

      4. Once we get a cache hit, the payload gets delivered to any user visiting the same lab home page link.

       

      How Do You Mitigate Cache Poisoning Attacks?

      The most secure way to achieve this is to avoid caching altogether or to include everything in your cache keys. However, since in most cases, that’s either not feasible or it defeats the purpose of caching, we can adopt the following precautions:

      • Ensure that secondary vulnerabilities don’t exist within your application. Running web scans, conducting manual tests, etc. to assess your application for any potential security flaws is always a good practice.
      • Restrict where caching is done and what is cached. For instance, you might want to limit caching at a single point or only cache static responses. Additionally, certain services (like CDNs) may have caching enabled by default and leave websites vulnerable to cache poisoning attacks.
      • Be selective about your unkeyed inputs. Disable unkeyed inputs where feasible. Carefully consider what goes into your unkeyed inputs as they can be manipulated to incorporate harmful payloads.

      In Summary

      Hopefully, by now, you have a basic understanding of what web cache poisoning is, why it’s no longer considered a theoretical vulnerability, and how placing a cache in front of web servers can provide entry points to exploit secondary vulnerabilities in the application. Since caching improves performance, disabling it might not be sustainable for the most part. However, taking necessary precautions such as regular vulnerability scans, or auditing every page within the application to understand how unkeyed inputs are handled, is equally crucial for avoiding security risks.

      • Share:
      author avatar
      Lumena Mukherjee

      Lumena is a cybersecurity consultant, tech writer, and regular columnist for InfoSec Insights at Sectigo Store(sectigostore.com). She is currently pursuing her Master's in Cybersecurity and has a passion for helping companies implement better security programs to protect their customers' data.

      Previous post

      What Is Bitcoin / Cryptocurrency & How Does It Work?
      April 14, 2020

      Next post

      Get Windows Log in Password !
      April 18, 2020

      You may also like

      secrets_370x208
      Unlocking Secrets: How to Crack SHA256 Passwords with Hashcat
      30 March, 2023
      domain-controllers_370x208
      Identifying Domain controller in a network
      24 March, 2023
      storm-braker_370x208
      Access Location, Camera & Mic of any Device 🌎🎤📍📷
      23 March, 2023

        1 Comment

      1. Hussein Muhaisen
        April 16, 2020
        Log in to Reply

        Such a Great Article ! Appreciate The time you took writing it <3

      Leave A Reply Cancel reply

      You must be logged in to post a comment.

      Categories

      • Cryptography
      • Cryptography
      • CTF
      • Forensics
      • Hacking & Security
      • Hardware
      • IOT
      • Kali Linux
      • Network Hacking
      • News
      • OSINT
      • Post Exploitation
      • Post Exploitation
      • Privacy
      • Programming
      • Security
      • Social Engineering
      • Uncategorized
      • Web Hacking

      Popular Posts

      Got a Blank Screen After Importing Kali in Virtual Box ? Here’s How To Fix It
      25Jan2018

      Connect with us

      • Facebook
      • Twitter
      • LinkedIn
      • Instagram
      • Youtube

      “Everything related to ethical hacking

      & cyber security in one place.”

      Quick Links

      • Home
      • About Us
      • Hacking & Security
      • Download Custom Kali
      • Contact
      • FAQ

      Services

      • Penetration Testing
      • Consulting
      • Code Review
      • One on one training
      • VPN
      • VIP Membership

      Company

      • About Us
      • Contact
      • Vulnerability Disclosure

      Support

      • FAQ
      • Forums

      Copyright © 2022 Z IT SECURITY LTD t/a zSecurity. All rights reserved.

      • Privacy
      • Shipping
      • Refunds
      • Terms

      Contribute

      Share your knowledge with the world

      SUBMIT AN ARTICLE

      Login with your site account

      Lost your password?

      Not a member yet? Register now

      Register a new account


      Are you a member? Login now

      Enroll in this course to access this lesson!

      All of our courses include:

      ✔ Lifetime, unlimited access to course materials & training videos.

      ✔ Watch online or download lectures for offline use.

      ✔ Verifiable certificate of completion from zSecurity, signed by the course instructor, Zaid.

      ✔ Get answers from our Support Team within a maximum of 15 hours.

      ✔ Unlimited Updates.

      Get free 1 month VIP membership per course with:

      ✔ Live mentorship and Q&A session with the course instructor, Zaid.

      ✔ Instant support from community members through our private discord channel.

      ✔ Daily updates with the latest tutorials & news in the hacking world.

      ✔ Daily resources like CTFs, bug bounty programs, onion services and more!

      ✔ Access our VIP community & connect with like-minded people.

      ✔ Discounts on other zSecurity products and services.

      We are using cookies to give you the best experience on our website. This includes but is not limited to:

      • Storing your settings and preferences.
      • Remember your access information
      • Track website performance and make our website more relevant to you.

      You can find out more about which cookies we are using or switch them off in settings.

      Privacy Overview

      This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

      Strictly Necessary Cookies

      Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

      3rd Party Cookies

      This website uses Google Analytics and Linkedin to collect anonymous information such as the number of visitors to the site, and the most popular pages.

      Keeping this cookies enabled helps us to improve our website.

      Please enable Strictly Necessary Cookies first so that we can save your preferences!

      Powered by  GDPR Cookie Compliance