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 no 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 be wrong. Many folks use “web UI content injection”, “content injection” or similar as a more accurate term.

[jmanico]

Addressing proposals from @elarlang :

1. Terminology - we call it abstractly "request forgery"

Cross Site Request Forgery, Session Riding CSRF and XSRF are the common terms and acronyms. If we stray beyond these, can we please cite them along side the new term? Maybe session riding is more accurate than cross site request forgery or request forgery? But overall I do not think this is a big problem. Most of the industry recognizes these legacy terms. The generic term "request forgery" is too generic IMO, it can incorrectly refer to SSRF or Clickjacking.

2. 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.

I like the direction of this. But I think it's more than state changing functionality. I think it's any functionality that would cause damage if the request was forged, regardless of the verb or state changing effect.

3. Special highlight for "downgrading" CORS-preflight request to CORS-safelisted request - need to check Origin and Content-Type request headers.

I think this is a really good idea to add in. Thumbs up on this one.

[elarlang]

Previously I proposed to use client-side request forgery to be "paired" with SSRF, but one of them is making the request and another is accepting the request:

• SSRF - The defense against SSRF is to not allow the application server-side component to make the request to the location based on untrusted input
• CSRF - The defense against CSRF is to not allow the application server-side component to accept a request from an untrusted party

The "Client" is also vague, and in the situation of SSRF to happen, the vulnerable application itself is a client to make the request. So maybe browser-based request forgery is a more correct or self-explaining term to use.

Proposal

Proposal is provided with different parts to have more precise feedback.

• the term "sensitive functionality" - there should be something better, as it may get mixed or confusion with data classification.
• part 2 - what else must be listed to "to be protected against "csrf" list?

---

Part 1 - the definition:

Verify that the application validates the request to call out state-changing or sensitive functionality originating from the functionality provided by the application itself or by a trusted party, to defend against browser-based request forgery attacks (previously known as cross-site request forgery (CSRF)).

---

Part 2 - the clarification the functionality to defend

Sensitive functionality includes accepting form posts for authenticated and non-authenticated users (such as authentication), calling out resource-demanding functionality (such as data export), and (todo: what else to list here?)

---

Part 3 - safe HTTP methods for data changes (merge 13.6.2)

Sensitive functionality must not be executed using safe HTTP methods such as HEAD, OPTIONS, or GET (e.g. using navigation request).

---

Part 4 - CORS spotlight (merge 13.2.5)

For requests that expect to trigger a CORS-preflight request, request header fields such as 'Origin' and 'Content-Type' must be validated to ensure that it is not possible to call the functionality with CORS-safelisted request.

---

Part 5 - terminology note

Too long to add into the requirement, probably part of the chapter text:

Note that the attack vector is known as cross-site request forgery (CSRF), but the definition of site (effective Top Level Domain + 1) makes the term CSRF outdated and incorrect. The scope limitation to cross-site is not valid, as the attack may come from 'same-site but cross-origin' or from 'same-site and same-origin' scope.

[elarlang]

We also have a requirement for safe-methods:

V13.6.2 [MODIFIED, MOVED FROM 13.2.1] Verify that HTTP requests using the HEAD, OPTIONS, TRACE or GET verb do not modify any backend data structure or perform any state-changing actions. These requests are safe methods and should therefore not have any side effects.

The main goal is the same, it is a kind of pre-condition to have a defense against browser-based request forgery attacks and it does not have its own separate risk.

The choice here is, to merge everything into one monster requirement, or to have some more specific separate requirements to address separate related and underlying problems, such as using safe methods for state changes or CORS-preflight downgrade to CORS-safelisted.

[tghosth]

So what is the rough wording suggestion please here @elarlang?

[elarlang]

So what is the rough wording suggestion please here @elarlang?

Rough wording is concat(part1, part2, part3, part4, part-x) - written as separate parts to have more precise feedback and finetuning for different parts.

Updated proposal in #2481 (comment)

[tghosth]

Regarding,

the term "sensitive functionality" - there should be something better, as it may get mixed or confusion with data classification.

Maybe we need to focus on state changing or resource intensive functionality. Not sure I know what sensitive functionality means in this that isn't included by one of those other definitions.

part 2 - what else must be listed to "to be protected against "csrf" list?

Not convinced there is anything else.

I would propose the following text:

"Verify that requests to state-changing or resource intensive functionality are checked to ensure they originate from the application itself, to defend against browser-based request forgery attacks (commonly known as cross-site request forgery (CSRF)). Additionally, this functionality must not be invoked using safe HTTP methods such as HEAD, OPTIONS, or GET. This precaution will ensure that cross-origin requests to this functionality will trigger a preflight request."

Comments on the proposal:

• In this use case, the "trusted party" is considered part of the application.
• Part 2 - the clarification the functionality to defend - I think this part is now redundant with the updated wording.
• (e.g. from a navigation request) - I think this is redundant or should be moved to the section text.
• Part 4 - CORS spotlight (merge 13.2.5) - Based on what it says at this link, we are enforcing preflights through our HTTP verb requirement.
• Part 5 - terminology note - I have included a proposal below to rework the section text.
  Section text:

V50.4 Browser Origin Separation

When accepting a request on the server side, we need to be sure it is initiated by the application itself and not in some way spoofed by a malicious party. Key security mechanisms here include browser security policies like Same Origin Policy for JavaScript and also SameSite logic for cookies.

The most common and well known attack vector is known as cross-site request forgery (CSRF), but note that the definition of site (effective Top Level Domain + 1) makes the term CSRF outdated and incorrect. The scope limitation to cross-site is not valid, as the attack may come from 'same-site but cross-origin' or from 'same-site and same-origin' scope.

[elarlang]

In this use case, the "trusted party" is considered part of the application.

As we included CORS, it may be some other trusted party that uses the API

Part 2 - the clarification the functionality to defend - I think this part is now redundant with the updated wording.

The proposal lost spotlight for the non-authenticated actions, such as authentication.

Part 4 - CORS spotlight (merge 13.2.5) - Based on what it says at this link, we are enforcing preflights through our HTTP verb requirement.

If you don't validate the previously/my proposed part 4, you can bypass this new/your proposed part 4.