3 - Exploiting origin server normalization for web cache deception

#portswigger #cachedeception #pathtraversal #infodisclosure

Web cache deception lab delimiter list | Web Security Academy

En este caso vamos a tratar de ver como el servidor y el CDN normalizan las urls de path traversal :

Detecting normalization by the origin server

To test how the origin server normalizes the URL path, send a request to a non-cacheable resource with a path traversal sequence and an arbitrary directory at the start of the path. To choose a non-cacheable resource, look for a non-idempotent method like POST. For example, modify /profile to /aaa/..%2fprofile:

• If the response matches the base response and returns the profile information, this indicates that the path has been interpreted as /profile. The origin server decodes the slash and resolves the dot-segment.
• If the response doesn't match the base response, for example returning a 404 error message, this indicates that the path has been interpreted as /aaa/..%2fprofile. The origin server either doesn't decode the slash or resolve the dot-segment.

Ejemplo de como puede ser aprovechada una respuesta normalizada por el servidor pero cacheada por el CDN:

If the origin server resolves encoded dot-segments, but the cache doesn't, you can attempt to exploit the discrepancy by constructing a payload according to the following structure:

/<static-directory-prefix>/..%2f<dynamic-path>

For example, consider the payload /assets/..%2fprofile:

• The cache interprets the path as: /assets/..%2fprofile
• The origin server interprets the path as: /profile

The origin server returns the dynamic profile information, which is stored in the cache.

==Laboratorio== :

Se cachea todo lo que está en /resources :

Conseguimos cachear my-account como una respuesta estática, al estar bajo /resources