In my ASP.NET MVC 4 application I use a third-party service. And one of the service's terms of use is adding to all session cookies HttpOnly and Secure attributes.
WebSite hosted on Windows Azure and works on SSL.
I added to root web.config the following settings:
<httpCookies httpOnlyCookies="true" requireSSL="true" lockItem="true"/>
<authentication mode="Forms">
<forms loginUrl="~" timeout="2880" requireSSL="true" />
</authentication>
So now my application session cookie ".ASPXAUTH" has HttpOnly and Secure attributes.
But the main problem that Azure Balancer "WAWebSiteSID" and "ARRAffinity" cookies don't have this attributes.
Could you help me to find appropriate solution to add missing attributes to them?
I don't believe you can modify the secure and HttpOnly attributes as the cookies are added to the response downstream of the app (i.e. by a load balancing appliance that sits in front of the site).
Of course the pragmatic question is "why"? What advantage would you gain by not allowing client script or an MitM on the wire to access these cookies? They're nothing more than bytes of data intended to tie clients to site instances and contain nothing of a personal nature nor provide any conceivable upside for an attacker (at least not that I can think of).
The answer is probably "because it keeps a security scanning tool happy" which may make you feel warm and fuzzy, but of course it doesn't actually change the practical security position of the site one iota.
As of June 24, 2017, this is changing and ARRAffinity cookies will be set with the HttpOnly flag in the future. https://github.com/Azure/app-service-announcements/issues/12
Related
I am working on MVC framework in ASP.NET where, I was trying to access the application but I was not able to go past the login screen, after which it kept throwing the not found IIS error. After workaround i found that i had this line : httpCookies httpOnlyCookies="true" requireSSL="true" in my web.config file which was stopping the access. Can anyone help me understand the problem and concept here?
Thanks already.
I was able to access the site after removing the requireSSL part only.
Web-config
httpCookies httpOnlyCookies="true" requireSSL="true"
Global.asax's Application Start :
if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Tls12) == false)
{
ServicePointManager.SecurityProtocol =
ServicePointManager.SecurityProtocol | SecurityProtocolType.Tls12;
}
I think the part of code in global.asax's Application Start might be causing the problem, but I'm not sure about it.
Websites use cookies to store information between page requests or browsing sessions.
The callback from an external provider to your site contains security tokens(httpCookies) that allow access to your site and contain user information.
If someone manage to steal other's authentication cookie for a website, he could carry out all the actions that they are capable of.
Transmitting this information over HTTPS to prevent interception while this information travels over the Internet is important
You can stop script access to all cookies in your site by adding a simple flag: HttpOnly. You can set
this flag in the web.config, as follows:
<httpCookies domain="" httpOnlyCookies="true" requireSSL="false" />
So If you write requireSSL="true" in your Web.config It Enforcing the external provider to make their callbacks to your site using HTTPS only.
#Vishesh Pandita In your case you are trying to access site using HTTP only. So faced "HTTP Error 403 - 403.4 Forbidden: SSL required" error.It means the page you are trying to access is secured with Secure Sockets Layer (SSL).
Solution:
To view the page, you must enable SSL (Secure Sockets Layer) by typing "https://" instead of "http://" at the beginning of the address you are attempting to reach. The "s" in "https" specifies a secure site.
Migration for HTTP to HTTPs
source : Professional ASP.NET MVC 5
For the last couple of days I'm trying to resolve a problem in my MVC 5 web application related to the anonymous identification module.
I enabled the anonymous identification by adding the following line to Web.config:
<anonymousIdentification enabled="true" />
The problem is that the cookie used by the module changes every time the browser sends a request:
.ASPXANONYMOUS=6yylwpA5baKlbP-ntBra3pA1vr1y5kXp...
After refreshing the page the cookie changes to:
.ASPXANONYMOUS=s3-AlVJNimP5NrDI1PLWc8RK720RTeNY....
And so on and so forth.
What's interesting is that anonymous identification works perfectly fine in our test environment and keeps the value of the cookie consistent across multiple requests. But deploying the same code to production results in this strange behavior, so I suspect a configuration issue in IIS. Both environments use IIS 8.5.
Any idea what I'm missing here?
You have likely moved on but I noticed this while in development on some MVC5 applications.
If you use a valid hostname / domain / IP and not 127.0.0.1, it shouldn't recreate the .ASPXANONYMOUS cookie every request.
On a side note, you can do a lot of edits to the anonymous cookie by applying attributes to the configuration.
For example, the following would only set the anonymous cookie for an hour:
<anonymousIdentification
enabled="true"
cookieName=".ASPXANONYMOUS"
cookieTimeout="60"
/>
Link to documentation on the anonymousIdentification element for more info.
I have code like this which is run when a user is authorized:
FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
1,
email,
DateTime.Now,
DateTime.Now.AddMinutes(120),
true,
userData);
string encTicket = FormsAuthentication.Encrypt(authTicket);
HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
faCookie.Expires = authTicket.Expiration;
Response.Cookies.Add(faCookie);
I then redirect to a controller/Action that has the Authrize attribute:
[Authorize]
public class ProductsController : Controller
{
I have the following in web.config:
<authentication mode="Forms">
<forms loginUrl="~/Home/Unauthorized" timeout="2880" />
</authentication>
<sessionState timeout="120"></sessionState>
However users are complaining of session timing out or redirecting Home/Unauthorized after a couple of mins of inactivity.
what could be causing this, what else should i check?
A couple of thoughts before I go into a possible solution of why your logins are expiring. First, the FormsAuthentication cookie and SessionState are two different things completely. You can have one or the other, or both or neither. As a result, the timeouts for these two items are also not related.
The FormsAuthentication cookie is an encrypted cookie that contains some basic information such as the user name and an expiration value. The .NET application uses this cookie once a user has authenticated to know if the user is authorized for certain resources.
What controls the encryption and decryption of the FormsAuthentication cookie is the MachineKey for that web application on IIS. The MachineKey is a set of keys used to encrypt and decrypt the cookie. By default, a web application on IIS is set to AutoGenerate the machine key. What this means is that when an application starts, a random machine key is generated. If an application recycles, you get a new machine key. Additionally, if you are hosting on a shared provider, the web host will typically have your application load balanced, meaning hosted by more than one server. Each one of those servers will auto generate a machine key.
If your web application is on a load balanced scenario, then each machine in the web farm cannot decrypt the other's encrypted cookie. This will give the appearance of "being logged out". The example of this is logging in on web server A, then a subsequent request goes to web server B. Web server B does not share a machine key with web server A and cannot decrypt the cookie, sending the user back to the login page.
The solution is to define the MachineKey section in your web.config so each instance of IIS will use the same keys as well as if the application pool recycles, you still have the same machine key.
Here would be an example machine key (use the .NET 2.0 version) that you could place in your web.config
<system.web>
<machineKey validationKey="EBC1EF196CAC273717C9C96D69D8EF314793FCE2DBB98B261D0C7677C8C7760A3483DDE3B631BC42F7B98B4B13EFB17B97A122056862A92B4E7581F15F4B3551"
decryptionKey="5740E6E6A968C76C82BB465275E8C6C9CE08E698CE59A60B0BEB2AA2DA1B9AB3"
validation="SHA1" decryption="AES" />
</system.web>
Additional thoughts are that your expiration in your web.config (2880) and what you are actually setting the expiration to be (120) do not match. You may want them both to match.
If you are running behind a load balancer you will want to ensure that the web farm is using a consistent key as pointed out by Tommy's answer.
Other things to check will be that the IIS metabase settngs for each server are identical. They need to have the same path and ID.
You will also want to look at holding session out of proc (your web.config looks like in proc) which is susceptible to network outage and random app recycles.
Basically a summary of this link.
http://msdn.microsoft.com/en-us/library/vstudio/ms178586(v=vs.100).aspx
If you can post more of your config if possible and give more detail about your environment setup it will be easier to point you in a more focused direction.
Try This one:
web.config Code:
<system.web>
<httpRuntime maxRequestLength="40000000" useFullyQualifiedRedirectUrl="true" executionTimeout="600000" />
<authentication mode="Forms">
<forms loginUrl="~/Home/Unauthorized" timeout="2880" cookieless="UseCookies" />
</authentication>
</system.web>
This will help you.
I'm trying to use forms authentication that will work for both my top level domain & sub domains.
for example, if I log in with this domain: mydomain.com and afterwards going to www.mydomain.com i want to have the ability to identify the user who logged on to mydomain.com (it's the same application).
i'm using the following in my web.config file:
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" domain="mydomain.com" timeout="2880" />
</authentication>
This is an mvc project, and i'm getting the user id with the following API:
HttpContext.Current.User.Identity.Name
The creation of form authentication cookie is done by the following api after performing openid logon to the user:
FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
I can see that the authentication cookie is being sent to both domain but only the domain that the authentication was made against recognizes the user.
Am i doing something wrong?
Thanks,
Lior
Make sure you have the same machine keys setup for those two applications. If the authentication token is encrypted with the machine key of application 1 and application 2 has different key it won't be able to decrypt it.
This question isn't exactly the same as yours, but it looks like it's the solution your looking for.
You need to issue your ticket in the toplevel domain, in order to be recognized by subdomains. This is because of how cookies work:
If you set the cookie in domain.com it will be visible on sub.domain.com
However if you set it on sub.domain.com, it will not be visible on domain.com
This is a security issue because of cookies and you'll have to consider it, beyond the settings of the <form> element which have to do with validating/rejecting a authentication cookie, where you will need to have domain='domain.com', which you already do.
In addition to all this, if on the subdomain you have a different application, you will need to explicitly define the machine key to be the same. You can generate your self some keys here: http://aspnetresources.com/tools/machineKey
Using DotNetOpenAuth 3 in ASP.NET MVC and implementing a RememberMe facility ...
I'm finding that even if I set createPersistentCookie to true in FormsAuthentication.RedirectFromLoginPage and FormsAuthentication.SetAuthCookie the user is not remembered once the ASP.NET session times out.
If I inspect the cookie I find it is marked as persistent and does have an expiry date way in the future, I assume because I set my web.config FORMS timeout to a few years away. Anyhow, if the user closes the browser and re-opens it they are remembered correctly - as long as the ASP session hasn't timed out.
An older post of Scott Hanselmann's makes me wonder if it is because FormsAuthentication tries to renew the authentication ticket and maybe in an OpenId model that doesn't work but I have set FORMS SlidingExpiration="false" in web.config and anyway I thought that forcing a persistent cookie would make that stuff irrelevant.
I'm also wondering why the DotNetOpenId MVC sample doesn't include a RememberMe checkbox - maybe there's something tricky about it?
On the other hand, here at StackOverflow I see I am automatically remembered across sessions. Wondering whether they used something other than DotNetOpenId to do their OpenId authentication.
Anybody else done RememberMe successfully with DotNetOpenId in ASP.NET MVC? Any tricks?
[Update]
Thanks for trying to help, Andrew. Turns out this was not about DotNetOpenId.
I gather, after reading this, that my hosting provider is probably recycling the app pool regularly and that's causing the authentication ticket encryption to be done with a new machine key.
As per the preceding linked article I added the following under System.Web in my Web.Config and it resolved the issue:
<machineKey
validationKey="(generated a new key to place here)"
decryptionKey="(generated a new key to place here)"
validation="SHA1"
decryption="AES" />
I still think the cookie name should match... but here's something else.
It sounds like you're saying as long as your timeout in the web.config file is large, then things work. But that once you shorten it, your persistent cookie doesn't outlast the timeout value. This forum topic helped answer this for me:
http://forums.asp.net/p/1010241/1347970.aspx#1347970
It seems that the timeout in web.config affects all cookies. It says how long the authentication ticket lasts. All auth cookies have this 'time to live' timeout whether they are 'persistent' or not. So the difference between persistent cookies and non-persistent cookies are that the former will last across different browser sessions and the latter will die (early) if the browser is closed.
Does that make sense?
Does the cookie name match in your web.config file and your controller's call to FormsAuthentication.SetAuthCookie? This may be a bug in the DNOI sample, but I suspect if you have a cookie name in your web.config file (as the DNOI sample does), then you probably have to set the cookie name as the third parameter to SetAuthCookie or RedirectFromLoginPage. Otherwise, forms auth doesn't recognize the persistent cookie you set as the login cookie.