New CS proposal: OAuth 2.0 Cheatsheet

[csfreak92]

What is the proposed Cheat Sheet about?

As suggested by my conversations with the OWASP ASVS leaders, my proposals for ASVS requirements were too detailed (as they were taken straight from the official RFC), they suggested me to trim the ASVS requirements down but since my work on the detailed OAuth 2.0 requirements would go to waste, they suggested me to open an issue about adding it to the OWASP cheatsheets, hence this issue proposal.

Reference: OWASP/ASVS#996

What security issues are commonly encountered related to this area?

Authorization and Authentication vulnerabilities in web apps, mobile apps and APIs.

What is the objective of the Cheat Sheet?

To provide a detailed information about OAuth 2.0 and its implementation.

What other resources exist in this area?

OWASP ASVS

[szh]

This sounds like a good candidate to me. Anyone have deep knowledge on this and willing to be a reviewer?

[mademarc]

Hey @szh Can i help out in reviewing this issue? i would like to contribute :)

[szh]

I can help review but I'm by no means an expert so I shouldn't be the only one.

[jmanico]

OAuth is really tough - all reviews are helpful!

[csfreak92]

@szh, if this is an acceptable cheatsheet proposal, shall I start a PR for a draft I have?

[szh]

Yes please, go ahead!

[mackowski]

@csfreak92 any updates on that?

[mademarc]

Hey all after look at this documents for this issue i have come up with some points in order to help everyone here:

Control Proposal Consideration

I kinda carefully reviewed the reference to OWASP/ASVS#996, where the need for a control to validate incoming HTTP requests in an API endpoint, specifically within the context of refreshing access and refresh tokens, is discussed. This proposal aligns well with the overall goal of reinforcing security measures in OAuth 2.0 implementations.

Proposed Control Details
The suggested control entails validating incoming HTTP requests, specifically for the refresh token endpoint, to ensure the correct format and parameters. This validation, encompassing both the URL and request body, is crucial to prevent scenarios where malformed or missing requests may still be accepted, leading to potential security vulnerabilities.

Rationale
the rationale behind this control is compelling, especially considering scenarios where compromised accounts could potentially prolong their usage due to inadequate request validation. While this may not be a prevalent design approach, incorporating such controls in the cheatsheet could serve as a valuable reference for developers aiming to bolster the security posture of their OAuth 2.0 implementations.

### Inclusion in OAuth 2.0 Cheatsheet Proposal (#1168)

So considering the significance of the proposed control, I recommend exploring its inclusion in the OAuth 2.0 Cheatsheet (#1168) under the appropriate section, possibly v3.5 Token-based Session Management. This addition would contribute to the cheatsheet's goal of providing comprehensive information on OAuth 2.0 and its implementation, particularly in addressing authorization and authentication vulnerabilities

### Next Steps

I personally encourage further community discussion on this matter to gather diverse perspectives. If you all could initiate a conversation within the OWASP community or cheatsheet maintainers regarding the proposed control, we can collaboratively assess its risk level and its alignment with the OAuth 2.0 Cheatsheet objectives.

If this sounds like a plan of action please comment and lets get to it :)

[csfreak92]

Ooops @mackowski, I just realized the first Pull Request I made is just for my own fork... how silly. I created a new PR for the master branch. This is my initial draft, maybe you could take a look?

[jmanico]

This is amazing work, Ralph!

[csfreak92]

Hey all after look at this documents for this issue i have come up with some points in order to help everyone here:

If this sounds like a plan of action please comment and lets get to it :)

@mademarc, noted and will adjust my cheatsheet proposal as I see fit. Take note that's a draft for now. I have parallel requirements for ASVS v 5.0 that is in-line with this, so I am working on both side-by-side as well to reflect the latest changes.