I have an application where I want to force HTTPS for all requests except one. For that one URL I don't care if it is HTTP/HTTPS.
I currently have the following security config
http.requiresChannel()
.antMatchers("/actuator/health").requiresInsecure()
.antMatchers("/*").requiresSecure();
The issue is that this requires actuators health endpoint to be accessed on HTTPs, but I don't really care what protocol is used (I would prefer both).
When you configure authorization you have permitAll, which doesn't care if you are authenticated or not, why is the not a similar mechanism for channel security.
Does anyone know how to exclude a URL from the channel security mechanism.
you could use a regex-matcher that matches all urls except the one you want to exclude like:
http...
.and()
.requiresChannel()
.regexMatchers("^((?!/actuator/health).)*$").requiresSecure();`
note I'am not a regex-expert (possibly there is improvement needed)
I think you could try something like this:
http.requiresChannel()
.antMatchers("/actuator/health").requires(ChannelDecisionManagerImpl.ANY_CHANNEL)
.anyRequest().requiresSecure();
Related
I am working on Asp.Net MVC 5. When i click a link (placed in another website) I navigate to UserDetails.cshtml page. Basically that 3rd party site is passing the UserName & Password to my site & using that I authorize & display further user info.
It's fine but the Url is looking like this
localhost:8080//Admin/UserDetails/UserName/PWD.
I don't want to show the UserName & Password in URL i.e URL should look something like :
localhost:8080//Admin/UserDetails/
One possible solution could be rewrite the URL in IIS (http://www.hanselman.com/blog/ASPNETMVCAndTheNewIIS7RewriteModule.aspx)
But I believe there is an easier way to handle this by using the routing mechanism of MVC.
Please help me to figure out the same.
EDIT :
As many of you are confused why I am not doing a Form Post here, let me re-frame my question. I have no control over the third party application, so I cant request them to do a form Post to my MVC application. Again the 3rd party application is a Oracle Reporting application (OBI), so doing a POST from that application might not be feasible too...
Let me reverse engineer your requirements from your question:
I want to have an URI that when invoked will give access to a secured section of my website. This URI must be clicked by visitors of a third-party site, whom I give that URI to. I want to hide the credentials from the URI.
You cannot do this, the requirements are conflicting. You cannot hand out URIs that will authenticate anyone who fires a request to that URI.
You could do something with a token (like http://your-site/auth/$token), but then still, anyone with access to that URI can use it to authenticate themselves, or simply put it up on their own website.
If you have data you want to expose to a third-party site, let that site perform an HTTP request (with tokens, usernames, headers or whatever you want to use to authenticate) in the background to your site, and display the response in their site. Then the visitor won't see that traffic, can't share the URI and all will be secure.
No. No. NO. Like seriously, NO. Any sensitive information should be sent via a post body over a secure connection (HTTPS). You can't "hide" information in a GET request, because it's all part of the URI, or the location of a particular resource. If you remove a portion, it's an entirely different location.
UPDATE
I find it extremely hard to believe that any third-party application that needs to authenticate via HTTP and isn't designed by a chimp with a typewriter, wouldn't support a secure method to do so, especially if it's an Oracle application. I'm not familiar with this particular app, but, and no offense meant here, but I would more easily believe that you've missed something in the documentation or simply haven't found the right way to do it yet before I'd believe you have to send clear-text credentials over GET.
Regardless, as I said previously, there's no way to hide information in a GET request. All data in a GET is part of the URL, and therefore is plainly visible in the browser location bar or whatever. Unfortunately, I have no advice for you other than to look closer at the documentation, even reach out to Oracle if you have to. Whether by post or something like OAuth, there almost has to be another way.
I have an ajax call used to start the 'forgot password' process from an SPA to a controller in the MVC app that looks something like this:
[HttpPost]
public JsonResult ResetPassword(User acct)
{
...
}
I was hoping there was a way to limit this controller to posts only from that page. I could write a custom attribute I suppose, but I was hoping this is a common enough problem that someone has already done that. And yes, I realize falsifying headers to contain spoofed referrer data is possible, but the added layer of security would give me a little more piece of mind. Or does anyone have a suggestion of a better way to accomplish the same thing?
Thanks for the help!
The short answer is that you can't. As noted, you could try to use the referrer header (HttpRequest.Referrer), but it's not reliable for a number of reasons:
It's not a required header,
You're depending on the rendering agent (e.g, the client browser) to set it [honestly], and
It can be changed. For instance, if the request is proxied, it could be set to the proxy URL.
HttpRequest.UserHostAddress is probably somewhat more reliable. But again, you can't really depend on it: it's the IP address the request came from, but again, if the request is proxied or coming through a firewall, you're likely going to get the proxy address, not the actual client IP address.
The most reliable way would be to implement client authentication via a certificate:
http://www.iis.net/configreference/system.webserver/security/authentication/clientcertificatemappingauthentication
http://www.iis.net/configreference/system.webserver/security/authentication/iisclientcertificatemappingauthentication
Though it's a bit of a hassle: the client has to provide the correct cert as part of the request and the server has to have the matching cert as well.
You could check the referer header in HTTP. That gives you the page the request was made from.
Yes, you have to be mindful that this is not secure, as any HTTP header can easily be spoofed.
I think you can use anti forgery token
http://kamranicus.com/blog/posts/70/protip-using-anti-forgery-token-with-aspnet-web-ap/
The Dropbox OAuth 2 requires me to set a return URL. Is it possible to implement the OAuth 2 flow with a dynamic return URL?
Background on why I need the return_url to be dynamic: The flow works great if the integration is through a website, however I am working on a product which is managed through a web console, and typically users will access it using the private IP on the unit. This IP is something I cannot know in advance.
Possible Solutions if dynamic return URLs aren't possible:
I host a cloud service of some sort to act as a broker --- the broker is a fixed URL and I relay back the access code to the device.
Use OAuth 1, which doesn't seem to have this restriction.
Florent's comment is correct, this isn't currently possible, as all OAuth 2 redirect URIs are required to be pre-registered as a matter of security. I'll be sure to pass this along as feedback though.
As mentioned though, one thing you may be able to do instead is to use one static redirect URI but encode the necessary information in the 'state' parameter, and decode it as necessary after the redirect back to your app, to handle it as necessary:
https://www.dropbox.com/developers/documentation/http/documentation#oauth2-authorize
Alternatively, you can use OAuth 1, which doesn't require pre-registered redirect URIs. Edit: note that OAuth 1 is only available for API v1, which is now deprecated.
I'm building a grails app, and the default URLMapping provided by grails is /$controller/$action?/$id
I'm concerned about the security aspects of this catch all mapping. On one hand, it's a pain to explicitly list our all of the mappings, but on the other hand it seems like there could be potential security issues, such as forgetting to secure certain mappings.
By explicitly specifying the mappings, we have much tighter control over the URLs. It also lets us making more user friendly URLs (e.g. maybe we could pluralize things like using having a people/john/ url instead of /erson/john.
Are there other concerns with leaving the default mappings? Is there a possibility that we could unintentionally expose the fact that a certain admin page is valid (I'll have to look more into spring security as to how to redirect to a 404 for trying to access admin pages for a non admin user)?
I think you answered yourself. Default url mapping "/$controller/$action?/$id" is easy to use but may be used as hole in the case of bad controllers security implementation.
But probably the best solution is to place security checks even at domains level, so even if for error a user can reach a not authorized controller an exception will block him to do anything with the domains.
I have an ASP MVC 3 website that has a Feedback form and should require SSL.
Now, I have an action called Feedback inside a controller called 'ContactUs' that is responsible for viewing and processing the feedback.
When I used the [RequireHttps] attribute on that action, it works nice and it changes the URL to "https". However, I noticed that all the links inside my page are now pointing to "https"! As if this attribute had forced the routing engine to apply the same to all links!!!
Of course, the SSL is only required for this single action and all the rest need to have normal http.
Could anyone tell me how to solve this?
In your case [RequireHttp] attribute might be OK if you clear out the login cookie - or you'll be sending it in clear-text across the wire. It might be more work than it's worth to avoid the slight cost of further HTTPS calls. SO is all about recycling questions and other users reading your question might think it's OK to drop down to HTTP after login, when it's usually the wrong thing to do.
The [RequireHttps] attribute can be used on a controller type or action method to say "this can be accessed only via SSL." Non-SSL requests to the controller or action will be redirected to the SSL version (if an HTTP GET) or rejected (if an HTTP POST). You can override the RequireHttpsAttribute and change this behavior if you wish. There's no [RequireHttp] attribute built-in that does the opposite, but you could easily make your own if you desired.
There are also overloads of Html.ActionLink() which take a protocol parameter; you can explicitly specify "http" or "https" as the protocol. Here's the MSDN documentation on one such overload. If you don't specify a protocol or if you call an overload which doesn't have a protocol parameter, it's assumed you wanted the link to have the same protocol as the current request.
The reason we don't have a [RequireHttp] attribute in MVC is that there’s not really much benefit to it. It’s not as interesting as [RequireHttps], and it encourages users to do the wrong thing. For example, many web sites log in via SSL and redirect back to HTTP after you’re logged in, which is absolutely the wrong thing to do. Your login cookie is just as secret as your username + password, and now you’re sending it in clear-text across the wire. Besides, you’ve already taken the time to perform the handshake and secure the channel (which is the bulk of what makes HTTPS slower than HTTP) before the MVC pipeline is run, so [RequireHttp] won’t make the current request or future requests much faster.
You can create another custom filter attribute to move back to http. Try solution from this question...
Why once SSL is enabled with [RequireHttps] at action level, it remains enabled forever?