4.2.2 does not seem like access control

[jmanico]

CSRF is also called "session riding" and is more of a session theft protection vs access control and should be moved

4.2.2	[MODIFIED, 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 plus additional defense in depth measures.	✓	✓	✓	352

[elarlang]

"CSRF is not authorization issue" - this conclusion was made here: https://github.com/OWASP/ASVS/issues/795#issuecomment-743720732

And if the opened issue is just for wrong category, it's duplicate of https://github.com/OWASP/ASVS/issues/1352#issue-1352215924 + https://github.com/OWASP/ASVS/issues/1230

Previously pretty much the same issue was opened here: https://github.com/OWASP/ASVS/issues/1193

To call it session riding covers most of the issues with CSRF, but gives maybe wrong signal like CSRF is the issue only for autenticated users with active sessions. CSRF is also an issue also for not-authenticated users.

[tghosth]

I am going to drop this into the v3 rework bucket for now. I agree that access control seems like the wrong place but not sure I would consider it a client side control either.

[elarlang]

... not sure I would consider it a client side control either.

any arguments?

[jmanico]

I agree with you #jimAgreesWithElarOn Jul 16, 2023, at 10:45 PM, Elar Lang @.***> wrote:

... not sure I would consider it a client side control either.

any arguments?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[tghosth]

... not sure I would consider it a client side control either.

any arguments?

For CSRF protection, the security mechanism is enforced at the server-side not the client side. Except for the samesite attribute.

[elarlang]

... not sure I would consider it a client side control either.

any arguments?

For CSRF protection, the security mechanism is enforced at the server-side not the client side. Except for the samesite attribute.

Quite confusing statement. From that perspective we kind of don't have any client-side problems, as most of them you protect on the server side.

Without a browser (client) this attack does not exists. So it is from attack perspective.

[tghosth]

Quite confusing statement. From that perspective we kind of don't have any client-side problems, as most of them you protect on the server side.

Apologies, that is not correct.

There are various controls which are implemented and enforced within the browser such as same origin policy, HSTS, etc. These are all things which the server signals to the browser what it should do but the implementation and enforcement is at the browser. Samesite attribute is another example of this.

Regular CSRF protection using tokens or whatever is implemented and enforced at the server. That is where the control exists.

You could argue that from a tester perspective, this is a client side attack but from a developers perspective this is a server-side control.

[elarlang]

You could argue that from a tester perspective, this is a client side attack but from a developers perspective this is a server-side control.

What is the correct perspective for ASVS?

Regular CSRF protection using tokens or whatever is implemented and enforced at the server. That is where the control exists.

Do you consider checking Origin header + checking correct request Content-Type header as a valid defense against CSRF (for API's)? If so, do you see it as "server-side" or as "client-side" mechanism?

[alamers]

What is the correct perspective for ASVS?

Just a suggestion: from an end user perspective, it would be nice to be able to quickly decide if the control is applicanle at all. E.g., if I don’t have a front-end, should I care about this control?

[elarlang]

What is the correct perspective for ASVS?

Just a suggestion: from an end user perspective, it would be nice to be able to quickly decide if the control is applicanle at all. E.g., if I don’t have a front-end, should I care about this control?

... and this is my exact reason why I have proposed this to be included in "client-side" category (see https://github.com/OWASP/ASVS/issues/1230#issuecomment-1294517635 and https://github.com/OWASP/ASVS/issues/1230#issuecomment-1717182270).

[tghosth]

Ok, I spent some more time thinking about this @elarlang .

Right now, I am (still) thinking that CSRF is a session management problem. As such, to me it belongs in V3.

Now in principle, CSRF does not just apply to cookie-based session management:

There are several scenarios where non cookie CSRF is possible. The use of HTTP digest, network based AuthN and similar automatic mechanisms.

So we have two options:

1) CSRF requirement gets added to V3 as a general requirement. 2) We decide that none of the above options are valid AuthN options under ASVS and we add this to V3.4 as as a cookie related control.

Just a suggestion: from an end user perspective, it would be nice to be able to quickly decide if the control is applicanle at all. E.g., if I don’t have a front-end, should I care about this control?

I hear this and I think the "client side" category will help with this but I still don't think CSRF is included in that.

[elarlang]

I don't see as V3 requirement.

My comment from https://github.com/OWASP/ASVS/issues/1652#issuecomment-1580244294

To call it session riding covers most of the issues with CSRF, but gives maybe wrong signal like CSRF is the issue only for authenticated users with active sessions. CSRF is also an issue also for not-authenticated users.

Example 1 - let's force victim browser to make false authentication attempts. Victim does not have (business logical) session to the application. The result - most likely IP gets blocked, maybe user account gets locked etc.

Example 2 - non-authenticated users can leave some comments. Victim's browser is forced to enter some hate-speech or propaganda to some site. Done from victim browser and from victim IP.

[tghosth]

Argh ok, I am going call in the WG because I am not sure now 🙃

[tghosth]

[elarlang]

More input here: https://github.com/OWASP/ASVS/issues/1230#issuecomment-1776736512

[csfreak92]

What is the correct perspective for ASVS?

Just a suggestion: from an end user perspective, it would be nice to be able to quickly decide if the control is applicanle at all. E.g., if I don’t have a front-end, should I care about this control?

@alamers, is the rationale for this suggestion for security testing web APIs that don't have front-end? Is this also why you would agree with it, @elarlang? I am trying to understand the main issue further so that I can provide some ideas/thoughts.

[csfreak92]

Can you expand a little more on this? I have been researching most of the day to find out examples of CSRF tagged vulnerabilities on public disclosure reports on bug bounty platforms to look for examples, yet they don't seem fitting with the examples you have. Maybe you could clarify further for the WG?

CSRF is also an issue also for not-authenticated users.

As the examples given, I am quite confused how example 1 is CSRF-related. Maybe you could help me understand?

Example 1 - let's force victim browser to make false authentication attempts. Victim does not have (business logical) session to the application. The result - most likely IP gets blocked, maybe user account gets locked etc.

I understand example 2 that in a public forum setting that could happen and may be an issue for anonymous user-forums. Or maybe I'm wrong?

Example 2 - non-authenticated users can leave some comments. Victim's browser is forced to enter some hate-speech or propaganda to some site. Done from victim browser and from victim IP.

Initially reading the comments above, I am inclined to agree with @tghosth as CSRF is more of a v3 Session Management-related vulnerability (which lightly touches on authorization somehow, but for the argument sake I would stick with v3 as well). I think having it as a general v3 requirement is better as the controls can be applied on both client-side and server-side whether in development or testing.

[elarlang]

As the examples given, I am quite confused how example 1 is CSRF-related. Maybe you could help me understand?

Eem, well.

<script>
function poll() {
  fetch('https://APPLICATION.TLD/path/to/login', {
    method: 'post',
    mode: 'no-cors',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
    },
    body: 'username=valid&password=not-valid'
  });
}
setInterval(poll, 100);
</script>

Constantly hitting authentication form via victim browser from external site. No session involved.

[elarlang]

CSRF is also an issue also for not-authenticated users.

This was linked by Josh, but here: https://github.com/OWASP/ASVS/issues/795#issuecomment-828717449

[jmanico]

CSRF is also an issue also for not-authenticated users.

Agreed. In the past I could use unauthenticed CSRF to force folks default Google language to Klingon or force items into folks shopping carts.

But is this really a ASVS worth risk? Unauthenticated functionality is rarely a real security issue.

[elarlang]

But is this really a ASVS worth risk? Unauthenticated functionality is rarely a real security issue.

https://github.com/OWASP/ASVS/issues/1652#issuecomment-1778792816

For sure mostly CSRF are made and published against authenticated users with active sessions, but by concept is not session management problem (if we don't keeping a state as session).

[jmanico]

But is this really a ASVS worth risk? Unauthenticated functionality is rarely a real security issue.

#1652 (comment)

For sure mostly CSRF are made and published against authenticated users with active sessions, but by concept is not session management problem (if we don't keeping a state as session).

This is absolutely a session-based problem. Even unauthenticated users have an anonymous session of some kind.

[elarlang]

But is this really a ASVS worth risk? Unauthenticated functionality is rarely a real security issue.

#1652 (comment) For sure mostly CSRF are made and published against authenticated users with active sessions, but by concept is not session management problem (if we don't keeping a state as session).

This is absolutely a session-based problem. Even unauthenticated users have an anonymous session of some kind.

Yes, they may have and this is is exact reason why I said:

(if we don't keeping a state as session)

and

Example 1 - let's force victim browser to make false authentication attempts. Victim does not have (business logical) session to the application. The result - most likely IP gets blocked, maybe user account gets locked etc.

so there are 2 things - which I call in my training "technical session" and "business logical session".

Technical is for keeping state for unauthenticated user, for example to be sure, that user is doing things in the same order.

Business logical is when user authenticates and gets access to own-related data.

So this is how I explain things in my training, but I'm not really sure it works well without entire context somewhere else.

[csfreak92]

This is what I am trying to get into. I don't see it much of a risk or real security issue as well just like @jmanico said:

But is this really a ASVS worth risk? Unauthenticated functionality is rarely a real security issue.

Isn't this covered by rate-limiting controls? I can see the concern that it could be an issue with locking down an IP of a legitimate user, but that usually ends up in a helpdesk situation to deal with. I understand the merit for an unauthenticated form such as a "report violation" functionality which I abused one time on a pentest, which I constantly hit hundreds of times for that unauthenticated endpoint and caused hundreds of tickets in the company's incident response team to triage. However, I placed that under business logic issues/bugs which is in this case covered already in ASVS such as 11.1.5

Constantly hitting authentication form via victim browser from external site. No session involved.

[elarlang]

The example I gave hits rate-limiting (11.1.5), but it misuses the limit and gets victim blocked and there is the place where CSRF is. You need to check CSRF before checking next level limits.

[elarlang]

In general, I don't mind to explain things - but here, it rising many questions.

Let's take this "authentication attempts CSRF" for the vulnerability - https://github.com/OWASP/ASVS/issues/1652#issuecomment-1778792816

If a random site in the Internet can force someones browser to make wrong authentication attempts and this way lock user out of his own account (especially nice when it's domain account somewhere in active directory). Also, "random site" can be public site and "site to authenticate" can be in internal network for the victim.

We can debate, is this "enough critical for ASVS" or not, but here the topic is - to which category CSRF belongs.

I take the previously vulnerable attack code, and make some fix.

Fix 1 - as request contains Origin header, the application on the server-side checks the Origin value to be in allow-list. Cross-Site part is taken down.

Where is the session here?

Fix 2 - let's use "double submit" pattern - an application sends one "csrf-token" cookie. With every request, there is extra HTTP header x-csrf-cookie (classical example) and it's value must match with cookie value.

Where is the session here?

[jmanico]

I stand corrected, this is a good reason to protect against unauthenticated CSRF.

[csfreak92]

Thanks for the explanation! This is really helpful now that you have painted that unauthenticated CSRF is also an issue (maybe we have to update in the OWASP definitions as well somewhere that this is an issue as just explained here, but that's another topic outside of this main issue). In that case, yes Fix 1 and 2 makes sense to mitigate it and I would agree as well, given you mentioned if a user's domain account got locked through this attack.

I still don't know where CSRF should belong though. My best hunch at the moment is this is a session management-related issue.

[elarlang]

@csfreak92 - so you agree based on given examples that it is not session management problem, but still think that the best choice for that is session management?

I have provided examples, how it is not session management problem, I think it should be enough. If someone has opposite argument, then please - with practical experience on the topic where you argument and with examples to cover your arguments.

[csfreak92]

This is absolutely a session-based problem. Even unauthenticated users have an anonymous session of some kind.

Hi @elarlang, to quote @jmanico this is also my thought now regarding unauthenticated CSRF thanks to your clear and awesome examples fall into session management (even if it is an anonymous session handling). I think the one with rate limiting code example trying to lock the victim falls into this as well.

So, regarding the fixes you mentioned:

Fix 1 - as request contains Origin header, the application on the server-side checks the Origin value to be in allow-list. Cross-Site part is taken down.

Where is the session here?

Ok, in here yes there is no real session being handled whether authenticated or unauthenticated. This is a wrinkle and I understand why you don't see CSRF as under session management. I am struggling as well where to put CSRF now, but my best bet is under session management as most of the other cases of CSRF examples including the one below seems to fit there.

Fix 2 - let's use "double submit" pattern - an application sends one "csrf-token" cookie. With every request, there is extra HTTP header x-csrf-cookie (classical example) and it's value must match with cookie value.

Where is the session here?

Here, the CSRF token somehow acts like an unauthenticated session (please do correct me if I am overthinking this, but that's the sort of understanding I have in this instance) as it is a way to determine that a certain HTTP request is from a certain "user".

I do believe it is best choice to be placed under session management requirements. I cannot think of a good alternative unless the other folks have better ideas please?

[elarlang]

"Fix 2" - server sets a cookie to the browser and expect the same cookie back in HTTP request and also expects the same value as cookie in one extra HTTP header, but server do not keep a state or session for the user on the server side.

[elarlang]

So it doesn't matter how many times I prove it's not in session management, it's still in session management?

[meghanjacquot]

Ok, so keeping with these fixes in mind, then if we're thinking not session management and not access control then is there a new category that should be created? These seem like they could be verification

Fix 1 - as request contains Origin header, the application on the server-side checks the Origin value to be in allow-list. Cross-Site part is taken down.

Where is the session here?

Fix 2 - let's use "double submit" pattern - an application sends one "csrf-token" cookie. With every request, there is extra HTTP header x-csrf-cookie (classical example) and it's value must match with cookie value.

[elarlang]

for that proposal we have another monster-issue: https://github.com/OWASP/ASVS/issues/1230#issuecomment-1287381350

TLDR: category "Attacks via browser" (not wording proposal) > section "Confused deputy"

[jmanico]

It is mostly a session management issue Elar, even if its not always session management. Is that fair?

[elarlang]

It is mostly a session management issue Elar, even if its not always session management. Is that fair?

This is what I wrote in my fist response: https://github.com/OWASP/ASVS/issues/1652#issuecomment-1580244294

Yes, it is mostly used against active sessions because there it gives more impact for attacker.

By concept and technically it is not session management problem - you all agreed it is an issue against not-authenticated users. Why you still push it to session management...

Do we want to put XSSI (https://github.com/OWASP/ASVS/issues/903#issuecomment-1048862338) also to session management because it is mostly used against active sessions? (The answer is no,)

[elarlang]

For me it seems that some may live a bit in "yesterday", so few more pieces of information.

You can watch Cross-Site Request Forgery as "session riding" when a browser sends session information automatically with a (forged) request.

Point 1 - when it is not sent automatically, nowadays - if session management is done with tokens and JavaScript need to put extra Authorization header into each request - it is not happening automatically by the browser.

This solution provides defense against CSRF attacks - you have a session, but you don't have CSRF.

Point 2 - Session identifier is/was automatically sent via cookies, nowadays SameSite=Lax is default

Previously browsers sent automatically cookies with every request if those cookies just matched with the condition. Nowadays there is SameSite attribute for limiting that and most important here - most browsers by default set it to Lax. By this table, FireFox do not belong to this list, but FireFox has different cookie policy system, which also blocks automatic cookie sending.

It means - to have Cross-Site Request Forgery to be effective, you need to attack vector in Same-Site scope. Which makes "Cross-Site" part in the attack name quite... conflicting.

Other option to have CSRF vulnerability is when someone configures SameSite=None, but nowadays this one requires also Secure attribute to be set.

So it's fair to say - automatic CSRF which we know as "session riding" do not exist anymore with default configuration.

@jmanico - does it changes your point of view for (https://github.com/OWASP/ASVS/issues/1652#issuecomment-1789302498)?

Point 3 - authentication without session

If somewhere is Basic authentication used, then browser sends the authentication information as Authorization header with the request by default. We don't have session for the user, but we can force user browser to do requests. No session to ride.

Point 4 - and now, when we don't have authenticated user or session.

Like proved here with attack scenario and Fix 1 and Fix 2, then the problem is actually more abstract and should be called "Client-Side Request Forgery" or "Browser Request Forgery" (Cross-Site in the name is mis-leading)

The point is - the defense must avoid accepting any forged request from 3rd party site via victim browser (which is not allowed to be by the application that way).

First and more known problem - if 3rd party site can force victim browser to make data operations as victim (previously given example - entering hate-speech or illegal content to some application).

Second - forcing victim browser to hit rate-limiting limits (or do whatever attacks), and there can be impact like locked user-account because of too many authentication attempts or just too many HTTP requests because of "Hotlinking". Basically we should talk about site-isolation here.

And maybe even worth separate requirement - origin of the request and anti-csrf must be checked before doing any action (like doing authentication or checking rate limits)

[tghosth]

I am happy to agree that this is not a session management problem.

I guess going back to basics, CSRF is basically spoofing because you are taking over another endpoint's identity. So maybe we need to move this to V2.

Either way, Elar I am comfortable to take the steer from you on where to put this but let's make a decision and move on as I don't want this to block us.

[elarlang]

So maybe we need to move this to V2.

... I can probably write the same lengthy responses for/against this line. So at the moment I take direction to move it to "browser-side" and we just need to put descriptive chapter/section title there.

[jmanico]

Maybe we need a new category for CSRF since it does not fit will anywhere else.

Perhaps "General Web Security"

[elarlang]

Again new ideas, instead of following my proposal - without being able to say any opposite arguments.

First - V2 - it is for authentication. With CSRF attacker don't fake himself to the application to be someone else. The expected fix is not related with authentication. CSRF is problem also for non-authenticated users.

With tiny sarcasm, I can take recommendation from Jim and rename this so called "client-side" to "General Web Security" and everything is legit :)

So what is CSRF?

Problem for CSRF - an attacker can force victim browser to do a request and server accepts it. The reason is not related to authentication, session or authorization. The outcome can be used against any category.

Expected defense against CSRF - an application must be sure, that the request was initiated from the same application (from the same Origin) and from the functionality which was intended to do so (i.e in same-origin situation you can not call resource demanding API request as image source from wysiwyg).

[jmanico]

Sa ei pea CSRF-i või ASVS-i pärast nutma, isegi kui me ei nõustu, kõik saab korda, Elar!

[tghosth]

Ok so looks like this is now relying on #1230

[elarlang]

The requirement is moved to the new "Web Frontend Security" category, as 50.3.1