I have my e-commerce website and dealing with a 3rd party payment vendor integration. I send them a URL and they're returning a POST request to it. The problem is I'm receiving 403-bad or Missing CSRF Token error.
The incoming request is as follows:
Request URL:https://mavi.local:9002/checkout/callback/secure3d?CSRFToken=425cc3ee-df74-482a-955b-c7836abff410&responseCode=0000&token=D7ED3EBA21864253AD7AA33AABB492C7FA90DDEBD7AD448D1210EF85814E077505BC8E58E1F29AC2153E600678E6545A2D87FAACF516AC3249F7D8572EA767835C89F1E370C01532F0DCCABF8ACCC7F215AE838E9B917204F1C362140E6F5E87
Request Method:POST
Status Code:403 Forbidden
Remote Address:127.0.0.1:9002
Referrer Policy:no-referrer-when-downgrade
And the initiator is:
test.masterpassturkiye.com/RedirectServer/MMIUIMasterPass_V2/s3d/bank/success?RRN=500007047967:7
I'm trying to add this url as allowed Cross Origin request in my Spring configuration.
I have tried 2 options.
Updating csrf.allowed.url.patterns setting in project.properties as follows:
csrf.allowed.url.patterns=/.*callback|.masterpass|[^/]+(/[^?])+(sop/response)$,/[^/]+(/[^?])+(merchant_callback)$,/[^/]+(/[^?])+(hop/response)$,/[^/]+(/[^?])+(language)$,/[^/]+(/[^?])+(currency)$
This regex mathces with the url but not the whole URL, I think it might be a problem, yet I'm not sure.
Inserted below item into my spring-mvc-config.xml
<util:list id="csrfAllowedUrlPatternsList" value-type="java.lang.String" >
<value>.*masterpass</value>
</util:list>
I adopted this solution from this blog post
Yet the problem with the 403 error still continues. What might be the possible problem with my configurations? Any help or idea will be great help.
I believe that your value in spring-mvc-config.xml is wrong.
Please try with /checkout/callback/secure3d since this is the Hybris URL which handles the POST request and which should not ask for a CSRF token.
To make everything more clear, your spring-mvc-config.xml should contain this:
<util:list id="csrfAllowedUrlPatternsList" value-type="java.lang.String" >
<value>/checkout/callback/secure3d</value>
</util:list>
I believe that this is valid for the csrf.allowed.url.patterns as well.
The regex should apply to the call back URL (i.e /checkout/callback/secure3d) instead of the initiator.
Related
I'm currently developing a little algorithm to solve the VRP. I herefore use the HERE Matrix Routing API to identify the actual travel times. I just came across the issue, that the retrieved status url after submitting the matrix seems to not accept the API key authorization. Here a little exapmle:
After submitting my matrix, I try to access the status of my calculation via the status url as described in the documentation:
https://matrix.router.hereapi.com/v8/matrix/{matrixId}/status?apiKey={apiKey}
as well as with the returned status url after submitting the request (which is basically the above URL prefilled and with resolved forwarding):
https://aws-eu-west-1.matrix.router.hereapi.com/v8/matrix/{matrixId}/status?apiKey={apiKey}
From my understanding and the way how it's documented, I expect this to be working. Instead, I'm receiving an error code 401, Unauthorized: No credentials found
My request succeeds, when I'm deleting the /status after the matrixId. Is this the expected behaviour or did I reveal a little bug?
Thanks for your help!
BR, Difreg
This is unfortunately due to a combination of how the service operates, and how some client libraries are configured to automatically follow HTTP redirects, like Python requests.
I answered a similar question a few days ago, and you can see the answer here.
Hopefully that helps you figure it out, but if it doesn't, feel free to ask again here.
Suddenly linkedin oauth2 stopped working! As per instructions found here:
https://developer.linkedin.com/docs/oauth2
When invoking this:
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=75jdo0an3ktnbx&redirect_uri=https://app.myapp.com/account/linkedin_login&state=fregfdgfasd&scope=r_basicprofile%20r_emailaddress
Instead of a valid response I get a 400 error:
LinkedIn
Invalid HTTP Request
Could not process this client request HTTP method request for URL. Please double-check the URL (address) you used, or contact us if you feel you have reached this page in error.
I am experiencing the same problem using Chrome, but not with Edge or Firefox. Contacted LI, reply was we are working on it, no estimate of when we will solve it. The new profile update seems to be botched in Chrome, OK with Edge and still not updated to the new look if using Firefox.
Linkedin has problems far deeper than poor coding, they forgot the meaning of being social in networking, the site is becoming a pile of stale resumes, non-existent debates and bad quality networking.
I am not OAuth fluent enough to tell you why, but they have 2 different systems: oAuth and oAuth legacy.
I personaly couldn't find a way to retrieve a valid token from OAuth but yes from OAuth legacy. The main difference is the URL and the authorization window.
You are actually using : https://www.linkedin.com/oauth/v2 for you api calls.
OAuth legacy is using https://www.linkedin.com/uas/oauth2.
The whole process is the same so you won't have to change your code, just the URL.
see OAuth legacy doc: linkedin.com/docs/oauth2-legacy
The bad side is the authorization window, the user has to literaly login (email + password) before clicking on the 'Authorized' button and being redirected to your callback URL.
I am agree, this website has something buggy. When visited from France (browser language set to FR-fr and an IP geolocalised in France), their whole interface is written in Dutch ...
Anyway, i hope it helps
I m creating a code in which based on query string the URL is changing when no values are supplied in URL everything is working fine but as i supply values to URL it shows Error HTTP Error 403.0 - ModSecurity Action
Kindly suggest some solution
also the same is working fine in local problem occurs when i upload my webpage to server
I know this is an old thread, but posting the answer so that it can be helpful for others. ModSecurity is an open source, cross-platform web application firewall (WAF) module.
https://modsecurity.org/about.html
So whenever you see the 403 (ModSecurity Action), this means that the mod security firewall has blocked the request. The probable cause could be vulnerable data present in the posted data, or the it could be because of the URL posted as parameter or it could be JavaScript.
In above case, the ModSecurity might have deemed the input as SQL Injection attack and hence may have blocked it. If you look into the logs of the firewall it may give you the detailed explanation.
In my case, I was passing URL as query parameter in the request hence it was returning 403.
I have been trying to learn OAuth (1.0) and have been testing my code by trying to access my contacts on Google. This is easy because I don't have to set up a friend/consumer relationship (Google just allows anonymous/anonymous for the consumer token) and because Google has the OAuth Playground to help me along.
So I set my code up as follows to go to
Request Token: https://www.google.com/accounts/OAuthGetRequestToken?scope=https%3A%2F%2Fwww.google.com%2Fm8%2Ffeeds%2F
Authorized Request Token: https://www.google.com/accounts/OAuthAuthorizeToken
Access Token: https://www.google.com/accounts/OAuthGetAccessToken
Everything seemed to be going well - I got the request token alright, authorized it fine, and was able to get an access token. I then tried to make a request to https://www.google.com/m8/feeds/contacts/default/full/
Only problem was, I kept getting this error: "401: AuthSub token has wrong scope"
I was confused by this because when I made the same request with the same consumer information in the OAuth Playground ( http://googlecodesamples.com/oauth_playground/index.php ) everything would work out alright.
Eventually, I found the following question: HTTP/1.1 401 Token invalid - AuthSub token has wrong scope
The top answer led me to my solution - there was code in one of the JARs I was using that was written to always set the port to 443 for https or 80 for http. When I stepped through my code and changed the port to -1, my request worked out fine and I was able to get the information I wanted.
Unfortunately, I'm not able to change the code in the JAR file, so I'm going to have to fix things on my end. In the answer to that question, 'Jonathan' said:
Another workaround would be to include the :443 in the token scope; it just has to match
I tried changing my request token query string to ?scope=https%3A%2F%2Fwww.google.com **%3A443** %2Fm8%2Ffeeds%2F and Google just refused to give me a request token - it gave me a 400 error saying Invalid scope: https://www.google.com:443/m8/feeds/. Changing https to http didn't do anything. How would I do what Jonathan (who hasn't been online in almost a year) suggested?
The fact that Google's auth scopes are URLs is basically academic -- they aren't actually serving anything useful (see for yourself), so adding a port just confuses Google. So Jonathan was incorrect in his suggestion.
The only reason they even look like URLs is so that they could be expected to be universally unique (even this is only arguably true).
So don't put the :443 in your auth scope.
Say I have a website that allows anyone to log in through oauth or similar, but only allows certain uses to create or modify content. Should they somehow make a request for page for creating a new post, I'll do a check and redirect them if they don't have the appropriate permissions.
It is considered acceptable to redirect to the "403 Error" page in this situation? There was no actual HTTP response with a 403 status code, there was no database- or server- level query that was failed - just my business logic. Am I misappropriating the idea of HTTP status codes if I serve an error 403 page with a specific explanatory message?
You are free to do so, but I think if you want to expose an API you would use an actual 403 response because they carry meaning that will be nicely handled by the client.
If you want to display a page to the client and will be using redirect, you will lose this meaning of the "403".
Isn't it better to just redirect them to an explanation page without including the "403" code. Or better yet, redirect them to a more helpful place, like the sign up page if that is what they have to do to make a post, or back to the original page with a floating message.
We want to help the user get closer to their goals instead of confusing them with technical error codes.
There is often a lot of discussion about this very topic and it comes down to the following choices:
a 5xx? Of course not. This is not a server error.
a 400? Not really, it wasn't a malformed request.
a 401? Probably not, 401 is generally for authorization in general, not application-level permissions. If your user has already logged in but has the wrong role, and you want to let the user know, then use something else.
a 404? Perhaps, as the server can't find the resource for this particular user, but if you want to tell the user "well such a resource is available but you can't have it because you lack permissions" then go with something else.
a 403? Actually, this one makes a lot of sense. Here is the definition from the RFC
403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
In your question you mention your intention to redirect the user. If you are making a RESTFUL web service then just return the 403. If you are doing an entire web app, you can control the 403 and redirect....