I'm currently using a Preauthentication with Spring Security through an SSO solution, and was having a problem with #'s in the URL. I noticed if you URL encode the #, the redirect would work correctly if the user was not logged in, so I wrote a filter that would look for URL encoded parameters, and decode them. The problem is, now if you are logged in, it seems like the URL is being decoded, and my filter is never being touched.
This is a really confusing question, but I'll try to explain what I am seeing through how the requests are handled.
Not Logged In:
/%23/some/resource
Redirect to SSO:
SSO Redirects to:
/#/some/resource
This works well.
Logged In:
/%23/some/resource
:
/#/some/resource is the URI passed, so no rewrite needed, verified through debug logging that the URL is being passed through.
/%23/some/resource is returned to browser, 404 is returned.
Where I am getting confused is why it's decoding, then it seems to be re-encoding the URL after the filter-chain (maybe?)
Thanks for any help!
Related
I'm working on a WordPress website: https://samarazakaz.ru/
The client discovered a strange bug. After newly opening a browser the first login always fails, second one succeeds.
I tracked down the issue to a strange cookie with the name RCPC that is being set when the login form is submitted. If the cookie is missing then the login fails regardless of proper credentials.
I searched high and wide for any information about this cookie but could not find anything useful. The only thing remotely resembling my case was on some discussion on a site called https://codeforces.com/ . But nothing on that mentioned anything related to WordPress.
The site has a bare-bones setup with Elementor and my own plugin. And nothing in my code messes with cookies or the login process. I downloaded all website files and search in all files for "RCPC" but found nothing.
The site is behind an Nginx proxy, but I could not find any connection with this cookie and Nginx either.
I noticed that the value of this cookie is constant. So, as a workaround I jerry-rigged my plugin to set this cookie any time when it's not set. But, of course, I'm not very happy with that solution because I don't know if this will just stop working one day.
Update:
I verified that this is coming from the hosting. I renamed the /wp-login.php file and made a request to it, and it didn't return a 404 error but a 200 page with the same redirect code and the header to set the cookie. The hosting is reg.ru .
As far as I can figure this is a counter measure against automated password guessing. Any request (POST, GET, etc) to the /wp-login.php will get the redirect script with the cookie setting header. Only requests containing the correct RCPC cookie will get forwarded.
Upon further testing found that the value of the RCPC cookie is some kind of hash generated from the request's IP address. Because all of our computers got the same one but from other locations its different.
This does not cause any problem if the standard WordPress login form is used because that lives at the /wp-login.php address, so the first GET request will generate the cookie. However, we had a custom login page which didn't access /wp-login.php until the form was submitted.
Based on these discoveries I made a workaround, which is simply adding a one line JS script to the login page which makes a (fetch) request to the /wp-login.php page and simply discards the result. This is enough to set the cookie in the browser so that the form will work at the first try.
Need on hosting disable test-cookie-module
I have configured an OpenID Connection application on OneLogin (not sure the provider matters) with a configured post MFA authentication redirect uri of
http://localhost:4200/LoginResponse.aspx?
The code behind my LoginResponse.aspx page grabs the returned id_token and processes it.
The issue is that after my initial redirect to the MFA login and successful login/MFA validation, the redirect is coming to
http://localhost:4200/LoginResponse.aspx#id_token=12345678987...........
Note the "#" symbol after my .aspx extension. This is corrupting the parameter string that is returned and not allowing me to grab the value of id_token from the Response.
After the redirect comes back, if I simply manually replace the "#" with a "?" and hit enter, my LoginResponse.aspx page loads fine and finds the id_token and processes it with my business logic.
My question is, how can I get the redirect to actually return to "LoginResponse.aspx?" so that I can grab the parameters.
On my OpenID Application I have tried the following options as Redirect URIs
LoginResponse
LoginResponse.aspx
LoginResponse.aspx?
LoginResponse.aspx?action=test
Did that last one to see if I could get around the ? not being there. But that just redirected the page to "LoginResponse.aspx?action=test#id_token=..............." So again, I could not grab the "id_token" variable out of the URL Response/QueryString.
I just cannot figure out how to get rid of this unwanted "#" sign and have a "?" after my .aspx extension.
Any help would be greatly appreciated!
I assume you are using the implicit flow to retrieve the tokens and in this flow you can either get back the tokens in the URL with the #. The # is added to make sure the tokens are not sent back to the server, instead they just stay in the browser. If it was a #, then the secret tokens would be sent back to the server and end up in various logs and creating various security issues.
I don't know how you implemented the client, but in OpenID Connect, if you add this parameter "&response_mode=form_post" to the initial authorization request, then you will get back the token using a POST request instead. just like this picture shows:
PS, I doubt you can get back the tokens using a ? instead of #.
I am using 'omniauth-linkedin-oauth2'.
When I am login with linkedin then I am getting this error
Invalid redirect_uri. This value must match a URL registered with the API Key.
This is my settings:
Went back to LinkedIn developer site (https://www.linkedin.com/secure/developer ) to check my setting again. Everything matches API Key, Secret Key and OAuth 2.0 Redirect URLs.
Searched web looking for some clues. Couldn’t find a one. Crazy issue:
Then I saw that in the URL Owin was appending some extra string to the redirect_uri “signin-linkedin”. When I decoded the URL I saw this http://localhost:54307/signin-linkedin . I took this URL and placed it in the OAuth 2.0 Redirect URLs field in the LinkedIn developer site.
This link is helpful for me
https://naveengopisetty.wordpress.com/2014/09/15/linkedin-oauth-2-0-issue-invalid-redirect_uri-this-value-must-match-a-url-registered-with-the-api-key/
You can just look in url that you are getting that error message on.
eg. if you are using python's social auth the url would look like this:
https://www.linkedin.com/uas/oauth2/authorization?scope=r_basicprofile+r_emailaddress&state=XXXXXX&redirect_uri=http://example.com.au/sa/complete/linkedin-oauth2/&response_type=code&client_id=YYYYYYY
so you would use this part of the above url for the redirect url
http://example.com/sa/complete/linkedin-oauth2/
please check your redirect_url. for my case I see like this.
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=77k93y0w31zaey&redirect_uri=http%3A%2F%2Flocalhost%3A1729%2Fsignin-linkedin&scope=r_basicprofile%2Cr_emailaddress&state=nhAC-nR-CgEwO3XS2ezANhuPBMz-IUmLPJYgGHlZvZ8B1pCfsGBU0PR0dZ5XxE4zbyeI0RLcKByqPLKkgQdqMm4s6DjFYqMCEehYA2iWT9MfioEHjPXGCt2USxUTF0wKBpflCUjG5URVlJa3qI7U3ydFOErZ4Hhnr9SVmKdf1bithYfbOqBx345o8LQLexbddQ687vP6y0szrIyCM6FHip1tCpOY3Hgg5FJQEFH1mCJ_yLunD5vDUN4VVfkQbcjk
for this I add the url for OAuth 2.0 Authorized Redirect URLs:
http://localhost:1729/signin-linkedin
where http://localhost:1729 =base url and
signin-linkedin = the string which add after base url
One more solution is to just verify the client_id you've been using the whole time..because with every update in the list of redirect_uri, the client_id gets updated.
Worth mentioning when one uses libraries to handle oauth: some libraries fail to care about the protocol that is used (or at least require further parametrization). Eg, I gave Linkedin https://example/callback as oauth2 url, but the library sent the request with http://example/callback as parameter.
I had this when trying to authorise from a zurb Reveal modal popup. In my case, the issue was the URL for the page that was being displayed in the popup was not in my OAuth2 Redirect URLs list on the LinkedIn developer site.
That was easy to miss because the page URL from the page in the modal is not the URL that was currently showing in the browser's address bar. Once I added the URL for the page being shown in the pop up it worked.
After spending hours i finally get to the solution. You got an error no issues just check the url and find redirect_uri. Copy and Paste it's value it in your linkedin dev account oauth2 redirect field.
Make sure to add both with and without trailing '/' as redirect url.
http://localhost:8000/oauth/complete/linkedin-oauth2
http://localhost:8000/oauth/complete/linkedin-oauth2/
CAT.NET says there is a cross-site redirection vulnerability in my website.
It says below code is problematic and can cause redirection attack.
this.Response.Redirect(this.Page.Request.Url.ToString());
I believe redirection attack occurs when a user controllable input exists in the URL. But in this case no user input exists in the URL.
Can anyone tell me if this is really a problem or just a false positive?
If this indeed is a problem than why is that and what is the solution?
Cross-site redirection vulnerability happens when there's a parameter added to the request that specifies on what page the user must be redirected after that the action has been performed (usually when using forms authentication).
URL looks like this: www.mysite.com/Logon?returnURL=www.mysite.com/Logon.
The malicious action consist of replacing this parameter with a wrong URL: www.mysite.com/Logon?returnURL=www.hackerSite.com/Logon
It's quite easy to avoid that by checking if the returnURL is local with
if (Url.IsLocalUrl(returnUrl))
In your case it might be a flase positive, but it's always a best practice to check the validity or the redirect URL before redirecting.
We've setup federated security using ThinkTecture server.
When a user wishes to access a particular URL, they get redirected to the Identity Provider Server (IDP), they login, get authenticated.
Then, the IDP server will redirect the user back to the "Redirect URL" specified in the configuration for that Relying Party.
Instead, I want it to be redirected to the originally requested URL.
Is this possible? I've read a little about the wreply parameter, but not sure how I use this and intercept the authentication levels calls on the original web server, before the redirect.
Update
I've realised that my problem is due to my url containing a hash, e.g. http://domain.com/#customer/123 and nothing after the hash is passed into the redirect url within WIF. See my answer below for more details.
It's up to your app to remember context info like this in the wctx param. If you're using WIF in the RP then this should be done automatically.
I figured out what was happening. I am using WIF and as Brock's answer suggested it should be doing everything itself...and it was.
Normally if you request a url like: http://domain.com/page and the 'Redirect To'/ReplyTo setting in ThinkTecture is just http://domain.com/.
Then when WIF calls out to the STS, it takes the path of the requested domain, in this case /path and adds it to the &ru param within the &wctx param. The &wctx param will look like this: rm=0&id=passive&ru=%2fpage.
Then after the STS has authenticated it redirects the user back to the ReplyTo url, http://domain.com with a body parameter of wctx and WIF picks this up and uses the ru param to do another redirect.
The problem is that my requested url was http://domain.com/#page and WIF doesn't include the #page in the ru param. So my ru param was just /, so it kept redirecting to http://domain.com which there was correct (yet incorrect).
Guess I need to set the ru value myself with the full URL... unless there is a better way.