8.2.1 - mention or require cache-control no-store about asvs HOT 22 CLOSED

I'd recommend clarifying no-cache and no-store into separate [split] requirements.

from asvs.

... and like usual - 0 arguments. What is the reason to have requirement for no-cache in ASVS?

from asvs.

... and like usual - 0 arguments. What is the reason to have requirement for no-cache in ASVS?

no-cache is configured by ASP.NET Core Data Protection to prevent CSRF for example.

from asvs.

... and can you explain me, how no-cache value in Cache-Control HTTP response header prevents CSRF attack?

from asvs.

... and can you explain me, how no-cache value in Cache-Control HTTP response header prevents CSRF attack?

The Synchronizer Token within the Response shouldn't be cached.

from asvs.

Your comments are technically incompetent.

Do you actually understand that no-cache does not disallow caching which is quoted in the issue and which is the main point of the issue?

from asvs.

Your comments are technically incompetent.

Do you actually understand that no-cache does not disallow caching which is quoted in the issue and which is the main point of the issue?

Can @elarlang withdraw this comment based on the extract of https://learn.microsoft.com/en-us/aspnet/core/performance/caching/middleware please?

from asvs.

No. My comment is valid.

Additionally you should understand the difference between cache for middleware (which you are referring) and the cache configuration for browser (which is the issue here).

from asvs.

no-cache prevents CSRF by forcing the web browser to revalidate the Synchronizer Token with the web server before sending the POST request.

Please let me know if you still disagree @elarlang?

from asvs.

no-cache prevents CSRF by forcing the web browser to revalidate the Synchronizer Token with the web server before sending the POST request.

And you don't dare here to explain, how and why this no-cache actually works in this process? I assume (which is in general bad thing to do) that there is extra HTTP request to achieve fresh tokens before data-changing request (in your example HTTP request with POST method). But it's not possible to read it out from your line - how browser is revalidating it.

Setting no-cache is not defence against CSRF. If you cache tokens, you may cause new vector to do it or just break functionality (because client sends invalid tokens), but it's not defense against CSRF. You are just copy-pasting lines from ASP NET manual without understanding the context (middleware vs browser cache).

from asvs.

Relevant quotes from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-cache which should hopefully change your opinion @elarlang

• the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.
• If you want caches to always check for content updates while reusing stored content, no-cache is the directive to use. It does this by requiring caches to revalidate each request with the origin server.
• no-cache allows caches to store a response but requires them to revalidate it before reuse.

from asvs.

Change my opinion on what?

The topic here is - client-side cache and sensitive data. Which means you are not allowed to store any cache on the client side (edit: anywhere) and if you don't have any cache on the client side, validating it is not the case.

Just stop digging your hole deeper.

from asvs.

I'll double check that CSRF controls include Cache-Control: no-cache elsewhere in ASVS.

8.2.1 does not mandate Cache-Control: no-cache but "anti-caching headers" should be reworded to infer setting Cache-Control: no-store with a suitable an antonym.

from asvs.

As far as I can tell, the CSRF point here is very niche and probably not worth having its own requirement.

@elarlang, I found this blog on caching which would seem to indicate that a more complex config is needed to fully eliminate caching.

from asvs.

The blog gives nice overview, but also kind of agrees with my question. To avoid caching sensitive data on the client-side (browser) the best option is to use no-store - it still writes it to memory.

The main point of the issue - from pen-testing I see often, that there is only no-cache set for Cache-Control, but the value is misleading and it's not correct / enough.

The rest is mostly configuring cache-server and this is the requirement 8.1.1

from asvs.

it still writes it to memory.

We should limit this ASVS Requirement to Cache-Control: no-store as recovering the sensitive data from memory is outside the threat model of ASVS.

from asvs.

So what do you think about:

[MODIFIED] Verify the application sets sufficient anti-caching headers (including but not limited to Cache-Control: no-store) so that sensitive data is not cached in modern browsers.

@elarlang

from asvs.

I've removed "including but not limited to" as this is open to interpretation, where the developer will select the less secure control, and Cache-Control: no-store explicit @tghosth

[MODIFIED] Verify the application sets sufficient anti-caching headers (including but not limited to i.e. Cache-Control: no-store) so that sensitive data is not cached in modern browsers.

Should we define another requirement for Cache-Control: no-cache for CSRF, which was discussed within #795 without the explicit Cache-Control: no-cache callout?

from asvs.

I also think that the part including but not limited to is not needed in the requirement.

But this no-cache vs csrf topic is non-stop facepalm here. Just stop it.

from asvs.

So @elarlang you also prefer:

[MODIFIED] Verify the application sets sufficient anti-caching headers (i.e. Cache-Control: no-store) so that sensitive data is not cached in modern browsers.

from asvs.

I'd removed the reference to the word "cache" in its entirety with as little reference to the cache control header @tghosth

[MODIFIED] Verify the application sets sufficient cache control headers (i.e. Cache-Control: no-store) so that sensitive data is not cached retained in by modern browsers.

from asvs.

It will be in memory or DOM anyway, can not take away that.

from asvs.