Secure page browser cache warning
604 views
Skip to first unread message
Matt Raible
Feb 12, 2013, 11:01:56 AM2/12/13
to zaprox...@googlegroups.com
Hello,
I'm using ZAP 2.0 to test an app I'm working on. I'm getting a "Secure page browser cache" alert for resources that are not HTML. For HTML resources, I'm returning the following in the <head>, which seems to solve this issue.
<meta http-equiv="Cache-Control" content="no-cache"/>
<meta http-equiv="Pragma" content="no-cache"/>
<meta http-equiv="Expires" content="0"/>
To solve this issue for other resources, I've tried adding the following ServletFilter to add these headers.
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1
response.setHeader("Pragma", "no-cache"); // HTTP 1.0
response.setDateHeader("Expires", 0); // Proxies
chain.doFilter(req, response);
}
Unfortunately, this doesn't seem to solve the problem. Any ideas?
Thanks,
Matt
Simon Bennetts
Feb 12, 2013, 11:07:39 AM2/12/13
to zaprox...@googlegroups.com
Hi Matt,
What other resources are you getting this warning on?
We explicitly ignore images in this test - its possible we should be ignoring other types of resources as well.
Cheers,
Simon
What other resources are you getting this warning on?
We explicitly ignore images in this test - its possible we should be ignoring other types of resources as well.
Cheers,
Simon
Matt Raible
Feb 12, 2013, 12:55:30 PM2/12/13
to zaprox...@googlegroups.com
I'm getting it on JS, CSS and some Ajax requests that don't have the following in <head>:
<meta http-equiv="Cache-Control" content="no-cache"/>
<meta http-equiv="Pragma" content="no-cache"/>
<meta http-equiv="Expires" content="0"/>
--
You received this message because you are subscribed to the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Simon Bennetts
Feb 14, 2013, 6:05:53 AM2/14/13
to zaprox...@googlegroups.com
Ah, ok.
First of all, ZAP assumes that anything delivered over https is sensitive and therefore shouldnt be cached.
For JS and CSS files that _could_ be an incorrect assumption for your application.
So have a look at those files, and if you dont mind them being cached in the browser then one option is to just ignore the warnings.
Just imagine someone accessing your app from an internet cafe ;)
The Ajax requests would concern me.
Are they being handled by servlets?
If so then you should be able to set the headers - maybe your filter configuration is incorrect?
I'd put some logging in the filter to see whats going through it.
If you are concerned about the JS and CSS files, then am I right in thinking the JS and CSS are files being served 'directly'?
eg by URLs which refer to the resource, like www.example.com/myapp/javascript/script.js
If so then the server filter wont get called for them as they are not servlets.
One option (which I've implemented before for the same reasons) is to serve the files indirectly, ie creating a servlet just for those files, so you end up with URLs like www.example.com/myapp/FileServlet?file=script.js
Just be sure you dont introduce a 'local file inclusion' vulnerability, otherwise you'll be vulnerable to attacks like www.example.com/myapp/FileServlet?file=../../../../etc/passwd
Cheers,
Simon
First of all, ZAP assumes that anything delivered over https is sensitive and therefore shouldnt be cached.
For JS and CSS files that _could_ be an incorrect assumption for your application.
So have a look at those files, and if you dont mind them being cached in the browser then one option is to just ignore the warnings.
Just imagine someone accessing your app from an internet cafe ;)
The Ajax requests would concern me.
Are they being handled by servlets?
If so then you should be able to set the headers - maybe your filter configuration is incorrect?
I'd put some logging in the filter to see whats going through it.
If you are concerned about the JS and CSS files, then am I right in thinking the JS and CSS are files being served 'directly'?
eg by URLs which refer to the resource, like www.example.com/myapp/javascript/script.js
If so then the server filter wont get called for them as they are not servlets.
One option (which I've implemented before for the same reasons) is to serve the files indirectly, ie creating a servlet just for those files, so you end up with URLs like www.example.com/myapp/FileServlet?file=script.js
Just be sure you dont introduce a 'local file inclusion' vulnerability, otherwise you'll be vulnerable to attacks like www.example.com/myapp/FileServlet?file=../../../../etc/passwd
Cheers,
Simon
kingt...@gmail.com
Apr 17, 2013, 8:20:36 AM4/17/13
to zaprox...@googlegroups.com
Two things to note:
1) In many web applications it is a big deal if content other than HTML is cached (i.e.: consider financial or medical reports delivered by image or PDF, etc). [I often catch apps that don't prevent caching of sensitive PDFs, etc]
2) Browser to browser (even version to version) handling of cache control directives is inconsistent (headers, meta, pragma). It seems a very generalized rule of thumb is that no-cache covers IE while no-store covers Firefox. Various articles, blog posts, etc that try to cover this say using both no-cache and no-store is best.
i.e.: http://palizine.plynt.com/issues/2008Jul/cache-control-attributes/
[As the RFCs go no-cache is supposed to make the Browser re-validate with the server before serving from cache. While no-store is supposed to mean don't store under any circumstances.]
Things to keep in mind:
* about:cache in Firefox (ensure you don't have any plugins like Tamper Data over-riding the setting and ensure you clear your cache first)
1) In many web applications it is a big deal if content other than HTML is cached (i.e.: consider financial or medical reports delivered by image or PDF, etc). [I often catch apps that don't prevent caching of sensitive PDFs, etc]
2) Browser to browser (even version to version) handling of cache control directives is inconsistent (headers, meta, pragma). It seems a very generalized rule of thumb is that no-cache covers IE while no-store covers Firefox. Various articles, blog posts, etc that try to cover this say using both no-cache and no-store is best.
i.e.: http://palizine.plynt.com/issues/2008Jul/cache-control-attributes/
[As the RFCs go no-cache is supposed to make the Browser re-validate with the server before serving from cache. While no-store is supposed to mean don't store under any circumstances.]
Things to keep in mind:
* about:cache in Firefox (ensure you don't have any plugins like Tamper Data over-riding the setting and ensure you clear your cache first)
kingt...@gmail.com
Apr 17, 2013, 8:38:57 AM4/17/13
to zaprox...@googlegroups.com
Note also that most modern web servers have methods by which cache control headers can be added to all responses or responses served from particular directories etc:
Apache:
http://httpd.apache.org/docs/current/mod/mod_headers.html
IIS:
http://support.microsoft.com/kb/247404
Apache:
http://httpd.apache.org/docs/current/mod/mod_headers.html
IIS:
http://support.microsoft.com/kb/247404
Reply all
Reply to author
Forward
0 new messages