We observed a page which had the following insufficient cache control configurations:
/WebGoat/login
No cache controls detected
What's the risk?
By default, web browsers and proxies aggressively cache web content, including pages as well as their static content. In response to the given URL(s), the application doesn't effectively inform the browsers to not save this content on the client side.
Recommendation
There are a couple ways in the HTTP response to tell the browser and any intervening proxies to not cache this data. Given the ever increasing number of browser and proxy version permutations, keeping up to date with what browser or proxy requires what cache control is hard, and thus our recommendation is to issue a combination of caching controls in order to properly inform user agents of different types of the application's intentions.
Issuing only a subset of these controls guarantees that some version of some browser or proxy will retain the page data when it shouldn't.
The easiest way to prevent this issue from occurring in Java EE applications is to add these
setHeader() calls to a servlet filter for all sensitive content:
At a minimum, Contrast expects to see a Cache-Control setting that contains
no-store and no-cache. This will alleviate client-side browser caching
concerns in modern browsers. This control can be delivered with a setHeader() call or
a <meta> tag.
First Event
(no event)
Last Event
(no event)
HTTP Request
GET http://localhost:8080/WebGoat/login HTTP/1.0
Accept-Language: en-US,en;q=0.5
Cookie: JSESSIONID=B73327F913BCE80911DBC6731850CABE; AJS.conglomerate.cookie="|config.sidebar.planNavigator.expanded=true|tabContainer.tabContainer.selectedTab=Capabilities|tabContainer.remote-agents-tabs.selectedTab=Online remote agents"; language=en
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:73.0) Gecko/20100101 Firefox/73.0
Upgrade-Insecure-Requests: 1
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Vulnerability ID: FXDT-NDLW-MULW-V3Q5
Application Name: WebGoat
Vulnerability Link: http://localhost:19080/Contrast/static/ng/index.html#/7c6cfec5-a187-4d5e-984a-d11d96d2ef63/applications/1f21baa2-741d-47df-a8ea-89ea70b18615/vulns/FXDT-NDLW-MULW-V3Q5
What Happened?
We observed a page which had the following insufficient cache control configurations:
/WebGoat/login No cache controls detected
What's the risk?
By default, web browsers and proxies aggressively cache web content, including pages as well as their static content. In response to the given URL(s), the application doesn't effectively inform the browsers to not save this content on the client side.
Recommendation
There are a couple ways in the HTTP response to tell the browser and any intervening proxies to not cache this data. Given the ever increasing number of browser and proxy version permutations, keeping up to date with what browser or proxy requires what cache control is hard, and thus our recommendation is to issue a combination of caching controls in order to properly inform user agents of different types of the application's intentions.
Issuing only a subset of these controls guarantees that some version of some browser or proxy will retain the page data when it shouldn't.
The easiest way to prevent this issue from occurring in Java EE applications is to add these setHeader() calls to a servlet filter for all sensitive content:
response.setHeader("Cache-Control","no-store, no-cache, must-revalidate"); //HTTP 1.1 controls response.setHeader("Pragma","no-cache"); //HTTP 1.0 controls response.setDateHeader ("Expires", 0); //Prevents caching on proxy servers
If setting headers is difficult in your infrastructure, you can also simulate them via meta tags in the HTML sent to the browser:
<meta http-equiv="Cache-Control" content="no-store, no-cache, must-revalidate"> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Expires" content="0"></pre>
At a minimum, Contrast expects to see a Cache-Control setting that contains no-store and no-cache. This will alleviate client-side browser caching concerns in modern browsers. This control can be delivered with a setHeader() call or a <meta> tag.
First Event
(no event)Last Event
(no event)HTTP Request
GET http://localhost:8080/WebGoat/login HTTP/1.0 Accept-Language: en-US,en;q=0.5 Cookie: JSESSIONID=B73327F913BCE80911DBC6731850CABE; AJS.conglomerate.cookie="|config.sidebar.planNavigator.expanded=true|tabContainer.tabContainer.selectedTab=Capabilities|tabContainer.remote-agents-tabs.selectedTab=Online remote agents"; language=en Host: localhost:8080 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:73.0) Gecko/20100101 Firefox/73.0 Upgrade-Insecure-Requests: 1 Connection: keep-alive Accept-Encoding: gzip, deflate Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8