I have a site that has a mix of http and https pages. Under the root of the site, one folder has all the http pages and another has all the https pages. Login is over https and sends the user to the other pages. When a session expires the forms authentication redirects to the Login page but the browser uses http and the user gets a 403 error.
Is there any way to override the session timeout to send it to https?
one way is to configure IIS to redirect http traffic to https
http://support.microsoft.com/kb/839357
one thing to consider with mixed mode like that:
there is a common attack on SSL pages, which is, making a http request (to https resource) in order to obtain the un-encrypted session cookie. This is why you want to configure your session cookie to encrypted only (would not be sent over http). I am guessing that your http and https pages share session, which means you can't set this setting, making your site vulnerable to this attack. but it's good to be aware of this.
http://anubhavg.wordpress.com/2008/02/05/how-to-mark-session-cookie-secure/
another article you may find helpful
http://www.west-wind.com/Weblog/posts/4057.aspx
Related
I have a web api application that I am considering moving to HTTPS. The reason is really just for the initial login where I would like to hide the username and password.
Once logged in do all other calls from the pages also need to be HTTPS? For example do my calls to CSS and scripts need to travel over HTTPS? How about WebAPI calls?
When referencing HTTP content from HTTPS pages, some user agents will issue warnings about "mixed content" or "insecure content" to the user, others may block the content (older versions of IE do that). GitHub solved this issue using ngnix as reverse proxy, so it serves the static content as HTTPS.
If you are only worried about the authentication, and it is cookie based, you can do the authentication in HTTPS and then get back to HTTP. The cookie will be shared as long it is not marked as Secure. Remember that both the GET request acquiring the login FORM and the POST call sending the login form should be HTTPS to be secure.
You can use the page in HTTP and do the AJAX calls in HTTPS: Ajax using https on an http page. Again, this may be useless if the auth form is not secure as well.
If your static content is hosted in a CDN, probably the CDN is able of proxying the requests to your site and return HTTPS content if required.
Static content served as HTTP won't be cached for when you request the same content through HTTPS, neither viceversa, so it will basically downloaded twice.
Also relevant, please check these 7 myths about HTTPS, specially myth #1. If you are worried about security, maybe switch completely to HTTPS is the best decision.
We are setting up a website with secure and non secure pages. These have been added for mapping in uriworker.properties. The domain name in the urls are different . Example nonsecure url is x-y-z.a.b.org and our secure url is x-y-secure-z.a.b.org.Both of these domains are part of our DNS entry. We do not have any redirect rules configured within the webserver. But when we try to access the secure url https://x-y-secure-z.a.b.org, webserver is sending the request as http://x-y-secure-z.a.b.org:443. Due to the scheme not being https , the application does not identify this as secure request and is returning a 302 to the https url. This redirection happens infinitely and then an error appears which says that page is not redirecting properly.
After a lot of analysis , we figured out that the application had a hardcoded check on the scheme of the domain name to be in a certain format as secure.xyz.
In My MVC4 Mobile application I have registration, login page and remaining pages. I would like to redirect user to HTTPS connection for all sensitive information pages like registration and login pages and HTTP to remailing pages.
For this, I used the following code: in the controller action method:
if (!HttpContext.Request.IsSecureConnection)
{
var url = new UriBuilder(HttpContext.Request.Url);
url.Scheme = "https";
Response.Redirect(url.Uri.AbsoluteUri);
}
but getting this error:
Server cannot modify cookies after HTTP headers have been sent.
You can use the [RequireHttps] attribute on your controller to do what you are asking. I would however suggest that since you already have a SSL certificate, just make all of your transactions HTTPS.
The reason for my suggestion is once a user has authenticated, the auth cookie will be sent with every HTTP request. If you then move away from a controller with the HTTPS requirement, a man in the middle attack is a potential vulnerability. Anyone able to sniff a users HTTP traffic could potentially hijack their session by stealing the cookie.
To force HTTPS across the entire site, in Global.asax add this line to the RegisterGlobalFilters method
filters.Add(new RequireHttpsAttribute());
I have a site (running a 3rd party app) that's available over HTTPS and HTTP. It allows people to log in with Basic Authentication. I'm trying to force all logins to happen over HTTPS rather than HTTP.
The app is odd in that the authentication "realm" is the root of the domain (/), and 401s are returned based on query string parameters rather than the URL path. I think I've got my RewriteRules set up properly so that any request that could result in a 401 is redirected to HTTPS first. However, I'm worried that after logging into the secure site, if users navigate back to the HTTP version somehow, browsers will still send Authorization headers (now unencrypted) without seeing a 401 since it's all the same domain with the /same/path/structure. That is, I'm worried about this behaviour from RFC 2617:
A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.
Should I worry? Or does switching protocols (https to http) prevent browsers from sending those preemptive auth headers?
We heavily use basic auth for our application. All using https of course :)
Browsers have a good sandbox model, they know that when the protocol changes, the target machine may not be the same anymore. You don't have to worry about browsers submitting the authentication information.
Even when they run into the initial 401, they will still ask the user for the username/password pair.
I have a virtual folder containing an administration application, like
https://www.mysite.com/alpha
which requires SSL. In the IIS manager properties for the folder, under "Authentication and access control", Anonymous Access is disabled and "Authenticated Access" is set to "Integrated Windows authentication."
When I connect to the site in Chrome, I receive two login boxes. The first is from mysite.com/alpha:443, and the second is from mysite.com/alpha:80. Firefox appears to re-send my credentials for the second box so it is never shown.
Any ideas why I'd be required to log in twice?
If you require SSL for authenticated users on your website (for any reason), then the best solution is to always have your "Login" page on https://. That way when they log in, they are instantly secure. The reason for this is because of the native design of SSL. It separates/secures it's self from the non secure version by not passing authentication states between http and https.
you will also have to write some logic to redirect returning authenticated visitors to the secure page (IE: visitors who can return authenticated from a cookie).
EDIT:
Since your using windows authentication, it's probably easiest to simply redirect ALL incoming http traffic to https. This means your entire site will be over SSL and will be inaccessible via http (other than to redirect to https)
I wrote a Blog Post on forcing a website to use WWW in the web address, but it can also be ported to forcing https.
Yep,
The one uses SSL, the other not.
therefore, you are not allowed to share the credential cache from a Secure session, with the one of the unsecure session.
if you require SSL, then directly redirect the users to the SSL website.