I am attempting to secure a website I am currently developing using ASP.NET MVC 2.0 and forms authentication. In order to secure the forms authentication cookie I want to set the requiresSSL property to true so the cookie is only send by browsers when the connection is under SSL, and obviously ensure that all resources which require authorization are under SSL.
My problem is that we are using Application Request Routing to fulfil a number of functions, one being SSL offloading, therefore by the time a request hits any web server in our farm the request is no longer under SSL and the FormsAuthentication.SetAuthCookie method fails because an SSL connection is required to set the cookie when requiresSSL is specified.
Anyone have any ideas as to a work around here!
Thanks
So I have a work around for this, however if anyone has any better ideas please feel free to comment. Essentially you need to intercept the response at the end of the request and manually set the Secure property on the forms authentication cookie, pretty obvious really, you will also need to set the requireSSL property in the forms authentication configuration to false. Also bear in mind we do not want to enable HTTPS for the entire site for authenticated users hence this work around.
There are a couple of caveats to this approach and a few things to be aware of.
I found during testing that the forms authentication cookie was always written to in the response, so I kept overwriting the valid authentication cookie in the browser with an empty authentication cookie, to get around this I included some logic in the HTTP module to work around this, see code snippet below.
All requests to the application which require authorization must be under SSL, otherwise the request will not contain the authentication cookie in order to authenticate the user.
Because you are only passing the authentication cookie for SSL requests you will need another mechanism to tell your application that the current user is authenticated when they browse the non SSL areas of the site, I have implemented this with an additional cookie which is set when the user logs in, and does not have an expiry date set, so will expire at the end of the users session, of course this cookie is removed if the user logs out.
Below is the logic implemented in an HTTP Module to affect the above, I have been testing this the last couple of hours and have not come across any problems yet, I will be sure to update this post if I do!
We should only ever send an authentication cookie to the client if the user has just logged in here's the logic
If the request has an auth cookie the user is already authenticated
and under SSL so ensure we do not send a new auth cookie in the
response.
If the request does not have an auth cookie but there is a valid
auth cookie in the response, set the response auth cookie to secure,
so it is only transmitted by the browser under SSL.
If the request does not have an auth cookie and the response has an
invalid or empty auth cookie, ensure we remove the response cookie
so we dont overwrite the valid cookie in the client browser.
private void EndRequest(object sender, EventArgs e)
{
var application = (HttpApplication)sender;
if (ValidRequest(application.Request) && application.Response.Cookies.Count > 0)
{
//only do the below if the user is not logging out the site, if the user is logging out we can
//leave the default forms authentication behaviour which is to expire the auth cookie
if (application.Request.AppRelativeCurrentExecutionFilePath != "~/authentication/logoff")
{
var requestAuthCookie = application.Request.Cookies[FormsAuthentication.FormsCookieName];
var responseAuthCookie = application.Response.Cookies[FormsAuthentication.FormsCookieName];
if (requestAuthCookie != null && responseAuthCookie != null && responseAuthCookie.Value.IsNullOrEmpty())
{
application.Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
}
else if (responseAuthCookie != null && !responseAuthCookie.Value.IsNullOrEmpty())
{
responseAuthCookie.Secure = true;
application.Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
application.Response.Cookies.Add(responseAuthCookie);
}
else if (responseAuthCookie == null || responseAuthCookie.Value.IsNullOrEmpty())
{
application.Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
}
}
}
}
SSL offload should allow you to make a SSL connection from the SSL offloader to the web server.
The SSL connection from the SSL Offloader to the web server should use the lightest and fastest (and probably weakest) encryption available.
This allows you to use secure cookies, reduce the encryption load on the servers and avoid the modification of your code.
Related
I am aware of How to Respond to an Authentication Challengelike we have NTLM Authentication as there are 3 options.
Provide authentication credentials.
Attempt to continue without credentials.
Cancel the authentication request.
But just want to know the thoughts here, when we go with the first option Provide authentication credentials we pass the username and password URLCredential is there any possibility of leakage of credentials, is it secure to pass the credentials, what is happening behind the screens? how Apple network API sending the credentials to the server?
Yes, we can set the policies like server domain, failure count etc. but from the security point of view is it safe? from Man in Middle Attack (MIMA) or anything else?
Maybe the way I have posted my question is not clear but I was looking more from the Application credential security point of view with NTLM Authentication and after lots of Google, I have found, how’s NTLM works and it’s pretty interesting to see that client don’t share the password with the server. here are the steps as follow.
The client makes the request to the server.
The server needs to validate the user because there is no identity so server generates 16 bytes random number called as the challenge and sends it to the client.
Client hash this challenge with the user’s password and return it back to the server that is called the response it also includes username as plain text and challenge sent to the client.
The server sends everything to the domain controller and it uses the username to retrieve the hash of the user’s password from security account manager database and hash the challenge.
Domain controller shares the response back to the server if they are identical then authentication is successful otherwise a failure.
So the interesting part is here that Network API doesn’t share the password with the server it means it very secure.
I hope it will help others, For More.
There are multiple types of challenges, and the answer to your question depends on what type of challenge you're talking about. Each challenge has a protection space, which basically tells what type of challenge you're responding to.
To answer your question for the most common protection spaces:
Basic password-based authentication (NSURLAuthenticationMethodHTTPBasic): The credential you pass is sent in cleartext to the server (HTTP) or encrypted by the session key (HTTPS).
Digest authentication (NSURLAuthenticationMethodHTTPDigest): The credential you pass is cryptographically hashed with a nonce provided by the server, and only the resulting hashed token gets sent over the network.
NTLM authentication (NSURLAuthenticationMethodNTLM): The credential you pass is cryptographically hashed with a nonce sent by the server, and only the resulting hashed token gets sent over the network.
Client Certificate authentication (NSURLAuthenticationMethodClientCertificate): The certificate is sent to the server, but not the private key data. The client uses the private key to sign the prior TLS handshake data as a means of letting the server verify that the client really does have the private key associated with that cert.
Server certificate validation (NSURLAuthenticationMethodServerTrust): If you pass a certificate obtained from the server, you MUST validate it first, or else you effectively reduce the level of security to that of HTTP (i.e. any server can send any cert and you'll be saying to trust that cert when talking to the server).
The list above covers the most common protection spaces. Kerberos is its own animal, and I don't know anything at all about how that works. And there's also the "Form" protection space, which is just a placeholder for custom authentication that you can use in various parts of your app's code, but is not actually supported in any meaningful way.
It is worth noting that Basic, Digest, and NTLM authentication provide no protection against man-in-the-middle attacks if the attacker can alter data in transit, because the authentication token provided does not depend on the rest of the request in any way. Thus, these are really suitable only for use over an encrypted channel (HTTPS).
I manage a Rails 4.2 application which runs dual stack: SSL and Non-SSL. I'd like to set the Secure flag for cookies when the resource is requested via HTTPS and I want to leave out the flag when the resource is requested via plain HTTP.
Is there a way to achieve this in Rails (session cookie, cookies sent manually in the Code)? And especially when using Devise with rememberable enabled.
I know this is a late response, but I'm currently looking into the same thing and it seems https://github.com/mobalean/devise_ssl_session_verifiable should automate this for you, although it uses a different approach (regular session cookie over http + https, but an additional secure cookie in https, so that someone hijacking your session cannot access your https-only resources.
I'm currently working on an OpenId Server/Client for demonstration purposes and I struggle to understand the following specification.
http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest
1) The clientApp sends an request (ajax) to the serverApp in order to obtain a session id
2) The clientApp sends an authentication request (ajax) to the serverApp with
{
response_type : "id_token",
scope: "openid profile",
client_id: "clientApp",
redirect_uri : "clientAppAddress/redirecturi",
state: ???,
nonce: ???
}
There are no optional fields for grant_type, username and password (as in RFC6749: Access Token Request). How can I transmit the credentials?
Moreover I don't understand the concept behind "state" and "nonce". The specification says that nonce's value "needs to include per-session state and be unguessable to attackers. One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter.", whereas state is used to mitigate CSRF, XSRF "by cryptographically binding the value of this parameter with a browser cookie". Where is the difference between them and how do they increase security? I would use the hash-value of the sessionid (stored in http only cookie, and transmitted to the client in the first request) for both of them?
The actual method of authenticating the user, thus transporting credentials is not part of the OpenID Connect specification. The OpenID Connect specification merely tells you how to transport information about the authentication event and the user to a peer. The means of user authentication is independent of that.
The state parameter is there to correlate request and response and to share context between request and response. One of the things that you would typically associate with the state is the URL that the user is trying to access, so that after a successful authentication response you can redirect to that.
The nonce parameter is to prevent replay attacks since that value should be cached.
Together they are used to prevent Cross Site Request Forgery where an attacker got hold of the id_token and tries to use it against the RP to impersonate the user in the attacker's browser.
It would be better to use other values for state and nonce than directly derived from session_id since you may want to restart authentication from the same session and then nonce replay prevention would block you from reusing it (and distinguish between you and an attacker). Also state should be non-guessable, so not the same as previously used in the same session.
Please help me to understand the concept of expiry time for sessiontoken.
Below is the way I am setting the session token after receiving the token from STS.
var principal = validationfunction();//returns claimsprincipal
if (principal != null)
{
var token = new SessionSecurityToken(principal.ClaimsPrincipal)
{
IsReferenceMode = false
};
//this makes sure that the identity and claims are written to the cookie.
FederatedAuthentication.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(token, true);
}
Please confirm if this is true or not:
if the token lifetime is 10 mins. if user is inactive for 10 mins and doesnt send any request to
website it the session token expires and its redirected to STS login page.
if user is active and keep refreshing the page/visits different page the sessiontoken lifetime gets
refreshed . it means everytime the user visits the page the token gets new expiry value. So user will not be redirected to login page every 10 mins.
if user requests a STS protected resource (web api) , the life time of token is treated absolute. Meaning regardless user is active or not, after 10 mins of token generated if the user requests web api , the token will be invalid and redirected to STS login page.
are the above concepts correct?
You need to set the token lifetime yourself. The default is IIRC - 10h. When the token has expired and you are accessing a protected resource, the application will emit a 401. If you have the WsFed modue - this will result in a roundtrip to the STS
Session security tokens are absolute expiration by default
You wouldn't use a cookie to secure a Web API - a redirect does not make sense for APIs (nor does cookie authentication).
I'm using DotNetOpenAuth to connect to Facebook and Google via OAuth2. The OAuth specs ask that no additional parameters be supplied in the request_uri and Google actually enforces this somewhat by forcing to to specify an exact call back uri when you define your Google App with them.
What I want to accomplish is to be able to return the user to a specific URL after they have been authenticated with Facebook or Google. The flow is this, the user clicks on a protected link, they get forwarded to my login page with a returnUrl parameter and then I kick off the authorization process based on the OAuth2 authorization server they choose.
Since the request_uri can't have any parameters in it (though Facebook lets you get away with this), I can't send the returnUrl parameter to the authorization server and get it back such that when the user is returned to my site, I forward them to the protected page they were trying to access. The best I can do is to forward them to the homepage or a member welcome page.
The way to fix this is to use the "state" parameter which the authorization server will send back to the request_uri, but I can't find a way to specify this with DotNetOpenAuth.
By default, it looks like the code uses the SessionID as the state parameter to verify the request coming back from the authorization server. Specifying an IClientAuthorizationTracker on the WebServerClient class lets me plug in my logic when the response is coming back from the authorization server but it's not called when the authorization request is being prepared, so I can't plug in my additional state.
This is code from WebServerClient.cs's PrepareRequestUserAuthorization:
// Mitigate XSRF attacks by including a state value that would be unpredictable between users, but
// verifiable for the same user/session.
// If the host is implementing the authorization tracker though, they're handling this protection themselves.
if (this.AuthorizationTracker == null) {
var context = this.Channel.GetHttpContext();
if (context.Session != null) {
request.ClientState = context.Session.SessionID;
} else {
Logger.OAuth.WarnFormat("No request context discovered, so no client state parameter could be set to mitigate XSRF attacks.");
}
}
There is no else block here which is what I would have expected to be able to play along and plug in my own data.
Any tips on what I'm missing?
The state parameter is necessarily preoccupied with mitigating XSRF attacks. Since you already have a user session, can you just store the returnUrl in the session dictionary?
Alternatively, you can file an issue with DotNetOpenAuth asking that you be allowed to bundle your own data into the state parameter (along with DNOA's own XSRF mitigation code).