Add Testing For Web Cache Deception

[cyspad]

Testing for Web Cache Deception

ID
WSTG-ATHN-12

Summary

In this phase the tester checks that the application correctly instructs the cache server to not retain sensitive data.
Web Cache Deception (WCD) is an attack in which an attacker deceives a caching proxy into improperly storing private information sent over the internet and gaining unauthorized access to that cached data. It was proposed by Omer Gil, a security researcher in 2017. Web caching is the storing of data for reuse in the same browser. It is one of the most beneficial technologies available to improve user experience and enables better performance standards for the users. It is considered an essential internet infrastructure and one of the most popular CDN (Content Delivery Network). The developers configure web caching functionality to their applications, which caches the web files that are frequently requested from the users so that when a user request one of those files the next time, it is directly served from the cache. Thus, the server does not have to perform the same request repeatedly, which can prevent the server from being overloaded.

We can cache public and static files that do not contain any sensitive information, such as:

• General JavaScript files
• Style sheets
• Downloadable content
• Media files

And the files with sensitive information or single user-specific information, such as assets, banking info, recent orders are not cached.

Although web caching reduces the load on web servers and improves the Internet user’s experience while browsing the web, web cache deception attack puts many Internet users at risk because of the widespread use of web caches and caching proxies deployed by CDN (Content Delivery Network) providers.

Test Objectives

• Make sure CDN caches static files correctly
• Make sure paths are configured correctl

How To Test

Let us consider having an application which is user specific and non-cached, and contains a profile section (https://www.example.com/my_profile).

And the attacker lures the victim to open the malicious crafted link (https://www.example.com/my_profile/test.css), where the file “test.css” does not exist on the web server.

Since it is a non-existent file, the application ignores the “test.css” part of the URL and loads the victim’s profile page. Also, the caching mechanism identifies the resource as a style sheet, and caches it.

Then the attacker sends a GET request to the cached page (https://www.example.com/my_profile/test.css), and the victim profile page will be returned.

The web cache deception attack works only when all the following conditions are met:

• When https://www.example.com/my_profile/test.css is requested, the content of https://www.example.com/my_profile should be returned as the response.

• The web caching functionality is configured to cache files based on their extensions.

• And the victim must be authenticated while accessing the maliciously crafted URL.

References

https://beaglesecurity.com/blog/article/web-cache-deception.html

Tools

• OWASP Zed Attack Proxy

Whitepapers

• Web Cache Deception Attack

[kingthorin]

Hey @cyspad if you've already assembled the content you can just go ahead and open a PR.

Note I did notice one typo you'll need to fix correctl.

[kingthorin]

Should probably also reference/cover https://portswigger.net/research/bypassing-web-cache-poisoning-countermeasures (with attribution where appropriate).

[cyspad]

Hey @kingthorin what is issue of this commit? i want to fix or close please help

[kingthorin]

You need to implement the changes in a new branch on your fork then open a PR.

[cyspad]

ok thanks

[kingthorin]

This seems to be a complete rip off of the Beagle article, of which you do not appear to be the author. Please re-write it with your own content.

Edit: Also the PR should be against this repo not your forked repo.

[cyspad]

This seems to be a complete rip off of the Beagle article, of which you do not appear to be the author. Please re-write it with your own content.

Edit: Also the PR should be against this repo not your forked repo.

If in your opinion (if edited correctly) this topic can be approved, I will rebuild it

[kingthorin]

Yes it’s a topic that should be added, if the content is original and not plagiarized.

[cyspad]

Ok @kingthorin i working on Web Cache Deception. please don't close that

[kingthorin]

Sounds good. The PR you opened is against your repo not this one 😉

[cyspad]

Hello Dear @kingthorin

I thought a lot about this test case and came to the conclusion that this test case should be added under the title Testing for Path confusion in the CONF section, because in fact, if this issue is configured correctly, it will prevent attacks such as Web Cache Deception. What is your opinion?