I am trying to configure a LinkedIn application for a multi tenant site. I will have 20+ tenants using the same application and the number is going to increase every time.
As per Linkedin API documentation (https://developer.linkedin.com/docs/oauth2) we need to ensure following points
We strongly recommend using HTTPS whenever possible
URLs must be
absolute (e.g. "https://example.com/auth/callback", not
"/auth/callback")
URL arguments are ignored (i.e.
https://example.com/?id=1 is the same as https://example.com/)
URLs
cannot include #'s (i.e.
"https://example.com/auth/callback#linkedin" is invalid)
Can i configure redirect url as https://*.mysite.com/auth/linkedin/callback instead of specifying url of each tenant separately.
You cannot do a subdomain based wild card mapping as the IP should know the RP.
You can change the logic after you get the authorization callback, so you set the cookie and then you will have to redirect the user back to the tenant URL instead of the base URL.
Anyway, after successful authorization, you will be redirecting the user to an action, just figure out the subdomaina and the construct the URL and do the redirection
HTH
EDIT
Since the use of the URL or other approaches seem to be a hack, can you please try to have a facade like application (or Gateway like one) that has a URL that is registered in linkedin and then on receiving the response, it can use a state or other factor to redirect to the tenant URL. This can use a 302 and it will be invisible unless the user is on a very slow network. This approach does not require any hack like approach.
Here state can be a function that takes a tenant info and generates a dynamic hash that is stored for tracking and redirection.
Related
ive been doing a stephen grider course and he creates a google oauth client id with authorised js orgins as http://localhost:5000 and authorised redirect URI as http://localhost:5000/* and google accepts it. But when i try the same it throws me an error for redirect URI as Invalid redirect: Cannot contain a wildcard (*). And im not sure without this , further it will cause problems.Any way to solve this. Ive typed http://localhost:5000/ as a temp solution. Kindly suggest.
What ever course you are following must be very old I have been developing with Google for five years a wildcard redirect uri has not been allowed in that time.
Authorized redirect URIs
For use with requests from a web server. This is the path in your application that users are redirected to after they have authenticated with Google. The path will be appended with the authorization code for access. Must have a protocol. Cannot contain URL fragments or relative paths. Cannot be a public IP address.
Redirect uri must be a path to the file you wish to use to handle your authorization.
The redirect URL you configure to the API console must be an exact string match to the redirect URL you use in your app. So for example, http://localhost:5000 does not match http://localhost:5000/ or https:5000//localhost. Thus a wildcard will never work.
Furthermore, it's very unusual for a redirect URL to not have a path component. So something like http://localhost:5000/myoauth is more conventional. That's not to say that an empty path is impossible, simply that it's so unusual that it's more probable you have misunderstood OAuth somewhere.
However, note that you can configure several redirect URLs, so http://local:5000 and https://localhost:5000 and https://myliveservice.com/redirect
I have a route in my application that returns results from an LDAP query. I'm using a privileged account for this as it needs to return information that a regular account can't access.
Is there a way to deny users access to this route if they're not using it via one of the application's views? What I'm trying to prevent is a someone reverse engineering it and building their own app to gain access to the PII.
There is no reliable way to say this request originated from this view vs. this request originated from (e.g.) the command line.
An HTTP URL request doesn't have a verifiable source of origination. There is a "referrer" HTTP header which is intended for saying where the previous request originated, but it is not for security and completely spoofable, and not even always included in the request.
Somehow you'll need to authenticate the request. Don't invent your own way. Use devise or some other tested tool to build an authentication strategy, and figure out how to modify your application to work with existing conventions of HTTP request authentication (secure token, cookie based auth, etc.)
In OAuth 2 when you add your client you give it a redirect url.
e.g.
http://example.com
But when you request authorization for a user, you also pass back a redirect url as part of the request.
e.g.
authorize?response_type=code&client_id=CLIENT_ID&return_url=http%3A%2F%2Fexample.com%2Fsecure%2F&state=STATE
My question is basically, what is the point in storing the redirect url against the client? Is this just for security to make sure you ONLY redirect to the original website and not whatever is passed as part of the request?
In any case what I have found is that the return url parameter sent as part of the request isn't honoured e.g. http://example.com/secure and the redirect url saved against the client is always used... and therefore you don't get redirected to your original request but just the home page.
What should happen? And why do we have the return url twice?
Should it not just be the domain stored against the client and then the return url passed back is used and then the domain compared for security?
This is indeed a security measure so that responses are only sent to URLs that have explicitly been associated with a client at registration/administration time.
The client may register multiple Redirect URIs and in that case it is useful to use the redirect_uri query parameter in the request to indicate to which one of the registred values the server needs to send the response. In case there's only one registered value, the redirect_uri query parameter may be omitted from the request.
This mechanism secures against phishing attacks where an attacker phishes the user in to clicking a link that contains a crafted redirect_uri parameter that points to a domain/server that the attacker controls.
The spec allows indeed for registration of a pattern that can be used to match against the redirect_uri value in the request, so e.g. a domain wide policy can be configured. This is an option that is implementation specific. Note that in that case you need to be sure that all possible URLs/paths on the domain are in fact controlled by the client owner and noone else (e.g. that excludes pages that load content from foreign domains, or potential dangerous wiki/forum pages). Since that is pretty hard in real life, the recommended/default matching is very strict.
I have an HTTPS post coming in via a secure form. Without going into lengthy explanation: I need to call an action within the same controller that accepts two tokens passed as parameters. When I run Fiddler, I see that that method is being called with the parameters in the URL. My question is: Does this pose a security risk? Is there a more secure way of redirecting within the same controller?
Yes, it poses a security risk, but it is easily mitigated by simply validating that the urls you are redirecting to are within the same domain as your source destination.
In fact, this is on the OWASP top 10.
A10 - Unvalidated Redirects and Forwards
EDIT:
I just realized that I missed the "ToAction" part of the question, so no.. It's not really possible to redirect outside of the site with RedirectToAction, so there isn't a worry for that. However, if you are using direct user input to feed into your RedirectToAction (and that includes accepting post data that you generate in a different page) then it's possible that an attacker could redirect to a method you did not anticipate. However, this is no different from a user simply trying random URL's and hitting one, or knowing a url and going to it manually. You need to have authorization in place to prevent access to URL's that the user does not have authorization to view.
If the original Action is accessed via HTTPS then RedirectToAction will redirect to a relative URL on the same domain using the same protocol.
So if your original page is
https://www.example.com/Foo/Bar
and this redirects to the FooBar action with some route parameters:
https://www.example.com/Foo/FooBar/1/2/3
an attacker cannot read the parameters 1/2/3 nor the rest of the URL.
However, the things you should bear in mind are:
The URL parameters will be logged by default by the browser (history), your server, by corporate proxy servers and possibly by other devices on your network by default.
If the user follows any links from your page to other https URLs, the referer HTTP header will contain your page address including parameters. Modern browsers will not send the referer header with http links though.
If there are any other https resources on your page this will cause the browser to send the referer header with the request.
For these reasons, if your parameters (1/2/3) are private, then you may wish to POST this data to the target page rather than use RedirectToAction (which results in a GET).
Note that you should be validating that the current user has access to the resources that 1/2/3 refers to (e.g. if the parameters were an order ID, you should check that the user identified by their auth cookies allow them to see the order referenced). Keeping 1/2/3 private are only beneficial if the parameters are themselves sensitive (e.g. a social security number).
Note that the OWASP Top 10 vulnerability, "A10 - Unvalidated Redirects and Forwards" does not apply here as RedirectToAction can only redirect to another action. If the other action redirects to a user set URL, then the vulnerability would lie there instead.
We're developing an application that hosts each user account under their own subdomain. Separate users may access their application through a domain such as usera.myapp.com and userb.myapp.com.
To enhance security between application accounts, the session cookies are scoped to the subdomain of the account (ex. usera.myapp.com instead of .myapp.com). This seems to pose a problem with Google's OAuth2 implementation. Since Google OAuth will only allow you redirect back to the set redirect_uri in their settings, we cannot redirect the user back to their custom subdomain after authorizing our app. We're forced to redirect them back a single generic subdomain such as oauth.myapp.com.
Once they're redirected, we no longer have access to the session (sessions are scoped to a different subdomain now). Since we no longer have access to the session, we cannot check the CSRF token we set to the "state" parameter when requesting the OAuth token. Most other implementations of OAuth2 will allow us to redirect back to a wildcard subdomain, so this isn't an issue.
Now we are left with 2 possible solutions to fix this issue...
Skip checking the CSRF token in the "state" parameter, which opens us up to clikjacking attacks. Or...
Open up our session cookies to use the entire domain, instead of scoping them to the the account subdomain. This opens it's own can of worms and security issues, but it is something that we can deal with.
Option #2 seems like the lesser of the two evils, but I'd like some input before we proceed with doing that.
Thoughts?
Hm, might it be possible to construct the state value by hashing up a bunch of pieces of state so you don't have to retrieve the desired value from a cookie? E.g. hash up the subdomain, the time of day, and some internal system state from your app. Then you can recompute the value you expect when they show up at oauth.myapp.com, no need to fetch it from the session. Should be effective against clickjacking I’d think.