search

github / securitylab

Resources related to GitHub Security Lab
https://securitylab.github.com
MIT License
1.42k stars 246 forks source link

[go]: Add query for detecting CORS misconfiguration #379

Closed gagliardetto closed 3 years ago

gagliardetto commented 3 years ago

Query

Relevant PR: https://github.com/github/codeql-go/pull/542

CVE ID(s)

No CVEs.

Report

After the addition of JavaScript to Netscape Navigator in 1995, it became necessary to introduce a security model that could limit the actions that an agent could undertake on behalf of the user. Before JavaScript, only the user could initiate actions.

The model that emerged is referred to as the "same-origin policy". Over time, many web-related technologies and vendors converged towards using some variant of it.

But as with many policies that regulate the web, over time, different needs and use-cases arise and require exceptions to those rules.

It's for that reason that the Cross-Origin Resource Sharing (CORS) mechanism was introduced. The Same-Origin Policy and CORS are sets of rules that limit what defines an origin and what are the sub-resources that are accessible within that origin or from an external origin.

As many developers may testify, CORS is hardly the easiest or the most stable or consistent standard they had to deal with during their careers.

CORS can be challenging with its limitations and confusing to the uninitiated. Frustration sometimes can lead to implementing solutions that open the doors to vulnerabilities.

This query targets exactly that: scenarios where the CORS permissions (for one reason or another) are too permissive.

Example Attack Scenario

You opened a new bank account at myexamplebank.xyz.

For some reason (maybe management, maybe regulation), there are multiple front-end subdomains in the format {region}.myexamplebank.xyz (in your case, it is us.myexamplebank.xyz), and there is only one API backend (api.myexamplebank.xyz).

Different domains (and subdomains) count as different origins, which means that api.myexamplebank.xyz has to implement CORS in order to be reachable from the various front-end subdomains.

When us.myexamplebank.xyz makes an API call to api.myexamplebank.xyz, your browser checks whether api.myexamplebank.xyz returns a CORS policy that allows it to be reached cross-origin from us.myexamplebank.xyz. If yes, then the request can go through, and you can successfully manage your bank account from us.myexamplebank.xyz.

Behind the scenes, api.myexamplebank.xyz needs to reply with a Access-Control-Allow-Origin: us.myexamplebank.xyz header when hit with a preflight CORS request sent by the browser with the OPTIONS method (plus some other CORS headers, like Access-Control-Allow-Credentials: true, which also allows sharing your cookies).

But the developers at your bank made a huge mistake (maybe because of continuous new regions that were added, or maybe because the CORS policies were too restrictive and continued to break the bank website as the browsers continue to slightly tweak the CORS rules and implementations, or maybe management just wanted so):

They made the CORS policy dependent on what the front-end request Origin header is, mirroring its value in the response Access-Control-Allow-Origin header value.

Examples:

The issue is that there were put no restrictions for this to happen:

Gotcha!

That opens up the doors for an attacker to transfer to themselves all your bank funds when you happen to load evil.com (or any other malicious domain), which will be allowed to access api.myexamplebank.xyz and make transactions on your behalf.

You might not even notice it while it is happening. You might be browsing the web and randomly end up on a malicious page that will want to access api.myexamplebank.xyz and leave you broke.

Result(s)

Provide at least one useful result found by your query, on some revision of a real project.

References

ghsecuritylab commented 3 years ago

Your submission is now in status FP Check.

For information, the evaluation workflow is the following: SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed

JarLob commented 3 years ago

Some examples of FPs, could you please fix them?: hprose/hprose-golang (there is a condition when the map is empty, but I don't think you handle map check) husobee/vestigo nytimes/gizmo hprose/hprose-go wiatingpub/MTBSystem Basically if the origin value is validated it is not vulnerable.

gagliardetto commented 3 years ago

Thanks for the review!

I reduced the number of false positives: https://github.com/github/codeql-go/pull/542/commits/c0f195ba164df16410583c27c37d0f1e496d6b73

With the above changes, the FPs you mentioned are gone: https://lgtm.com/query/6956940192800229725/

gagliardetto commented 3 years ago

@JarLob

ghsecuritylab commented 3 years ago

Your submission is now in status CodeQL review.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

ghsecuritylab commented 3 years ago

Your submission is now in status SecLab finalize.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

ghsecuritylab commented 3 years ago

Your submission is now in status Pay.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

ghsecuritylab commented 3 years ago

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

xcorail commented 3 years ago

Created Hackerone report 1266540 for bounty 317935 : [379] [go]: Add query for detecting CORS misconfiguration

gagliardetto commented 3 years ago

Thank you @xcorail ! :confetti_ball: :confetti_ball: :partying_face: :confetti_ball: :confetti_ball: