8000 Google OAuth redirects still being blocked due to ".profile" · Issue #2212 · coreruleset/coreruleset · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Google OAuth redirects still being blocked due to ".profile" #2212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mac-chaffee opened this issue Sep 28, 2021 · 10 comments
Closed

Google OAuth redirects still being blocked due to ".profile" #2212

mac-chaffee opened this issue Sep 28, 2021 · 10 comments
Assignees
@azurit
Labels
➕ False Positive

Comments

@mac-chaffee
Copy link
mac-chaffee commented Sep 28, 2021 •
edited
Loading

Description

This is a resurfacing of Issue #1451 where a valid google oauth redirect gets blocked because it thinks you're trying to read from the ".profile" OS File.

A rule was implemented to try to detect google oauth and allow it:

coreruleset/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf

Line 24 in cebc7fd

# -=[ Google OAuth2 callback detection ]=-

But it seems to be too specific and fails my redirects. Example:

GET /accounts/google/login/callback/?state=123ommitted123&code=4%2F0AX4XfWj-123ommitted123-A&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+openid&authuser=0&hd=example.com&prompt=none
  • There are more than just 3 args, so the first rule fails
  • Even when I remove the restriction that there must be exactly 3 args, I think the regex is too restrictive too, not sure specifically how

Audit Logs / Triggered Rule Numbers

Sensitive data masked with "••••":

2021/09/09 20:09:55 [error] 2525#2525: *30580 [client ••••••••] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable
`TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] 
[msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-mult"[] [tag "attack-generic"] [hostname "10.233.123.103"] [uri "/accounts/google/login/callback/"] [unique_id "1631218195"] [ref ""], client: ••••••••], server: ••••••••], 
request: "GET /accounts/google/login/callback/?state=••••••••••••&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+openid&authuser=0&hd=renci.org&prompt=none HTTP/2.0", host: "••••••••••"

ModSecurity: Warning. Matched "Operator `PmFromFile' with parameter `lfi-os-files.data' against variable `ARGS:scope' (Value: `email profile https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinf (16 characters omitted)' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "78"] [id "930120"] [rev ""] [msg "OS File Access Attempt"] 
[data "Matched Data: .profile found within ARGS:scope: email profile https:/www.googleapis.com/auth/userinfo.email https:/www.googleapis.com/auth/userinfo.profile openid"] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] 
[tag "capec/1000/255/153/126"] [tag "PCI/6.5.4"] [hostname "10.233.123.103"] [uri "/accounts/google/login/callback/"] [unique_id "1631218187"] [ref "o99,8v143,116t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase"]ModSecurity: Access denied with code 403 (phase 2). 
Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) 
[file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "••••••••]"] [uri "/accounts/google/login/callback/"] [unique_id "1631218187"] [ref ""]

It's hitting this rule:

coreruleset/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf

Line 107 in cebc7fd

# -=[ OS File Access ]=-

Your Environment

  • CRS version: v3.3.2
  • Paranoia level setting: The default, I think that's 5?
  • ModSecurity version: v3.0.5
  • Web Server and version: nginx, specifically https://kubernetes.github.io/ingress-nginx/
  • Operating System and version: N/A

Confirmation

[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
@azurit
Copy link
Member
azurit commented Sep 28, 2021 •
edited
Loading

Hi @mac-chaffee,
thanks for reporting this! Your 'scope' parameter seems to be invalid, from Google OAuth documentation ( https://developers.google.com/identity/protocols/oauth2/openid-connect#authenticationuriparameters ):

The scope parameter must begin with the openid value and then include the profile value, the email value, or both.
...

In addition to these OpenID-specific scopes, your scope argument can also include other scope values. All scope values must be space-separated. For example, if you wanted per-file access to a user's Google Drive, your scope parameter might be openid profile email https://www.googleapis.com/auth/drive.file.

Can you recheck it?

I will look at the additional parameters.

@mac-chaffee
Copy link
Author
mac-chaffee commented Sep 29, 2021 •
edited
Loading

I think that scope parameter is actually generated by Google themselves. That URL is where my browser gets redirected to after completing the Google login process.

The process goes like this:

  1. User visits mysite.com and clicks "login with google", which takes them to mysite.com/accounts/google/login
  2. User receives a 302 redirect to https://accounts.google.com/o/oauth2/auth?client_id=••••.apps.googleusercontent.com&redirect_uri=https%3A%2F%2Fmysite.com%2Faccounts%2Fgoogle%2Flogin%2Fcallback%2F&scope=openid+profile+email&response_type=code&state=••••&access_type=offline
  3. The user logs into google, which returns a 302 redirect to the URL that gets blocked.

We do give Google the start of the URL in the GCP console (/accounts/google/login/callback/) but I think they add the other stuff. Maybe there's a specific sequence of params we pass in the original URL that causes the order to get mixed up? Not sure myself, I'll keep digging on my side.

@azurit azurit self-assigned this Oct 4, 2021
@azurit
Copy link
Member
azurit commented Oct 5, 2021 •
edited
Loading

Can you try with this regex?
^(?:email|profile|openid)(?: email| profile| openid| https://www\.googleapis\.com/auth/userinfo\.(?:email|profile|openid))+$

@azurit azurit mentioned this issue Oct 6, 2021
Closed
@fzipi
Copy link
Member
fzipi commented Oct 14, 2021

Hi @mac-chaffee! Were you able to test with the suggestion from @azurit ?

That way we can push the fix with confidence it is working for your case.

@mac-chaffee
Copy link
Author

Sorry, I typed up a response and forget to hit "send" 🤦‍♂️

Yes, the regex matches my oauth URLs. However, I'm suspicious of the effectiveness of trying to detect google oauth requests from URL parameters alone, especially since if we do think we've detected google oauth, all OS file access is disabled.

Is it not possible to strictly disable checks for the ".profile" file if we think we detect google oauth? Could that be accomplished by "rewriting this as a plugin" as @azurit suggested? That sounds ideal to me

@azurit
Copy link
Member
azurit commented Oct 14, 2021

Is it not possible to strictly disable checks for the ".profile" file if we think we detect google oauth?

No but it would be possible to disable checks only for scope argument.

@azurit
Copy link
Member
azurit commented Oct 16, 2021

See #2232.

@dune73 dune73 mentioned this issue Nov 15, 2021
Closed
@dune73
Copy link
Member
dune73 commented Nov 15, 2021

@azurit, thank you for the proposal in #2232. I think we can close this in favor of said feature request that takes a holistic approach to this surprisingly diverse problem.

@dune73
Copy link
Member
dune73 commented Nov 15, 2021

Thanks @mac-chaffee

@azurit
Copy link
Member
azurit commented Jan 27, 2022 •
edited
Loading

@mac-chaffee Can you look at this? It's a replacement for current Google OAuth2 support (we are moving it from CRS core rules into plugins). Thank you!

https://github.com/coreruleset/google-oauth2-plugin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@azurit azurit

Labels
➕ False Positive
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fixing Google OAuth2 detection
4 participants
@dune73 @azurit @fzipi @mac-chaffee
0