Clarify CSRF requirement 50.4.1

[tghosth]

Current text:

#	Description	L1	L2	L3	CWE
50.4.1	[MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality, using the development framework's built-in anti-CSRF functionality or CSRF tokens, along with additional defense-in-depth measures.	✓	✓	✓	352

We also have:

#	Description	L1	L2	L3	CWE
50.4.3	[ADDED, SPLIT FROM 14.5.3] Verify that the Origin header field is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy.	✓	✓	✓	346

Points to change:

• Merge origin validation from 50.4.3 into 50.4.1, as discussed here: having a new sub-section for CORS(e.g. V14.6) and add one more item. #876 (comment)
• Mention triggering a CORS preflight

Potential wording:

[MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality. This should use the development framework's built-in anti-CSRF functionality or CSRF tokens, along with additional defense-in-depth measures such as validating the origin header. Where cross-origin requests are used, this should always trigger a CORS preflight request first.

[jmanico]

[MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality. This should use the development framework's built-in anti-CSRF functionality or CSRF tokens, along with additional defense-in-depth measures such as validating the origin header. Where cross-origin requests are used, this should always trigger a CORS preflight request first.

Notes:

• Simple cross-origin javscript based requests (XHR, fetch) do not trigger pre-flight.
• Cross origin requests from non-JavaScript sources (like HTML forms) do not trigger pre-flight or SOP.

[randomstuff]

Yes, "Where cross-origin requests are used, this should always trigger a CORS preflight request first." does not feel right as a consequence.

[tghosth]

So I would clarify to:

"[MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality. This should use the development framework's built-in anti-CSRF functionality or CSRF tokens, along with additional defense-in-depth measures such as validating the origin header. Where cross-origin requests are used for this functionality, this should always trigger a CORS preflight request first."

Can we think of a situation where a cross-origin request for "authenticated or sensitive public functionality" should not trigger a pre-flight?

[elarlang]

I don't like the requirement nor the proposal. It takes some time to list all the issues. That's why it is assigned to me with status "awaiting proposal".

[elarlang]

So, some ideas to take into account.

Problems:

• The terminology (CSRF) is outdated
  • I think at the time Cross-Site Request Forgery was invented, the term Site was not defined
    • The Site is effective top level domain + 1 (need to take into account the public suffix)
  • Nowadays the term Cross-Site is most of the time used incorrectly
    • Mostly the request forgery happens from the Same-Site scope due to he cookie SameSite attribute setup, but it is called Cross-Site Request Forgery
    • If the request forgery happens due to CORS misconfiguration, the actual problem is Cross-Origin Request Forgery, because the boundary for CORS is Origin (not Site)
• Safe HTTP methods vs state changes - request forgery, or also "use HTTP safe methods" are often limited to "state changing" functionality, but also in the scope should be
  • Resource-demanding functionality, such as data export, serving a large file
  • Authentication form
  • Filling any form, such as commenting anything (hate speech into public site can cause some issues)
• Addressed functionality: we need to take into account
  • authenticated and not authenticated functionality
  • state handling with cookies
  • state handling with Authorization header (adding it with JavaScript)
  • state handling with Authorization header (adding by the browser automatically - basic auth, NTLM, etc)

Proposals (to take into account):

• Terminology - we call it abstractly "request forgery"
  • or if to work hand-in-hand with Server-Side Request Forgery then it can also be called Client-Side Request Forgery (ironically, the acronym is CSRF)
• Define the goal to achieve: for executing state-changing or resource demanding functionality (we may ask documentation requirement for that), application must be sure the request was initiated by the application itself or by a trusted party.
• Special highlight for "downgrading" CORS-preflight request to CORS-safelisted request - need to check Origin and Content-Type request headers.

v4.0.3 Requirements to cover:

• 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.
• 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: double submit cookie pattern, CSRF nonces, or Origin request header checks.
• V13.2.5 Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.

Additionally, v5.0.0 requirements to cover:

• V50.4.1 [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality, using the development framework's built-in anti-CSRF functionality or CSRF tokens, along with additional defense-in-depth measures.
• V50.4.3 [ADDED, SPLIT FROM 14.5.3] Verify that the Origin header field is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy.
• V13.2.5 Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.

[randomstuff]

The terminology (CSRF) is outdated

I agree. I don't like this term very much (and I don't like "XSS" much either for the same kind of reasons). However, this is the accepted wording. It is difficult to depart from it and mint your own wording when the whole community is using this "CSRF".

FWIW, I think a better wording would be "cross origin request forgery" but it is not used at all anywhere.

then it can also be called Client-Side Request Forgery

I kind-of like that 😄.

I'm wondering if this is clear enough though. There might be other kind of client-side request forgery (for example, client-side cross-protocol confusion attacks, ALPACA).

[elarlang]

Offtopic:

and I don't like "XSS" much either for the same kind of reasons

Probably you can find also from here (ASVS repo) in issues discussions how much I don't like the XSS. The XSS even worse than CSRF. CSRF is "half ok", because the "request forgery" part still explains what it is. But XSS is also used in "Same-Origin HTML injection" situation, which means not a single word from cross-site scripting is actually true, and this is insane nonsense.

---

Ontopic:

However, this is the accepted wording. It is difficult to depart from it and mint your own wording when the whole community is using this "CSRF".

I think "this is the used term", not that much maybe "the accepted term" anymore. At the end, the term Cross-Site Request Forgery is incorrect and there is reason to use it. The same with XSS - we have it mentioned only in one requirement in the context of impact. The "Cross-Site" is used also in "XSSI" name.

FWIW, I think a better wording would be "cross origin request forgery" but it is not used at all anywhere.

I would not limit it to cross-origin either. It can be also same-origin - for example, an attacker can use only HTML injection (classical outcome from sanitized HTML, you can still use <img src="/local/path">), but with that can trigger all functionality (if cookies are used for state handling) using GET method - for example calling resource demanding export, call logout etc.

[tghosth]

@elarlang I see your point but can you make a concrete wording suggestion please.

[jmanico]

Agreed XSS is not a good term. All three of the words can me wrong. Many folks use “web UI content injection”, “content injection” or similar as a more accurate term.