V4.2.2 CSRF and/vs anti-automation #795
Comments
|
Good catch, CSRF protection and anti-automation defenses are for
different use cases. Here are additional thoughts.....
CSRF protection on a public non authenticated resource is sometimes
still important.
1) I could CSRF you to force google to be a different default language
or fill a shopping cart for you with an item you did not choose, or
similar. The impact is often small for public CSRF endpoints, but the
need is there.
2) Public features, like airplane reservations that do not require
login, need anti-automation defense so bots cant lock down tickets on a
plane and hold seats, but this is an entirely separate requirement that
I do think is important
- Jim
…On 5/29/20 8:13 PM, Elar Lang wrote:
V4.2.2
<https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V4-Access-Control.md#v42-operation-level-access-control>
Current:
V4.2.2 Verify that the application or framework enforces a strong
anti-CSRF mechanism to protect authenticated functionality, and
effective anti-automation or anti-CSRF protects unauthenticated
functionality.
* Anti-automation and CSRF are different problems and require
different solutions for defense / Anti-automation is not what
anti-CSRF protection (requirement) should address.
* Anti-automation is covered with requirements in "V11.1 Business
Logic Security Requirements"
No clear proposals yet, I would like to know first, why this
anti-automation part is in this requirement?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#795>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEBYCOZ6PSL3LD7IRTAKMLRUBFT5ANCNFSM4NOOCCYQ>.
|
|
For non-auth, CSRF defense is important. Another example - there is some defense "too many requests from one IP and traffic from IP will be blocked", for instance: authentication attempts. So it's important to have CSRF defense on login in also, that I can not force someone else's browser to make wrong attempts and to get blocked. Anti-automation - I think we should have separate subcategory for Anti-automation under business logic. But as it is not urgent yet, I haven't made any issue for this yet. I'll do it after ASVS v4.0.2 is out. I think you current example (2) is also covered by V11 category, like:
But how to improve current V4.2.2? Very robust and simple could be:
Questions:
|
|
No for framework, yes for non-auth :)
…--
Jim Manico
@manicode
Secure Coding Education
+1 (808) 652-3805
On May 31, 2020, at 2:25 PM, Elar Lang ***@***.***> wrote:
For non-auth, CSRF defense is important.
Another example - there is some defense "too many requests from one IP and traffic from IP will be blocked", for instance: authentication attempts. So it's important to have CSRF defense on login in also, that I can not force someone else's browser to make wrong attempts and to get blocked.
Anti-automation - I think we should have separate subcategory for Anti-automation under business logic. But as it is not urgent yet, I haven't made any issue for this yet. I'll do it after ASVS v4.0.2 is out. I think you current example (2) is also covered by V11 category, like:
V11.1.2 Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.
But how to improve current V4.2.2? Very robust and simple could be:
V4.2.2 Verify that the application or framework enforces a strong defense against Cross-Site Request Forgery (CSRF) attacks.
Questions:
do we need "or framework" part?
do we need to point out separately, that yes, for non-auth users it's also makes sense to provide defense against CSRF?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Proposal:
Language check/correction needed. |
|
Well not all public web pages need csrf protection; just sensitive features, not basic public page access.....
…--
Jim Manico
@manicode
On May 31, 2020, at 4:05 PM, Elar Lang ***@***.***> wrote:
Proposal:
V4.2.2 Verify that the application enforces a strong defense against Cross-Site Request Forgery (CSRF) attacks for both, authenticated and not authenticated users.
Language check/correction needed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
... and how to put it to the requirement? If you say "sensitive feature" we should also define "what is sensitive feature", otherwise it's endless discussion "is this feature sensitive enough". Defense against CSRF is required when not safe HTTP method is used:
And here, precondition is - HTTP methods are used like they are meant to be - no data changes with safe HTTP methods. |
|
Safe HTTP methods are a "should" not a "must" in the HTTP Spec, so you
have no guarantee that is what is happening in any web app.
In fact, some GET requests for lookup alone are super sensitive and
merit CSRF like we see in Magento and other eCommerce engines.
Verbs alone are not enough to merit when and when not to do CSRF
defense. So we need a more mature requirement then to say always do it.
- Jim
On 6/1/20 8:31 AM, Elar Lang wrote:
... and how to put it to the requirement?
If you say "sensitive feature" we should also define "what is
sensitive feature", otherwise it's endless discussion "is this feature
sensitive enough".
Defense against CSRF is required when *not* safe HTTP method is used:
* https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods
* https://developer.mozilla.org/en-US/docs/Glossary/safe
And here, precondition is - HTTP methods are used like they are meant
to be - no data changes with safe HTTP methods.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#795 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEBYCJXHURQK2POJ4XOECLRUONSXANCNFSM4NOOCCYQ>.
--
Jim Manico
Manicode Security
https://www.manicode.com
|
|
@jmanico, I leave this proposal fine-tuning to you :) Also, I'lle take here requirement from "V13.2 RESTful Web Service Verification Requirements" subcategory, as there are also no mention of sensitive action / transaction or something like that. Maybe this one needs some improvement as well.
|
|
To your point this is a hard one to wordsmith but I'll be glad to take
(them both) on.
Aloha, Jim
…On 6/1/20 12:38 PM, Elar Lang wrote:
@jmanico <https://github.com/jmanico>, I leave this proposal
fine-tuning to you :)
Also, I'lle take here requirement from "V13.2 RESTful Web Service
Verification Requirements" subcategory, as there are also no mention
of sensitive action / transaction or something like that. Maybe this
one needs some improvement as well.
V13.2.3 Verify that RESTful web services that utilize cookies are
protected from Cross-Site Request Forgery via the use of at least
one or more of the following: triple or double submit cookie
pattern (see references
<https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>),
CSRF nonces, or Origin request header checks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#795 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEBYCLZWGCG5AC5UICFFDDRUPKPXANCNFSM4NOOCCYQ>.
|
|
@tghosth , why milestone v4.1? |
Sounds like a non-cosmetic change to a requirement so too extensive for a 4.0.2 |
|
Will do
When do you want to push 4.0.2 by the way? When should I have mine done by?
- Jim
…On 6/18/20 3:52 PM, Josh Grossman wrote:
Hi @jmanico <https://github.com/jmanico> whilst you are working on
this can you try and resolve the potential duplication betwee v4.4.2
<https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V4-Access-Control.md#v42-operation-level-access-control>
and v13.2.4
<https://github.com/OWASP/ASVS/blob/master/4.0/en/0x21-V13-API.md#v132-restful-web-service-verification-requirements>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#795 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEBYCNUBN3R5WXLTAJB2FDRXJWAZANCNFSM4NOOCCYQ>.
|
|
Takeaway from #876 - CSRF defense is not clear authorization problem from an application point of view, it's defense "is user's browser authorized to do the request". This requirement (merged with V13.2.4) should belong to the same category like CORS/ACAO. Maybe need for clear new category to send clear message, which requirements exists for taking away or lowering impact for attack vectors via victim browser. |
|
This is very hard to wordsmith but I am trying to address it now. |
|
I propose: V4.2.2 Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated or sensitive public functionality. I realize "sensitive public functionality" is not perfect but I am open to suggestion to fix this. I think "sensitive functionality" is too hard to define at this level. |
|
I agree CSRF does not belong in the access control section. |
|
Ok I suggest we delete 4.2.2 and 13.2.3 and add a new requirement in the CORS section as advised which states: Verify that the application or framework enforces an anti-CSRF mechanism to protect authenticated or sensitive public functionality using at least one or more of the following: double submit cookie pattern, CSRF nonces or SameSite cookies. |
|
Last proposal (merged 4.2.2 and 13.2.3):
Current 13.2.3:
For category change I'll open separate issue in future. |
|
I like the change you propose. Looks good! |
This is not really needed, the other defense are more robust and not all browsers send the Origin header with each request.
I agree! |
|
Current:
Proposal 1 - current 4.2.2:
Proposal 2 - current 13.2.3:
|
"enforces defense" kan perhaps be shortened to "defends". Some people think that SameSite cookies are not sufficient against CSRF, and that a server-side solution is always needed. I disagree, but that may be something to consider.
The term "nonce" suggests that every CSRF token is used once, but I think CSRF tokens that remain the same throughout the session are also acceptable.
I have a hard time thinking of a CSRF attack on a public endpoint. Do you have an example in mind? |
Please read 2nd and 3rd comment in this thread. Agree with shortening to "defends". nonce vs token - in practice, it probably does not matter - if an attacker can read out victim's token, it's probably possible to use nonce from that situation as well. |
This science is clear there. If you only support browsers that have SameSite support (and you enforce this policy in code and reject old browsers) then same site cookies are sufficient. Be wary of wonky IE11 support and bugs in recent versions of Safari. Frankly, I would not depend on SameSite alone... yet. |
Josh you are right. SameSite cookies really are not enough. Avi Douglen, Neil Madden and Daniel Fett "schooled" me over twitter and they are right. So SameSite is sufficient for CSRF defense but only if (1) cookies are the session transport mechanism and (2) older browsers are not supported. We still need other defense methods for non-cookie based session management like network only AuthN, HTTP Digest/Basic and other edge case issues. |
|
Have not analyzed it enough but the idea is - maybe we should just drop all technical recommendations as those depends on technologies used in application:
There are so many different ways to achieve that. If we remove SameSite from this requirement, but in reality application uses cookie-based session token with samesite=strict, then in practice the defense is there. |
|
Yes, and it's already there: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V4-Access-Control.md |
|
Ok so can you modify the wording of the requirement so it says that instead of allowing samesite as a standalone option |
|
I totally back saying that SameSite is not enough.
|
|
Not sure now what is the expectation? I think requirement text should not say "follow cheat sheet", it can be written somewhere in "category description". Requirement text itself should be clean, so my proposal is to clean up all technical advises/requirements:
|
|
I would like to avoid any requirement pointing the a cheatsheet - they requirements should be self contained. I am a bit lost. What more needs to happen? I want to make sure:
And I am a bit lost in this thread! :) |
|
Proposal without "technical advices", go or no go?
|
|
I think we need to give advice here. |
|
I created a PR based on how I understand the cheatsheet's summary https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#introduction |
|
I can not see benefits over just dropping all this recommendation part - it does not advice anything. It recommends to use framework CSRF defense, but what if this one is weak? Then by this requirement application is ok (as it uses framework solution like required), but actually it's not. Most-likely framework built-in defense is used anyway. Same with "additional defense in depth measures" - it does not give any information. For me it feels better without those filler-extras. If we actually want to give advises, I think we can not handle it with one requirement and we need context-specific requirements. Personally I don't like this direction, because it's maybe not realistic to cover all tech combinations. It's possible to achieve defense against CSRF attacks so many different ways - if it's done in whatever way, it's done. It's up to pen-tester to verify that or to prove it not strong enough. |
|
Yes. to be clear: I'm not against giving technical advises but I think there are way too many different ways to achieve that to be able to cover them with one requirement. |
|
I object, it’s does not give advice how. Can we please mention synchronizer token, double-cookie submit ...”or other” defenses at least?
|
This part is covered with requirement in cookie section and it's not relevant for application which does not use cookies. |
|
From this issue perspective - my goal was to separate anti-csrf and anti-automation requirements and merge 2 different anti-csrf requirements to one requirement, I think those are achieved. |
|
@elarlang, is CSRF relevant for applications which do not use cookies...? :) |
|
non-auth functionality, basic authentication (picked from #795 (comment)) |
|
There are several scenarios where non cookie CSRF is possible. The use of HTTP digest, network based AuthN and similar automatic mechanisms.
|
|
Ah yes, sorry I missed that bit. #795 no longer mentions cookies thing so I think we are good to merge and close this thread, thanks all :) |
V4.2.2
Current:
No clear proposals yet, I would like to know first, why this anti-automation part is in this requirement?
The text was updated successfully, but these errors were encountered: