search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.62k stars 639 forks source link

Add OAuth2 requirements #996

Open csfreak92 opened 3 years ago

csfreak92 commented 3 years ago

Ed note: This issue was originally called "v3.5 Token-based Session Management addition"

Ed note 2: If you are just joining us, the draft chapter is currently here: V51 OAuth 2.0 Protocol

Before you review it, read through this issue thread to collect the context and then feel free to open separate issues if you have specific questions or suggestions.

Original text starts here:

I think we need to add a control that validates the incoming HTTP request in an API endpoint which issues new access and refresh tokens. Usually this is with the refresh endpoint, but in some weirdly built applications, there were some implementations that every response would contain the new tokens that could be used for the next authenticated and authorized calls to the API. The requirement would be for the refresh token endpoints to have a validation of the requests, URL and request body must be validated before issuing the new set of tokens.

The rationale about this thought came to me when I was testing a few recent applications that either have refresh endpoints or a few ones that do not have refresh endpoints but the next authenticated tokens are coming from the HTTP responses. This is a bit of an old way of doing it as I understood and a bit uncommon. However, I noticed a pattern of accepting the request even if it was malformed or missing the object id or any reference for a resource (e.g. http://www.example.com/12345 but I the request was http://www.example.com/ralph; second URL is invalid and should be rejected). The application returns no valuable data except the new set of tokens which can be used for the succeeding calls to the API. I think it was a bad design, but for defense in depth purposes and preventing an attacker for prolonging their usage of the compromised account (which would be cut short had the application been following proper OIDC flow), the application should check for incoming HTTP requests to be correct in format, parameters, etc. and if anything is wrong then reject the request and never send back new tokens.

I would place this under v3.5 Token-based Session Management. I don't know whether this is still an acceptable thing to worry about and whether the threat model is too low to bother about this control, but I think it just seems like a basic thing that developers should have placed some sort of validation for requests before allowing the scenario described to happen. If this is too low risk, then we could scrap it.

jmanico commented 2 years ago

I like this, but do we need a new OAuth2 section that covers https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18 ?

csfreak92 commented 2 years ago

That is a great question though.. In wishful thinking I think we should add something OAuth2 best practices as well. I believe a lot of developers are not aware how to properly implement this on their applications.

jmanico commented 2 years ago

OAuth2 is a special protocol for just delegation and is often misused. But a dedicated section for OAuth in 5.0 is a great idea!

csfreak92 commented 2 years ago

@jmanico, would you like me to draft a proposal for OAuth2 dedicated section? I believe that also deals with the original issue I opened here.

jmanico commented 2 years ago

Mr. @csfreak92 absolutely yes. And we can a get few of the OAuth2 security group folks to review. You can extract a lot from https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics to help you

csfreak92 commented 2 years ago

Sounds good, let me thoroughly read it and then draft something soon (might be a bit later). :)

csfreak92 commented 2 years ago

Just an update. I'm still actively working on this over spare time, please do not close the issue.

tghosth commented 1 year ago

Hi @csfreak92, any update on this, would like to get this prepared for 5.0

@set-reminder 1 month consider closing this issue

octo-reminder[bot] commented 1 year ago

⏰ Reminder Saturday, January 7, 2023 12:00 AM (GMT+01:00)

consider closing this issue

csfreak92 commented 1 year ago

@tghosth, @jmanico, as promised here is my initial draft for the OAuth requirements (with some references to OpenID Connect) as I have derived from the RFC: (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics).

I still need to add the CWE mappings and more details for the explanatory paragraphs about each of them. I have two questions how we wish to present these new to be added requirements:

  1. I propose a section 3.8.x to keep all OAuth requirements separate and easier for anyone using ASVS for security audits. If that is good for you guys, then shall I keep it like this where there's a separating subsection as per the security threats presented RFC that I followed? Also, shall I add separate explanatory paragraphs each or do you prefer all those explanations about Authorization Servers, Clients, Resource Servers, PKCE, etc. all in one huge chunk of paragraphs right after 3.8.x section title? Which one do you think is better?
  2. If having a separate section for OAuth requirements seem quite too much and redundant (as we have token-based session management requirements), then I will need further help with splitting them to other 3.x sections.

I am sure I might be missing a few more things, but I just pushed my initial draft so that I don't keep holding this issue from moving forward and start the year right. :)

elarlang commented 1 year ago

I have not yet went into details, but first impression is - 18 requirements on one topic is a bit too much and maybe we need some abstraction.

I don't think we need all related OAuth requirements in one category if the same point is covered in general somewhere else. To have easy to follow "checklist" is maybe more testing guide approach.

Maybe we should have discussion in the issue first, not discussion over PR's. From PR's it's hard to follow later, why some requirements got in or why some changes were made.

Really nice input to work on!

csfreak92 commented 1 year ago

@elarlang, yeah I do agree that 18 requirements for one topic is quite too much, honestly. I have this dilemma too, but there's another dilemma if I will cut them down.

An example is if you look at 3.8.12 - 3.8.14 in that draft, those all pertain to IDORs and ACLs which are covered somewhere in ASVS. However, OAuth-specific ones kind of make sense if our main objective in this issue is to teach developers and engineers how to properly use OAuth. This is one of my dilemmas which had been paralyzing me for a while what to do with it. I'd like to hear it from the community so that I can finally get that off my head. :)

All of these 18 are derived from the OAuth RFC which is quite comprehensive. Great yeah, having a discussion about the issue would be very helpful too, at least in my view for trimming down the PR.

jmanico commented 1 year ago

OAuth is complex. 18 requirements are critical. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics has many more and is recent...

jmanico commented 1 year ago

I love this work! Steallar!

elarlang commented 1 year ago

Another topic is category - I don't think session management is the best place for covering OAuth. If it is 18 requirements (or even 10+) with splitting to different topics, it may be worth separate main category.

jmanico commented 1 year ago

OAuth is so important for _access delegation and API access that I do think it's critical for a new category.

Once we have the initial batch I can loop in some top tier experts to review.

And please be sure to include the requirements from the OAuth 2.0 BCP (Best Current Practice) for the most up to date requirements.

octo-reminder[bot] commented 1 year ago

🔔 @tghosth

consider closing this issue

csfreak92 commented 1 year ago

@jmanico, almost those 18 requirements I have drafted there were straight from the RFC's best current practice. I may have left some out, which I will do another few passes to ensure at least the critical ones are included.

Also, if this will be a new category, what number shall I assign to it? Should it be next to Session Management category so that it stays relative?

tghosth commented 1 year ago

Hi @csfreak92,

This is really fantastic work, I can see how much effort you have put into it.

However, I am a little nervous that the level of detail is significantly more that we should probably have in the ASVS. The level of detail feels more like an OWASP cheatsheet. (I think this point could also be accurately made about parts of V2 but that is a different discussion for another day).

@jmanico what do you think?

@csfreak92 Do you think there is any way it could be trimmed down to key essentials?

For now I have created a dedicated branch for it.

csfreak92 commented 1 year ago

Thanks @tghosth, @jmanico and @elarlang for chiming in your thoughts and praises! It is still draft at first stages, but I had a lot of dilemmas presenting these requirements as I said earlier that some of them may have been covered by ASVS in other sections (in some ways or another).

@tghosth, I have the same worry too as the level of detail was taken straight from the RFC which makes it too strict of an implementation guideline including the Authorization Server, Resource Server and other components that make up an OAuth setup.

I'll see what I can do to trim them down to the key essentials and push another commit soon. I'll add the subsection explanatory paragraphs too to explain such terms and their meaning.

tghosth commented 1 year ago

thanks, I think it deserves it's own section and I think it should obsolete 3.5.1

csfreak92 commented 1 year ago

Still doing some clean-up and trimming it down. Any number for the new section that I should use, @tghosth? I agree that the current 3.5.1 should be obsolete after this new section.

csfreak92 commented 1 year ago

Also, combing through the RFCs and related documents together with searching the net for any CWEs that I can map the new OAuth 2.0 requirements and could not piece them together. Any ideas how else I can do that? Or shall we leave them blank for now and add those later?

elarlang commented 1 year ago

I think it does not make sense to waste time for CWE mapping at the moment as there is quite big chance that we will remove this mapping.

https://github.com/OWASP/ASVS/issues/1481

tghosth commented 1 year ago

Agree that there is no need for a CWE mapping right now.

I remain concerned by the number and complexity of the requirements and still think it needs cutting down. I would also urge you to create a cheatsheet because I think the information you have provided is super valuable, just too in-depth for this use case.

Can we cut this down to a few requirements that an OAuth2 client needs to consider and a few requirements that a Resource Server needs to consider. Presumably implementing an Authorization Server is a much more niche situation.

What do you think @csfreak92?

csfreak92 commented 1 year ago

@tghosth, I did not add anymore CWE mapping for the draft pull request.

Regarding the complexity of requirements, I agree with you that maybe we should just focus on OAuth2 client needs as the implementation of an Authorization Server is a niche situation. Although, just out of curiosity, what are the chances and scenarios where an organization would implement their own Authorization Server?

About the cheatsheet, for sure I can do that. Where shall I place those? I presume appendix somewhere?

tghosth commented 1 year ago

Hey @csfreak92, good to see you 😀👋

Regarding the complexity of requirements, I agree with you that maybe we should just focus on OAuth2 client needs as the implementation of an Authorization Server is a niche situation.

Would be great if you could do this, yes :)

Although, just out of curiosity, what are the chances and scenarios where an organization would implement their own Authorization Server?

I am not sure to be honest but I think it is a little unusual.

About the cheatsheet, for sure I can do that. Where shall I place those? I presume appendix somewhere?

Suggest you put it into the cheatsheets project. I would suggest you open an issue and ask them whether you should add it to the existing cheatsheet or create a new one.

csfreak92 commented 1 year ago

@tghosth, apologies for being MIA. Conferences and work travel has taken over the past few months. If we have an instant messaging channel/system we use, please add me there too :)

Ok, will rework my pull request and submit an update before I fly again in 4 days.

If the implementation of an Authorization Server is quite unusual, then yeah I agree we have to trim those down from the OAuth 2.0 requirements for ASVS, but I'll retain these on the cheatsheet.

Oh, ok let me do that cheatsheet project separately. For a second I thought you wish to add that in ASVS, good to know I clarified.

tghosth commented 1 year ago

apologies for being MIA. Conferences and work travel has taken over the past few months.

Didn't mean that :) Just pleased to see you, I was worried we had scared you off 😂

If we have an instant messaging channel/system we use, please add me there too :)

We will probably speak further about this, is LinkedIn messaging the best way to get in contact with you?

Ok, will rework my pull request and submit an update before I fly again in 4 days.

Fantastic, thanks!

Oh, ok let me do that cheatsheet project separately. For a second I thought you wish to add that in ASVS, good to know I clarified.

Excellent :)

csfreak92 commented 1 year ago

No scare at all! Just got flying to different places and cities for work recently and got a breather.

Yes please, for now we can use LinkedIn messaging until the leaders and core team agrees on an instant comms channel. I look forward to your message! :)

@tghosth, quick question: won't it be overwhelming for folks out there that there's bunch of OWASP cheatsheets we have? I checked it out and there's a lot for different things which I would argue most are covered either by ASVS, OTG or Top 10. Anyway, that's not very important, just curious about it.

tghosth commented 1 year ago

quick question: won't it be overwhelming for folks out there that there's bunch of OWASP cheatsheets we have? I checked it out and there's a lot for different things which I would argue most are covered either by ASVS, OTG or Top 10. Anyway, that's not very important, just curious about it.

I think it is intentional that there are a lot of OWASP cheatsheets, the idea is that cheatsheets go into far more detail than the ASVS is able to.

jmanico commented 1 year ago

I don’t understand your question. One more time please?

csfreak92 commented 9 months ago

I don’t understand your question. One more time please?

Is this for me, @jmanico?

jmanico commented 9 months ago

I’m not 100% certain, please ignore.

tghosth commented 9 months ago

I renamed this as it is more about OAuth now.

I preserved the original name in: https://github.com/OWASP/ASVS/issues/996#issue-889784907

tghosth commented 7 months ago

I have merged this into a dedicated branch and moved the content to a dedicated chapter. I will make more changes and post here with updates.

tghosth commented 7 months ago

Hi @csfreak92, thanks for the updates, appreciate your hard work!

Two tasks right now:

elarlang commented 7 months ago

I open a bit wider question.

Should we really be limited with OAuth 2.0 or should take direction to OAuth 2.1:

Yes, it's draft, yes, it's not released etc.. but.. it is a patch for OAuth 2.0 known weaknesses.

For software components we have requirement:

# Description L1 L2 L3 CWE
14.2.1 Verify that all components are up to date, preferably using a dependency checker during build or compile time. (C2) ✓ ✓ ✓ 1026

I interpret, that using features provided by OAuth 2.0 is using component with known weaknesses. There are reasons why OAuth 2.1 is proposed and for it makes sense to require to use technical solutions without known weaknesses.

In this context it means - can we just require everyone to use only PKCE flow for public OAuth clients (so-called "Standard Authorization Code flow" is not good enough). It also disallows using implicit flow and password grant.

Take into account, that it takes time to release v5.0 and then it takes years to release v6.0, between them we can not have breaking or major changes, we going to set the situation for years. I don't want to go with a solution, which is deprecated from the start.

tghosth commented 7 months ago

@csfreak92 do you think targeting OAuth2.1 is possible. I agree that conceptually it would make for a good aim and better to be ahead of the curve.

csfreak92 commented 6 months ago

Hi @elarlang and @tghosth, let me take a look at adding OAuth 2.1 as well. Good idea if we can put it on ASVS 5.0 and be ahead. Let me do more research on it and push changes soon.

jmanico commented 4 months ago

@csfreak92 do you think targeting OAuth2.1 is possible. I agree that conceptually it would make for a good aim and better to be ahead of the curve.

The requirements that came from the OAuth 2 BCP is essentially what is being moved to OAuth 2.1

jmanico commented 4 months ago

I open a bit wider question.

Should we really be limited with OAuth 2.0 or should take direction to OAuth 2.1:

Yes, it's draft, yes, it's not released etc.. but.. it is a patch for OAuth 2.0 known weaknesses.

For software components we have requirement:

Description L1 L2 L3 CWE

14.2.1 Verify that all components are up to date, preferably using a dependency checker during build or compile time. (C2) ✓ ✓ ✓ 1026 I interpret, that using features provided by OAuth 2.0 is using component with known weaknesses. There are reasons why OAuth 2.1 is proposed and for it makes sense to require to use technical solutions without known weaknesses.

In this context it means - can we just require everyone to use only PKCE flow for public OAuth clients (so-called "Standard Authorization Code flow" is not good enough). It also disallows using implicit flow and password grant.

Take into account, that it takes time to release v5.0 and then it takes years to release v6.0, between them we can not have breaking or major changes, we going to set the situation for years. I don't want to go with a solution, which is deprecated from the start.

For sure. Here are the main differences between OAuth 2.0 and 2.1 and topics we should cover to address 2.1.

csfreak92 commented 4 months ago

The requirements that came from the OAuth 2 BCP is essentially what is being moved to OAuth 2.1

Yup, that's why I was still double checking if I missed something on the Best Current Practices from our current draft though most seems to cover OAuth 2.1 as you have pointed out @jmanico. There were some that we have omitted in the current OAuth 2.0 draft as it is covered in other ASVS chapters like the URL redirect handling (which is also in OAuth 2.1 exact string matching that maybe we should call out?).

tghosth commented 4 months ago

Hi everyone,

If you are just joining us, the draft chapter is currently here: V51 OAuth 2.0 Protocol

We'd love people to review the chapter and provide feedback. Before you review it, please read through this issue thread to collect the context and then feel free to open separate issues if you have specific questions or suggestions.

jmanico commented 4 months ago

I had some of my OAuth2 friends review this, this morning. Here are a few suggestions:

* Prevent Authorization Server Mix-Up Attacks: Include up-to-date strategies for mitigating mix-up attacks in environments with multiple Authorization Servers. Detail the use of the "iss" parameter and recommend additional checks like verifying the "aud" claim.

*Detailed Scope and Audience Implementation: Provide concrete examples of how to implement and validate access token restrictions based on scope and audience to offer actionable guidance.

csfreak92 commented 4 months ago

I had some of my OAuth2 friends review this, this morning. Here are a few suggestions: *

Thanks Jim! I'll take a look and create a PR to address these and bundle the OAuth 2.1 additions that are needed.

TmmmmmR commented 3 months ago

It's a wonderful addition to have a dedicated section for OAuth.

Regarding section 51.1.4 token rotation can mitigate token replay attacks, it cannot entirely prevent them.

Consider the scenario where an attacker exploits an XSS in a client-side JS application that performs silent token refresh. This allows the attacker to intercept all token refresh operations. In this case, the attacker simply waits until the client becomes inactive and then catch the latest refresh token to obtain fresh tokens. So, as long as the attacker don't use the stolen refresh tokens immediately, the authorization server's detection mechanisms remain inactive.

This article describe this scenario with more details : https://www.pingidentity.com/en/resources/blog/post/refresh-token-rotation-spa.html

TobiasAhnoff commented 3 months ago

Hi! I would like to contribute with feedback and have a few initial questions to get better understanding of goals, level of detail etc, before adding feedback as more specific issues.

To start with, I think it is good that ASVS adds guidance on OAuth and OIDC, since many web applications built today use OAuth/OIDC in some way and technically detailed guidance/requirements are a little bit "hidden" in specs and RFCs. But a concern is that it will be challenging for ASVS to summarize and highlight the most important things, get the right amount of detail and align with all "best current practices" as they change...

Perhaps this will make my thoughts clearer:

In the first section it is stated that this "summarizes the best current security practices for OAuth 2.0 as derived from its RFC 6750 and 6749" and OIDC is also is mentioned.

Two set of specs for OAuth2/OIDC that are often referenced and used for guidance when building and testing OAuth2/OIDC solutions are https://oauth.net/2.1/ (in particular https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) and https://openid.net/wg/fapi/specifications/ (in particular https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html, applicable for domains with high security requirements like finance and healthcare etc).

Have you considered adding additional requirements and recommended mitigations found there?

For example, FAPI 2.0 defines about 30 verifications for the authorization server while ASVS currently has 6, in particular ASVS does not mention PAR. And if we compare FAPI and ASVS guidance for resource servers ASVS has 3 requirements while FAPI has 5, which looks like this, some overlap, but also differences.

5.3.4. Requirements for resource servers The FAPI 2.0 endpoints are OAuth 2.0 protected resource endpoints that return protected information for the resource owner associated with the submitted access token. Resource servers with the FAPI endpoints

  1. shall accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750];
  2. shall not accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750];
  3. shall verify the validity, integrity, expiration and revocation status of access tokens;
  4. shall verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in Section 3.1 of [RFC6750]; and
  5. shall support and verify sender-constrained access tokens using one or both of the following methods:
    • MTLS as described in [RFC8705],
    • DPoP as described in [RFC9449].

I understand if it is hard to answer this open question, but it would be interesting if you could elaborate some more on this, for example why there are differences and what role ASVS is meant to play in addition to guidance and requirements found at https://oauth.net/2.1/ and https://openid.net/wg/fapi/specifications/

Thanks for all work with ASVS, it is a great resource! Please let me know if you would like me to submit more concrete feedback in issues.

elarlang commented 3 months ago

Hi @TmmmmmR - I have addressed the issue from another perspective, such as do not allow any refresh tokens to the browser at all. See https://github.com/OWASP/ASVS/issues/1916#issue-2207465783 # Discussion/Proposal 1.

If you agree it is the same topic and the same problem, please continue the discussion in the other issue.

elarlang commented 3 months ago

Hi, @TobiasAhnoff - I agree with your point of view and (y) for the attitude to understand the situation first.

The situation at the moment:

The action plan here can be - if you feel, that the OAuth paragraph is missing some requirement, then just point it out. If it is covered somewhere else, we can then say it. For me it's probably faster to say is it covered than for you to investigate the entire ASVS for each potential proposal.