We have a .NET Framework web app where we use .ASPAUTH cookie and ASP.NET_SessionId for authenticated user. Our Session.Timeout is set to 60 minutes in the IIS hosted web.config file.
Recently I follow the recommendation of OWASP top 10 to prevent possible information exposure by Disable caching for response that contain sensitive data.
I did this by adding the following in the Web.config file of the web app.
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="0" />
</customHeaders>
</httpProtocol>
The very next day I start getting call from some users (not all) that they got redirect to the log out page by simply clicking on links in our web application. So I did what naturally comes to me is to roll back that change and off course that complains went a way gradually.
This puzzle me, as I don't know how http response caching directive could lead to invalidating a user session and log them out. Even though I see the issue went away, there is no way for me to confirm that it was due to my roll back of these header values.
I know the Pragma and Expires are from Pre HTTP 1.1 so I plan to add the following back in and see if I have the log out issue again.
<add name="Cache-Control" value="private, max-age=3600, must-revalidate" />
Do you think they are related? I researched around and all I could come up is the cache control really affect how often the user request resource from server. One factor I don't have control over is can something on the user's browser end that when combine with this Cache-Control directive can destroy their authenticated session?
Update: I see this refers briefly at this resource. However, they don't really go into the details.
Related
I know there are a lot of questions on this topic and I have read them all.
I'm using IIS8, .Net 4.5.
Users randomly get an invalid viewstate error, I can't figure it out. Once this happens the only way they can get back into the site is to clear browser cache.
In my web.config I have:
<system.web>
<machineKey validationKey='....key here' decryptionKey='....decrypt key is valid here' validation='SHA1'/>
<!--<hostingEnvironment shadowCopyBinAssemblies="false" />-->
<authentication mode="None" />
<compilation targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5.1" />
...
</system.web>
I'm running on a virtual private server, and I've yet to find a viewstate larger than 9kb.
My application pool is set to restart at 3:00am, once per day.
My page uses update panels, maybe the user is clicking 'back'? But I've seen it happen just visiting the page with no clicking back.
One thing I noticed is I have 3 different sites using the same application pool identity, but the application pools are seperate. There is no machine keys in machine.xml, but only in my web.config.
A couple of possibilities to investigate:
Update panels are changing form field values (which are what is used to compute ViewState), then the page gets POSTed back to the server, where the new values make validation fail. See this post
You have caching enabled (perform a trace of HTTP headers - make sure you don't have dev tools open) which is causing invalid ViewState to be generated w/ UpdatePanel gumming things up.
Are you using Server.Execute anywhere? (see above link for same)
(less likely) Does your "Virtual Private Server" get migrated to different hardware (perhaps without you knowing it)?
I've just got back to working on an integration with the Adwords API, and realized it had to be upgraded (from v201109).
This was previously a prototype application, that is now scheduled to come to life, and what I've noticed is that there's been a big leap from v201109 to v201209 in terms of authentication.
By reading Takeshi's reply here, it became clear that the entire concept of sandbox has now been phased out, and we now work on the basis of having a test account.
Initially on my prototype I was only using ClientLogin as the AuthorizationMethod through a test account. However, with the new authentication I've realized I will actually have to use our actual live MCC account with a test account as described here.
All well and good, I've got the account created, and have requested permission to use it as a test account. However using the live credentials with
<add key="AuthorizationMethod" value="ClientLogin" />
<add key="Email" value="xxx"/>
<add key="Password" value="xxxxx"/>
Isn't an option... :-(
I then thought about requesting an OAuth key pair in order to use them on my application instead. All the documentation I found about getting one of those seems a bit rough around the edges, so I'm not really sure how to get one of those without actually making my application request it. Ideally, I'd like to go somewhere, generate it, and then use it on my config file as such.
<add key="AuthorizationMethod" value="OAuth" />
<add key="OAuthConsumerKey" value="INSERT_YOUR_OAUTH_CONSUMER_KEY_HERE" />
<add key="OAuthConsumerSecret" value="INSERT_YOUR_OAUTH_CONSUMER_SECRET_HERE" />
Is that even possible? If so, where can I generate the OAuth keys?
Turns out you still can use ClientLogin, but it's been earmarked for deprecation, which means Google will still support it for the next 3 or so years.
Here's a link to a conversation between Anash (AdWords API Advisor) and myself on the Google Adwords API official forum.
https://groups.google.com/d/topic/adwords-api/C-giDgpvF_I/discussion
I am getting this error, and I know what causes it. There are many causes, but in my case, the issue is that the machinekey differs from server to server (in the web farm) and therefore when it jumpes from machine to machine, it can't decrypt viewstate and/or cookies . I've since fixed this issue, however, there are some users still left with a cookie on their machine, written with the old machinekey, and they are getting this error. I need a good way to handle this error, log them out and then redirect back to the login page. I've tried putting an exception handler in global.asax in Application_error, but this doesn't seem to fire for this error. There are other errors that happen, and I've filtered to catch only this error (by looking at the exception). I have customErrors 'on' in the web.config. How do I do this?
There are a few ways to resolve this issue. The best overall solution is to set the encryption and decryption keys explicitly in the machine.config of each server:
<machineKey validationKey="JFDSGOIEURTJKTREKOIRUWTKLRJTKUROIUFLKSIOSUGOIFDS..." decriptionKey="KAJDFOIAUOILKER534095U43098435H43OI5098479854" validation="SHA1" />
Another option is to disable encryption of the ViewState altogether, but you will lose some security benefits by doing this:
<pages viewStateEncryptionMode="Never" />
Lastly, you can disable the validation:
<pages enableViewStateMac="false" ... />
I am using the openid-selector with DotNetOpenAuth in my MVC 3 app. Whenever I set a session variable and the DotNetOpenAuth sections are in the web.config, my session variables don't stick after a redirect.
I checked the Session.SessionID variable and it is still the same, so I am in the same session (I believe), but when I check the session variables I just set after a redirect they are all set to null.
I haven't seen anyone else with this issue. I am wondering if DotNetOpenAuth just isn't ready for MVC 3 yet. I am using the latest version of DotNetOpenAuth as well.
Here are the relevant portions of the web.config if it helps:
<configSections>
<section name="uri" type="System.Configuration.UriSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<section name="dotNetOpenAuth" type="DotNetOpenAuth.Configuration.DotNetOpenAuthSection" requirePermission="false" allowLocation="true"/>
</configSections>
<uri>
<idn enabled="All"/>
<iriParsing enabled="true"/>
</uri>
<system.net>
<defaultProxy enabled="true"/>
<settings>
<servicePointManager checkCertificateRevocationList="true"/>
</settings>
</system.net>
<dotNetOpenAuth>
<openid>
<relyingParty>
<security requireSsl="false"/>
<behaviors>
<add type="DotNetOpenAuth.OpenId.Behaviors.AXFetchAsSregTransform, DotNetOpenAuth"/>
</behaviors>
</relyingParty>
</openid>
<messaging>
<untrustedWebRequest>
<whitelistHosts>
<add name="localhost"/>
</whitelistHosts>
</untrustedWebRequest>
</messaging>
<reporting enabled="true"/>
</dotNetOpenAuth>
Updated:
it is happening on my development server, either in IIS, or when I run the ASP.NET development server.
Also, I tried running session in process and out of process using the state server, and it didn't make a difference.
In regards to a new session, I checked the session_start event, and that isn't being called. I also checked the Session.IsNewSession, and that returned false as well. So something is randomly (or maybe not so randomly) deleting my session variables!
Not the best answer, but I figured out that it's the response.redirect that is killing the session variables for some reason.
So I just made it do a javascript redirect instead, the session stays, everything works fine. Still really don't know what the real issue is here, but hey, I don't have all day to figure it out.
Found the issue here (long ago now). Apparently MVC2 didn't care if I had a view for my actions where I just did some processing then a redirect.
However starting in MVC3, after my upgrade, if I didn't have a view for my action, the page registered an error, and once there was an error, the framework did not store the session variables I just set.
So simple fix... add the views and then also make sure there are no errors in the views.
This should work. I have used DotNetOpenAuth with ASP.NET MVC 3 without any issues. You might want to check that your session doesn't expire during the user is on the remote site for authentication. The fact that you are getting the same SessionId doesn't mean that the session hasn't expired. This could also happen if the server restarts the AppDomain.
DotNetOpenAuth certainly doesn't have Session.Abandon or Session.Clear anywhere in its codebase. It seems possible that if you're setting cookies after the redirect has been sent to the client that those cookies would be lost. Session variables aren't typically persisted as cookies individually though, so if you session cookie made it (and apparently it seems to have) then the rest of your state ought to be there.
It would be interesting to dig into this by implementing your own session store and monitoring what's really going on.
I have something strange going on with our session state.
Our ASP.NET C# application has a session timeout of 10 min, but it seems to be losing session state when redirecting between pages.
So, we set out session value, and redirect to the next step,
Session["temp"] = "somevalue";
Response.Redirect("page2.aspx");
At the top of page2, we check the session value, and if it's not there, redirect back to the start (the code below is the first on Page_Load):
if (Session["temp"] == null)
{
Response.Redirect("start.aspx");
}
The issue is it keeps on doing this redirect, even though the session should not have timed out.
I have checked the config file, and it has a machinekey, as I have been informed that this can sometimes causes issues if it's not there.
Is there something else that could be causing us to lose the session?
Depending how your session's configured, cookie problems can cause you to lose session. As can switching domains / switching between http and https.
And as an aside, if you're connecting over a mobile connection, all sorts of horrible things can happen to your cookies...
Disabled Coockies may be issue. You can also create brand new application (with default web.config without any change) with single page and test it. This will tell you whether the problem is application specific or server specific.
try to add to system.webServer -> modules section in web.config next lines:
<remove name="Session" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />