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.

[tghosth]

I think the following requirement covers parts 1, 2 and 4 above:

"Verify that requests to state-changing, security sensitive, or resource intensive functionality includes a mechanism to prevent browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). Ideally the functionality should only accept content-types which would trigger a CORS preflight and enforce an allow list of 'Origin' headers. Alternatively, another CSRF prevention mechanism may be used."

It covers the "write" case here where the "read" case is covered by 50.3.6.

I think the following requirement covers part s 1, 2 and 4 3 above:

"Verify that requests to state-changing, security sensitive, or resource intensive functionality use appropriate HTTP methods including POST, PATCH, DELETE or PUT."

Part 5 will be covered in chapter text but we have a note that we wanted to mention authentication as a specific "write" case there.

[elarlang]

TLDR:

• If you use CORS(-preflight), accept only CORS(-preflight)
• Do not execute state-changing or resource-demanding functionality for navigation or (incorrect) resource loading (e.g. request made as calling an image load) request (using HTTP safe-method)
• CORS-safelisted requests with POST method - check tokens and/or extra headers

---

Disclaimer - in total I have spent (too) many hours to put this together. I expect any comments to be technically validated before proposing anything else, just so that I do not have further time to explain how HTTP or CORS works. It also means, that every detail I proposed, is there for a reason, and if an alternative proposal is going to lose some detail, it must be validated and explained reason to do so.

---

Separate requirements

I'm going to propose (to keep) separate requirements instead of merging everything to one monster-anti-csrf-requirement, just because the impact is a "CSRF".

If the CORS-preflight can be downgraded to CORS-safelisted request, the impact is a "CSRF" but it is a separate problem to solve compared to "missing tokens" or "making changes with navigation request".

In the same way, we have a separate requirement for each technical situation on how to reach HTML or JavaScript execution (so-called XSS). If we could use one requirement "verify that user-controlled input is not executed as HTML or JavaScript" we could lose too many details and it could not provide anything practical anymore. For example, we can not put together problems related to dynamic document building (HTML or JavaScript injection), using an incorrect method to display the data (HTML or JavaScript execution), using an incorrect Content-Type when serving the data (API response as text/html instead of application/json), or serving user-uploaded .svg or .html file from the same-origin scope. Those all reach "malicious content execution", but test-cases and expected defenses are different.

Using separate requirements also aligns with agreed principles such as "One problem per requirement", "different test-cases into different requirements", and "a separate requirement to highlight really widespread problems".

Listed requirements are not duplicates, they just have a common impact. From the impact point of view, those (theoretically) can be merged into one monster requirement but with the cost of actionable details.

---

Part 2, 5 - Terminology, Functionality, scope, technical limitation

Limitation for request forgery requirements - it affects only if there

• is no state kept for the browser
• OR if the browser includes state-keeping information automatically with the request (such as session cookie, HTTP basic auth, or NTLM authentication HTTP headers). It affects authenticated and non-authenticated users.

Previously proposed:

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?)

It should be covered in the chapter text.

The chapter text must include also "Part 5" - the explanation, of why "CSRF" is not a technically correct term to use.

---

Part 4

I start from Part 4, to get the scope reduced for the others.

The scope and the point to cover - if using API and/or CORS - accept only API and/or CORS calls.

Applies only to APIs that are used via browser using JavaScript (XHR or fetch)

Previously (#2481 (comment)) proposed as part 4:

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.

Test-Cases:

• If the application does not use cross-origin requests, it must not accept them (covered by validating the Origin request header field)
• Is Access-Control-Allow-Origin (ACAO) response header field reflecting the Origin request header field value
  • CORS pre-flight is also used as a defense to validate if the browser is allowed to make the request to the API
  • In case a quote is needed, from MDN: CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request.
• Is it possible to "downgrade" the CORS pre-flight request to a CORS-safelisted request
  • Is the Origin request header field validated?
  • Is the Content-Type request header field validated - if safelisted Content-Type is used, it requires using an extra defense method (e.g. an extra header field)?
  • Is there any not CORS-safelisted request header in use?

Expected defense:

• Use correct request headers field validation and correct response header field values (configuration) to have pre-flight-based defense in place

In other words: in case it is possible to skip pre-flight request and downgrade it to CORS-safelisted request, the expected defense is not to ask "CSRF tokens", but to fix the set of headers.

It means it should be a separate requirement - it is a separate technical problem, it expects a different defense than "ask tokens".

It should cover current v5.0 requirements:

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

The meaning for the requirement:

Verify that if the application uses and relies on CORS-preflight mechanism, it is not possible to call the functionality with a CORS-safelisted request. It may require validating the 'Origin' and 'Content-Type' request headers or using an extra header field in the communication that is not a CORS-safelisted request header field.

---

Part 3 - Accept only safe methods - current 13.6.2 (#2492).

When simplified, it needs to achieve that:

• The application is built a way that state-changing functionality is used via safe methods, for example, deleting something is not done via the GET method request
• The application does not accept calling the functionality with other methods or other parameters - a widespread problem for old-school applications as they may merge URL parameters and request body parameters without distinguishing them and checking the anti request forgery token only when functionality is called via the POST method. So it gives a "CSRF"-check bypass sending the same parameters via URL and using the GET method

Test-cases (simplified):

• Verify that by default all the "state changing" functionality is not called with safe HTTP methods
• Verify that calling a "state changing" functionality can not be called with a safe HTTP method

Expected defense (simplified):

• For state-changing requests, use and accept only unsafe HTTP methods

Previous proposal (simplified):

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

When not simplified, we need to take into account:

• CORS - if some HTTP request header fields are added by JavaScript (it is not automatically included by the browser)
• Tokens, that can be used as part of the URL

That means, although state-changing or sensitive functionality is called using an HTTP safe method, it is not vulnerable to "CSRF" just because of that.

Instead of "use HTTP safe methods" we need to ask "the functionality must not be triggered with navigation request or resource loading request, e.g. loading an image". Navigation request here is the most critical because cookies with SameSite=Lax are sent with the request. For example, if calling the resource from a cross-site application as an image, cookies with SameSite=Lax are not sent.

It should cover current v5.0 requirements:

• 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 proposal has "negative wording", but let's start with that.

Verify that state-changing or resource-demanding functionality is not executed for a navigation request or is called an incorrect destination (e.g. export data functionality is called as an image from the browser). Not accepting safe HTTP methods such as HEAD, OPTIONS, or GET and Sec-Fetch-* request headers can be used for validation. It requires special attention if the application does not distinguish URL parameters and message body parameters.

This requirement is a pre-condition to have any defense against browser-based request forgery.

The expected defense is not to check and validate tokens, the expected defense is to have a correct architecture in place.

---

Part 1

Previous proposal (with updated wording by Josh):

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

It should cover current v5.0 requirements:

V50.4.1 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.

A pre-condition:

• CORS-preflight can not be downgraded to CORS-safelisted request (Part 4)
• Navigation request can not be used to trigger functionality (Part 3)

Test-Cases:

• Does the request contain something unique that is not known for a third party (token)
• Does the request contain something that can not be added by a cross-origin party (using an extra request header triggers CORS-preflight and provides a defense even if CORS is not used)
• Does the request contain something that can not be added by a cross-site party (requires "Part3", cookies with the SameSite=Lax or SameSite=Strict)

Expected defense:

• Require and validate something (unique) from the request, that is provided by the application to the party that initiates the request

Proposal with some limitations and direction compared to the previous one:

Verify that requests to state-changing or resource intensive functionality are checked to ensure they originate from the application itself. For example, by using and validating tokens or extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).

Scope - this requirement basically handles the situation if an HTTP request using the POST method is made

• GET, OPTIONS, HEAD are ruled out by Part 3
• PUT, DELETE, PATCH are triggering CORS-preflight and are covered by Part 4

So the requirement may also start with:

Verify that CORS-safelisted requests to

---

Before any comments - please validate your comment against this post before submitting it.

. o O ( Where do I send the bill for writing this post? )

[tghosth]

#thiscommentshouldhavebeenablogpost

🙃🤣

[tghosth]

Please can you add your proposals to the tl;dr together with tags to help understand which current requirements they are modifying.

[elarlang]

In the current situation, the long post was (forced to be) written to explain and address all the situations, different test cases, and expected developments together and point out, how they don't overlap.

I recommend taking the time and analyze it. Understanding it is a pre-condition to make any decision based on the provided information. So I don't think those 3 proposed requirements should be taken out of context and then start answering the questions out of context that are actually already written in the post.

[tghosth]

Ok so as I understand it, your proposed requirements are:

Part 4:

V50.4.3 - [MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3] Verify that if the application uses and relies on CORS-preflight mechanism, it is not possible to call the functionality with a CORS-safelisted request. It may require validating the 'Origin' and 'Content-Type' request headers or using an extra header field in the communication that is not a CORS-safelisted request header field.

Part 3:

V13.6.2 - [MODIFIED, MOVED FROM 13.2.1] Verify that state-changing or resource-demanding functionality is not executed for a navigation request or is called an incorrect destination (e.g. export data functionality is called as an image from the browser). Not accepting safe HTTP methods such as HEAD, OPTIONS, or GET and Sec-Fetch-* request headers can be used for validation. It requires special attention if the application does not distinguish URL parameters and message body parameters.

Part 1:

50.4.1 - [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that requests to state-changing or resource intensive functionality are checked to ensure they originate from the application itself. For example, by using and validating tokens or extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).

Correct? If so, I can then go and analyse your argumentation whilst clearly understanding your end goal from your argumentation.

[elarlang]

Relations to current requirements that will be covered with new proposal, were listed in my post into each part. So I think the question was answered already.

How correct tags are pre-condition to analyze the concept "one monster requirement" vs "3 separate requirements" is not understandable for me. What is the correct tag also depends on the requirement. I listed at the moment current v5.0.be requirements, if we want to have correct tags, we need to analyze the content of a v4.0.3 requirement compared to new proposed requirement. At this stage, I don't see the reason to put time into it. Just for an example, 13.2.3 from v4.0.3 is basically covered by 2 separate requirements.

Overall, requirements to cover was provided in #2481 (comment) and 13.6.2 was linked later in #2481 (comment)

[tghosth]

Summary of discussion

---

These are ok:

Part 4:

"V50.4.3 - [MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3] Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a CORS-safelisted request. This may require checking the values of the 'Origin' and 'Content-Type' request headers or using an extra header field that is not CORS-safelisted."

Add a note to chapter text that this applies to apps that are designed to be accessed cross origin but also those which are not but instead preflight is used as a security mechanism.

Part 1:

"50.4.1 - [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that CORS-safelisted requests to sensitive functionality are checked to ensure that they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF)."

Add anti-forgery tokens to glossary?

---

This needs more thought:

Part 3:

V13.6.2 - [MODIFIED, MOVED FROM 13.2.1] Verify that sensitive functionality is not executed for a navigation request or is called an incorrect destination (e.g. export data functionality is called as an image from the browser). Not accepting safe HTTP methods such as HEAD, OPTIONS, or GET and Sec-Fetch-* request headers can be used for validation. It requires special attention if the application does not distinguish URL parameters and message body parameters.

[tghosth]

Looking again at Part 3:

This is the current state:

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

I previously said (here) that I thought this should be merged into a separate CSRF requirement. I am prepared to accept that it needs to stay separate and also include the subtleties of the version proposed above.

I therefore propose the following @elarlang :

"V13.6.2 - [MODIFIED, MOVED FROM 13.2.1] Verify that calls to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source). This is particularly important if the application does not distinguish between URL parameters and message body parameters."

What do you think?

[elarlang]

Proposed middle-part:

Alternatively, strict validation of the Sec-Fetch-* can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source).

Attempt to turn it into positive requirement:

Alternatively, strict validation of the Sec-Fetch-* can be used to verify that the request to sensitive functionality was initiated the way the application expects it (such as not accepting cross-origin request, navigation request, or executing functionality as called by image source).

If to keep the first option, "such as an image source" needs to be updated to say that "executing functionality being loaded as image resource is not accepted if not intended".

[tghosth]

or executing functionality as called by image source

I don't understand why this level of detail is necessary? We have already said this is about calling sensitive functionality. When would we ever expect this from a resource load?

[elarlang]

Images and dynamically creating images can be called as an image resource and it is expected functionality.

[tghosth]

"V13.6.2 - [MODIFIED, MOVED FROM 13.2.1] Verify that calls to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. This is particularly important if the application does not distinguish between URL parameters and message body parameters."

Good enough? 👆

[elarlang]

One more finetuning:

Verify that calls to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. This is particularly important if the application does not distinguish between URL parameters and message body parameters

[tghosth]

Ok so I think we are there, I think all these requirements now belong in V50.4 so I would propose as follows:

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 or by a trusted party and has not been forged by an attacker. The keywords here are browser security policies like Same Origin Policy for JavaScript and also SameSite logic for cookies. Another common protection is the CORS preflight mechanism. This mechanism will be critical for endpoints designed to be called from a different origin, but it can also be a useful request forgery prevention mechanism for endpoints which are not designed to be called from a different origin.

The category should contain requirements with ideas:

• Verify that the request was initiated by a trusted party (CSRF, CORS misconfiguration)
• Verify that the response is readable only for trusted parties (CORS misconfiguration)

#	Description	L1	L2	L3	CWE
50.4.1	[MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that CORS-safelisted requests to sensitive functionality are checked to ensure that they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).	✓	✓	✓	352
50.4.3	[MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3] Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a CORS-safelisted request. This may require checking the values of the 'Origin' and 'Content-Type' request headers or using an extra header field that is not CORS-safelisted.	✓	✓	✓	346
50.4.4	[MODIFIED, MOVED FROM 13.2.1] Verify that calls to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. This is particularly important if the application does not distinguish between URL parameters and message body parameters.	✓	✓	✓	650

---

V13

V13.2 Web Services

#	Description	L1	L2	L3	CWE
13.2.1	[MOVED TO 50.4.4]
13.2.3	[DELETED, MERGED TO 50.4.1]
13.2.5	[MOVED TO 50.4.3]

V13.6 HTTP Request Header Validation

Delete 13.6.2 and move the two reqs after it up by one number

---

Appendix A: Glossary

• Anti-forgery token - A mechanism by which one or more tokens are passed in a request and validated by the application server to ensure that the request has come from an expected endpoint.

[tghosth]

Let me know if you are good with this @elarlang and I will open a PR and make notes on the other relevant issues

[elarlang]

The chapter text should contain the explanation what kind of functionality must be protected and it is valid for authenticated and non-authenticated users.

I need to rethink the modification tags, but you can start with the PR.