Re: CORS and 304

On Dec 4, 2013 4:15 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>
> On Wed, Dec 4, 2013 at 11:38 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > So you mean that if a CGI does a 304 redirect and sends some response
> > headers and a response body, then apache will filter out the headers but
> > send the 304 and the body? Is this specific to 304s?
>
> 304 is not strictly a redirect. 304 is "Not Modified". An indication
> from the server that you can use the cached copy.

Doh! I forgot that's what it means.

However I would say that we then definitely need to require CORS headers
unfortunately.

Otherwise it means that you can just read 304 responses from any website
without any security checks at all. And I think making the claim that a 304
response couldn't possibly contain sensitive data is too bold of a claim.

For example it would let me see when you last got money deposited into your
bank account by polling the "show account summary" URL with different
if-modified-since dates. Any time I get back a 304 it means that the date
used was more recent than when you received money.

Yes, the apache behavior is a problem, but I don't see that we can simply
skip doing any and all security checks.

However, in most cases when 304 responses are involved the website doesn't
actually see the 304 response. Most of the time the website makes a request
for a resource. If the UA has that resource cached, it will then make a
if-modified-since request. If a 304 is returned, without cors headers, then
the UA will return the originally cached response. If this cached response
does have the appropriate cors headers then permission should be granted.

/ Jonas