rules block Google OAuth2 redirect (callback) URLs #1451
Comments
|
User csanders-git commented on date 2019-06-13 20:34:44: Well that is certainly interesting and I think we could easily put forth some exceptions (even a pack for google auth maybe). However, My understanding of the OAuth flow is that you should never really be seeing scopes on your own side. You will generate a request to accounts.google.com (in this case) and that will include, scopes, redirect_uri, state, client-id, etc. After the user logs in and allows access, they will be directed back to the redirect_uri with the auth code (as you showed) and the state. I'm a bit confused why you'd receive back the states -- perhaps i'll dig through their docs, but i'm not sure why google would send the scopes back -- as far as i know that is not per OAuth2 Spec (could be wrong) |
|
User 1raj1 commented on date 2019-06-13 22:44:17: I don't know why Google is sending back the scopes if it shouldn't, but it does. If you search the net for posts about error 403 after Google auth (not all cases caused by mod_security, of course :)) - as I did - you will find multiple examples of actual redirect URLs posted by people, and the scopes are always there. |
|
User csanders-git commented on date 2019-06-13 23:20:43: I'll take a look at the regex in the coming days hopefully - in the mean time, do you need help crafting an exception rule? |
|
User 1raj1 commented on date 2019-06-14 09:39:27: Can this exception rule be placed in .htaccess file? If not, I have to contact the server administrator anyway, who probably can temporarily resolve the issue by replacing ".profile" with "/.profile" in the file containing restricted names list - am I right? |
|
User csanders-git commented on date 2019-06-14 15:33:40: as far as i'm aware it is possible to place these in htaccess files, however we have to be careful to make it a more sweepinng rule -- so for instance, we can remove any variable named scopes from being processed by this rule -- if we wanted to be more specific it would have to be loaded before the rules, which would probably require contactign an admin. |
|
User csanders-git commented on date 2019-06-14 15:33:59: to save me some time, do you have the ID of the rule? |
|
User 1raj1 commented on date 2019-06-15 09:49:19: As I already wrote, I'm not the server admin and I don't have access to configuration or logs, so I can't provide you any more information than I already did. |
|
User csanders-git commented on date 2019-06-17 21:59:20: Thanks for following up with that information. The rule referenced by that file indicates that the following rule (snippet) is at fault This is incorrect for the case at hand as REQUEST_FILENAME does not contain parameters (see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#request_filename), rather it is just the path of the URL /index.html for instance. As a result, we won't be able to do anything further on this without additional detail. Thank you again for your report, and please let me know if you are able to gather any additional information in the future. |
|
User harwoeck commented on date 2019-10-29 20:47:43: Hi csanders-git ! :) I'm currently having the same issue and can provide additional data if you want :) I use ModSecurity v3 with nginx, owasp-modsecurity-crs 3.2 and a When the oauth callback returns from google it is detected as 930-APPLICATION-ATTACK-LFI. Excerpt from my logs: 2019/10/29 20:23:50 [error] 6#6: *5 [client 188.x.x.x] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator
I have also tried to reduce |
|
User selwynorren commented on date 2019-11-15 12:42:55: Hi, So I am having the exact same issue on my side. I am running WAF Comodo rules and it is rule number 210580 that is invoking, Here is my ruleset: Would it be possible to help me tweak these rules or create a specific bypass for them? |
|
User felixarntz commented on date 2020-02-19 19:16:33: Hello there, I've discovered this thread because we have been encountering the same problem in our WordPress plugin that integrates with the Google OAuth flow (google/site-kit-wp#1113). csanders-git I believe that this should be reopened, an indeed an exception for the I have tested this myself, and it is indeed the case. Google's implementation passes the |
|
User rahulbhatu commented on date 2020-03-20 15:36:05: selwynorren If this is still a problem, i can help you bypass this rule, But it is just a workaround not advisable you can comment out .profile from the bl_os_files and reload your webserver this requests will not be scanned for .profile. |
|
@1raj1 @harwoeck @selwynorren @felixarntz @rahulbhatu 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! |
Issue originally created by user 1raj1 on date 2019-06-13 20:15:23.
Link to original issue: SpiderLabs/owasp-modsecurity-crs#1451.
Type of Issue
false positive
Description
I don't have access to server logs, because I'm not an administrator, however the issue is pretty simple and was already described here: https://serverfault.com/questions/932614/apache-issue-with-profile-in-the-url (however without any solution)
I implemented Google OAuth2 authentication on my website. After user authenticates successfully on Google login screen, Google redirects the browser to an URL on my site that looks like this: https://site/somepath/somescript.php?state=#####&code=#####&scope=email+profile+https://www.googleapis.com/auth/userinfo.profile+https://www.googleapis.com/auth/userinfo.email
(https://site/somepath/somescript.php is predefined by me, but all the parameters after "?" are appended by Google and necessary for the authentication to work). However, the request is blocked and I get a 403 error.
The part "userinfo.profile" is what causes the issue - because of presence of the ".profile" string in the URL. If I manually copy the URL and remove the "+https://www.googleapis.com/auth/userinfo.profile" part, then the request gets through (however, there is no way to tell Google to not use that part in the URL).
The particular string "https://www.googleapis.com/auth/userinfo.profile" should be an exception form the general rule that blocks ".profile".
Your Environment
Have no access to version information.
Confirmation
[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
The text was updated successfully, but these errors were encountered: