I've got an app that uses antiforgerytoken to secure all forms. the app is hosted on a web site that has the http binding set to the 8080 abd the https set to the 443 (default https port). Until now, I made sure that all the requests were made through https (The MVC app was using the required https filter, web config had the cookies entry requiressl set to true and owin had the auth cookies also set to https).
Recently, we had to change things because now we've got a firewall which handles the https requests for us. it will always serve the response through https to the final client, but I had change my app so that it could be called through http.
I've removed the required https filter, the required ssl for the cookies from the config and changed the owin auth cookies settings, and thought everything would be ok. Unfortunately, that didn't happen and I've started getting the anti forgery token cookie missing exception during validation. Now, the thing is that everything works out if I use https, but it will break if i change to http (which is in port 8080).
I've ended up changing the anti forgery configuration settings from within the global asax, but I'm not able to find a good explanation for the previous problem. in other words, why does the https access work without any problems but the http access ends up throwing an exception saying it can't find the anti forgery cookie...
any ideas?
Thanks,
Luís
More likely than not, you're using secure cookies (cookies sent with the Secure tag). These will only ever survive on HTTPS connections. As soon as SSL is dropped, so are any secure cookies. You could turn it off, but that actually opens up an attack vector on your users, allowing their cookies to be exposed in plain text through protocol-switching.
The best thing you could do is keep it secure all the way. Just because SSL is being provided by the firewall, doesn't mean you can't implement SSL on your site as well. The only difference is that you would need a self-signed cert, since obviously the external domain will not apply. Other than that there should be no problem proxying to a secure site internally, rather than an unsecure one.
Related
I'm using Oracle Application Express 11g.
To secure RESTful services I want to create Third Party Authentication for it.
According to this article : http://www.oracle.com/technetwork/developer-tools/rest-data-services/documentation/listener-dev-guide-1979546.html
In order to register my third party user I need to access this url : https://server:port/ords/resteasy/ui/oauth2/clients/ as I don't have SSL every time I face this error(entring the url in http) :
403-Forbidden
This resource must be accessed over HTTPS only
The Question is : how can I disable "security verify SSL" in apex, in order that I never face this error again.
Note that there is no error like this in other pages because I'm not forced to use https, and I'm receiving this error entring the url in http.
https://docs.oracle.com/cd/E37099_01/doc.20/e25066/install.htm#AELIG7183
1.4.5 Using OAuth2 in Non HTTPS Environments
RESTful Services can be protected with the OAuth2 protocol to control access to nonpublic data. To prevent data snooping, OAuth2 requires all requests involved in the OAuth2 authentication process to be transported using HTTPS. The default behavior of Oracle REST Data Services is to verify that all OAuth2 related requests have been received using HTTPS. It will refuse to service any such requests received over HTTP, returning an HTTP status code of 403 Forbidden.
This default behavior can be disabled in environments where HTTPS is not available as follows:
Locate the folder where the Oracle REST Data Services configuration is stored.
Edit the file named defaults.xml.
Add the following setting to the end of this file just before the </properties> tag.
<entry key="security.verifySSL">false</entry>
Save the file.
Restart Oracle REST Data Services if it is running.
Note that it is only appropriate to use this setting in development or test environments. It is never appropriate to use this setting in production environments because it will result in user credentials being passed in clear text.
We are currently using AWS ELB -> Apache in front of our Tomcat instance running Grails. We use Apache to redirect http requests to https requests. This works fine for us on our regular site. The issue arrives when trying to embed our site within an iframe on Chrome. Chrome does not like an https site redirecting to an http page (even if that page subsequently redirects to https). The reason this happens is that to Spring Security it looks like we're on http because we're behind a load balancer. Here is the network ping pong from Developer Tools:
Here is the problem when putting that same page within an iframe on Chrome.
We have found many solutions that will allow the Spring Security Grails plugin to redirect http requests to https request for certain URL patterns. Here and here are two of these examples. We have already solved this issue by having Apache intercepting http requests and redirecting to https.
The issue is that Chrome won't even make the http request within the iframe. We need an ability to tell Spring Security that even though the saved request you receive is using http, we need you to change that to https once you complete the authentication.
One solution we thought may work was changing to a relative URL using contextRelative instead of the absolute URL, which Spring Security views as http because of the ELB proxy. This post seemed to suggest the same, but the solution also did not change the URL generated when changing contextRelative to "true".
How can we tell the Grails Spring Security plugin to always either format the URLs as relative or force them to an https scheme so that we can run the application within an iframe in Chrome?
If you want to modify the SavedRequest then you can implement your own SavedRequestAwareAuthenticationSuccessHandler that will override the protocol when it pulls the saved request out of the cache and force it to be https.
I'm implementing a simple load balancer - it's an http listener which parses incoming requests from browser and routes them to appropriate ASP.NET application. It listens on a certain port (8801) and when routing it preserves the original URI and changes only port number, e.g. https://machine.domain.com:8801/testsite/Default.aspx could be routed to https://machine.domain.com:8811/testsite/Default.aspx
With no security routing works just fine. The problem emerges when I try to apply WIF federation to the ASP.NET apps. I use ADFS 2.0. Here are two scenarios I tried:
scenario 1
relying party's WS-Federation passive endpoint is set to ASP.NET app URI
When load balancer URI is accessed through browser, load balancer routes to the ASP.NET app and the page gets loaded, however, the RequestSecurityTokenResponse from STS is redirected directly to the ASP.NET app (not the load balancer), according to the passive endpoint set up. So it works but since I want the entire communication towards ASP.NET app to be handled through the load balancer, this scenario doesn't meet my requirement.
scenario 2
relying party's WS-Federation passive endpoint is set to load balancer URI
When load balancer URI is accessed through browser, load balancer routes to the ASP.NET app, which returns Unauthorized response, browser redirects to STS, RequestSecurityTokenResponse is redirected back to the load balancer, but when further routed to the ASP.NET app, I get a response of 401 - Unauthorized: Access is denied due to invalid credentials. That's due to the URI mismatch I believe, as the saml token is issued for load balancer URI. I tried various combinations of audience uris and realms, but no success.
So my question is whether there exists a workaround that would enable load balancer handle all necessary federation communication, as my ASP.NET apps can only be accessed from the load balancer.
I hope I explained my problem clearly enough.
Help much appreciated
Thanks
Eventually the problem was somewhere else. What my load balancer actually does is to transform an incoming HttpListenerRequest to a new HttpWebRequest, which is then forwarded to the appropriate ASP.NET app. However, I didn't disable the auto redirect on the forwarded request so there were happening redirections from ASP.NET app to ADFS.
This code did the magic:
HttpWebRequest.AllowAutoRedirect = false;
In your relying party application web.config, can you confirm that your federatedAuthentication section looks something like this (the realm below should have your NLB port specified):
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true" issuer="https://mysts.com/v2/wsfederation" realm="https://machine.domain.com:8801/testsite/Default.aspx" requireHttps="false" />
<cookieHandler requireSsl="false" />
</federatedAuthentication>
Also, another problem you should be aware of is the session cookie. WIF uses DPAPI by default to encrypt it, so you'll have to use RsaEncryptionCookieTransform instead. The same problem problem exists when using WIF in Azure. Here's an article that demonstrates how this is done:
http://msdn.microsoft.com/en-us/library/windowsazure/hh289318.aspx
I'm getting ready to have an SSL cert installed on my hosting.
It is my understanding that (and correct me if I'm wrong...):
Once the hosting guys install the cert, I will be able to browse my site on Http or Https (nothing will stop me from continuing to use Http)?
The only thing I need to do, is add logic (in the case of MVC, Controller attributes/filters) to force certain pages, of my choosing, to redirect to Https (for instance, adding a [RequiresHttps] attribute sparingly).
Do I have to worry about doing anything extra with these things to make sure I'm using SSL properly? I'm not sure if I need to change something with logic having to do with:
Cookies
PayPal Express integration
Also, I plan on adding [RequiresHttps] only on the shopping cart, checkout, login, account, and administration pages. I wish to leave my product browsing/shopping pages on Http since I heard there is more overhead for using Https. Is this normal/acceptable/ok?
One more question... I know ASP.NET stores some login information in the form of an Auth cookie. It is okay that a user logs in within an Https page, but then can go back and browse in an Http page? I'm wondering if that creates a security weakness since the user is logged in and browsing in Http again. Does that ruin the point of using SSL?
I'm kind of a newb at this... so help would be appreciated.
Starting with your questions, on one, (1) yes nothing will stop you to use for the same pages http ether https.
and (2) Yes you need to add your logic on what page will be show only as https and what as http. If some one wondering, why not show all as https the reason is the speed, when you send them as https the page are bigger and the encode/decode is take a little bit more, so if you do not need https, just switch it to http.
Switching Between HTTP and HTTPS Automatically is a very good code to use for the implementation of switching logic fast and easy.
Cookies
When the cookie have to do with the credential of the user then you need to force it to be transmitted only with secure page. What this mean, mean that if you set a cookie with https, this cookie is NOT transmitted on non secure page, so is stay secure and a man in the middle can not steal it. The tip here is that this cookie can not be read on http pages - so you can know that the user is A, or B only on secure page.
Cart - Products
Yes this is normal : to leave the products and the cart on unsecured connection because the information is not so special. You start the https page when you be on user real data, like name, email, address etc.
Auth cookie
If you set it as secure only, then this cookies not show/read/exist on unsecured page. It is an issue if you not make it secure only.
Response.Cookies[s].Secure = true;
Few more words
What we do with secure and non secure page is that we actually split the user data in two parts. One that is secure and one that is not. So we use actually two cookies, one secure and one not secure.
The not secure cookie is for example the one that connect all the products on the cart, or maybe the history of the user (what products see) This is also that we do not actually care if some one get it because even a proxy can see from the url the user history, or what user see.
The secure cookie is the authentication, that keep some critical information for the user. So the non secure cookie is with the user everywhere on the pages, the secure is only on check out, on logged in, etc.
Related
MSDN, How To: Protect Forms Authentication in ASP.NET 2.0
Setting up SSL page only on login page
Can some hacker steal the cookie from a user and login with that name on a web site?
1) Yes, you are right.
2) Yes. You can optionally handle HTTP 403.4 code (SSL required) more gracefully, by automatically redirecting the client to the HTTPS version of the page.
As for authentication cookies, I've found this MSDN article for you. Basically, you can set up your website (and the client's browser) to only transmit authentication cookie via HTTPS. This way it won't be subject to network snooping over unencrypted channel.
Of course, this is only possible if all of your [Authorize] actions are HTTPS-only.
I'm an old hand at C but a raw newbie at Java/Tomcat.
I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.
I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.
But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.
Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?
Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?
I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.
thanks for any help,
Steven.
It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.
Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.
It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.
This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).