Almost two years after first being documented, Web Cache Deception attacks are still a major issue, and they still impact many popular websites.
New academic research published this month reveals that 25 of the Alexa Top 5,000 websites are still impacted by Web Cache Deception (WCD) attacks.
While the number is small, academics say these websites have “substantial user populations,” allowing attackers to retrieve personal user information from a user’s account without having to authenticate.
What is a Web Cache Deception attack
Web Cache Deception attacks were first disclosed in February 2017. They were discovered by Omer Gil, a security researcher, and bug hunter.
Gil found that many of today’s popular websites would cache pages that contained a user’s personal information. These cached pages would be stored inside a website’s front-facing content delivery network (CDN), readily available to anyone on the internet, effectively bypassing login requirements.
Cached sensitive content included backend dashboards, settings sections, pages with financial details, etc. — pages usually exempt from a website’s caching procedures.
The trick, Gil said, was for an attacker to convince a user to access a boobytrapped URL that had the following structure: [LEGITIMATE_DASHBOARD_URL]/[NON-EXISTENT_FILE]
An example would be:
If the user clicked and accessed one of these booby-trapped links, a website’s CDN would cache the user’s personal dashboard, along with all the data found inside, and store it on the website’s public, front-facing CDN server.
An attacker would only have to access the original boobytrapped URL and retrieve that particular user’s dashboard content.
Gil said the attack wasn’t restricted to web-related files like JS and CSS, and that attackers could create booby-trapped URLs with more than 40 different file extensions.
Using any of the file extensions to create a non-existent URL tricked a website’s CDN into caching a page with sensitive information, even if the link they pointed to didn’t exist, or the page was specifically blacklisted.
In 2017, Gil said he tested only around 30 popular websites and found that only three were vulnerable to WCD attacks, naming only PayPal.
In an interview with this reporter at the time, Gil said he only tested websites that had a public bug bounty program and said he believed the issue was far more widespread than his initial and very limited research.
Testing more sites for WCD attacks
In an academic paper published this month, a team of six researchers expanded Gil’s original work to the top 5,000 most popular websites on the internet, according to the Alexa ranking.
They not only tested WCD attacks that relied on loading non-existent files, but also explored various other forms of malformed URLs, expanding the WCD attack surface with new attack variations. The WCD attack variations the research team tested are listed in the image below.
The research team ran their experiment twice, 14 months apart. For the first run, they selected 295 websites from the Alexa Top 5,000 list, websites that had a backend storing sensitive data. For the second run, they expanded the list to 340 websites.
After both experiments, researchers said that 25 high-traffic sites with “considerable user populations” were vulnerable to WCD attacks.
“Our second experiment showed that in the fourteen months between our two measurements, only 12 out of 16 sites were able to mitigate their WCD vulnerabilities, while the total number of vulnerabilities rose to 25,” researchers said.
In most cases, the websites were vulnerable due to improperly configured CDN caching rules, researchers said. However, the research team didn’t fault CDN providers, but rather website operators.
“One reason for this slow adoption of necessary mitigations could be a lack of user awareness. However, the attention WCD garnered from security news outlets, research communities, official web cache vendor press releases, and even mainstream media also suggests that there may be other contributing factors.”
These factors include the lack of any free or official tools to check if a website’s CDN configuration is vulnerable to attacks and the sheer amount of effort needed to test CDN configurations.
“The empirical evidence we presented […] suggests that configuring web caches correctly is not a trivial task,” the research team said. “Moreover, the complexity of detecting and fixing a WCD vulnerability is disproportionately high compared to launching an attack.”
“We do not believe that these observations implicate CDN vendors in any way, but instead emphasize that CDNs are not intended to be plug&play solutions for business applications handling sensitive data,” researchers said. “All CDNs provide fine-grained mechanisms for caching and traffic manipulation, and site owners must carefully configure and test these services to meet their needs.”
All in all, website operators don’t seem to be aware of the full spectrum of WCD attacks, or they don’t know how to research and fully mitigate these attacks.
ZDNet readers who’d like to learn more can consult the researchers’ white paper, titled “Cached and Confused: Web Cache Deception in the Wild,” which will be presented at the Usenix security conference next year, in August 2020.