I have two website, Site A and Site B.
Site A is on the DMZ area where allow public/anonymous sending http request (one of the client http request data), and i would like the request to redirect to Site B(internal secure host which only allow internal http request)
My question is, Site B is setup with basic authentication REALM. but public/anonymous http request doesn't support Basic REALM. is there a way in the IIS Site A to redirect the request with authentication so Site B could accept the request with REALM
I have found a way to resolve the above question by using Microsoft ISA Server
Related
Imagine the following scenario:
The user goes to http://example.com
The server redirects to the secure version https://example.com using a temporary redirect (status 302)
https://example.com responds with an HTTP basic auth challenge (status 401)
The user successfully provides username/password and access is granted (the browser stores these credentials in its internal cache)
What happens if the user follows a link to the unsecured version of the website (http://example.com)?
Would the credentials be exposed due to the clear-text HTTP request?
Are HTTP credentials and HTTPS credentials stored in separate "buckets" by the browser?
Technically, the two URLs belong to different origins so the credentials should not be shared. But I could not find any confirmation of this online.
Are HTTP credentials and HTTPS credentials stored in separate "buckets" by the browser?
Yes, and those buckets are officially called 'origins'. Specifications like HTML, Javacript, HTTP and URIs talk about origins, but the bucket is effectively the URI minus the path.
So for https://example.org/foo/bar, the origin is https://example.org
So this includes:
The scheme (http / https).
The domain
The port
So in your example the 2 relevant origins / buckets are http://example.com and https://example.com and they are separate.
I'm sending username and password in the HTTP Body for authentication to each controller action in a Web API. I do the authentication in each controller using the username/password. It's using SSL.
Are there any security reasons why it's better to send the authentication credentials in the HTTP Header than in the HTTP body?
If I was using Basic Authentication I can see how having the credentials in the header are necessary as in this question but I'm not so I don't see the purpose. It seems just as secure in either as long as it's using SSL.
From an SSL perspective the security of the credentials in header (HTTP Basic auth) or body (e.g. form based logon) of an HTTP request is equal.
However if the client is a regular web browser you should consider the following:
Browsers cache the credentials used with HTTP basic authentication the users usually face the problem that for performing a log-out they would have to close their browser.
On the other side a form-based logon usually created a session cookie that is time restricted and can be deleted any time.
I'm experimenting with moving an existing enterprise app to HTTP 2.0 at my customer's request. The app uses ASP.NET Forms Authentication, and when accessed over HTTPS with HTTP 2.0-aware browser and server (Windows Server Tech Preview), authentication appears to succeed during the login action, redirecting to the requested URL, but then the server responds to the next request with a redirect back to the login URL again. After adding some diagnostic logging to Application_BeginRequest, I found that the auth cookie is present in the request, but an attempt to decrypt the ticket with FormsAuthentication.Decrypt() throws an exception stating that there are non-base-64 characters in the cookie. I suspect this has something to do with HTTP 2.0 header compression, but I would have thought that this should have been handled transparently by IIS and that the headers should have been decompressed by the time my code executes. Has anyone else experienced this and know of a workaround? Happy to provide additional information if I left anything out.
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 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