We Keep Coding

.net core 2.2 Session logout

So I have a problem with my session logout. After 20 minutes I get redirected to the home page of my website.
I've looked at Session Services but they all show ways to use the session timeout to make it so a label name or id just goes away after the set time. How do I change the Session timeout from default to any other time. I've added
services.AddSession(opts =>
{
opts.IdleTimeout = TimeSpan.FromSeconds(10);
});
to my Startup.cs folder and added app.UseSession() to the Configure but the timeout doesn't time me out in 10 seconds.
I know inside asp.net there is a web.config file that you can set the timeout time in my .net core doesn't have a web.config.

GDPR (no, seriously).
Core 2.1 introduced some tooling that assists with GDPR compliance by not storing non-essential cookies until a user consents to cookie storage. Unfortunately session state uses cookies, and since session state is used for all sorts of things, MS defaulted session state cookies to non-essential.
The easiest way to fix this is to implement the cookie consent form and accept it, but there are other workarounds that can be found here.

Is it possible to persist cookies between visual studio debug sessions

I have an authentication cookie that gets set after I hit a login screen in my local environment. That cookie has been set to be persistent and has been given a timeout period of 7 days in the future.
When I end my debug session and start debugging after another build the cookie is not present. This happens for every browser. Is there a way to get Visual Studio to remember the persistent cookie after a debug session completes?

The solution I found was to make it so that new instances of .NET Core MVC would not open up in a brand new window, but an existing one. I changed one setting
1)Tools menu
2)Options...
3)Debugging > General
4)Uncheck "Enable JavaScript debugging for ASP.NET"
And when I run the app with F5 an instance fires up in an existing instance of chrome and I can reuse the cookies that are already in existence. With that box checked it always opens into a new instance of chrome and cookies are not present.

Assuming you are using VS and ASPNet 4.5 or core 1.0/2.0 under IIS, check your debug output on start up and you might see :
“Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.”
This is caused by the DataProtection keys used by IIS. Follow this short blog post to resolve

Let’s have a quick look how to make cookies as persistent
//Creting a Cookie Object
HttpCookie _userInfoCookies = new HttpCookie("UserInfo");
//Setting values inside it
_userInfoCookies["UserName"] = "Abhijit";
_userInfoCookies["UserColor"] = "Red";
_userInfoCookies["Expire"] = "5 Days";
//Adding Expire Time of cookies
_userInfoCookies.Expires = DateTime.Now.AddDays(5);
//Adding cookies to current web response
Response.Cookies.Add(_userInfoCookies);
Now once you have set with the Cookies expires time , it will be stored in hard drive until expires or user manually delete or clear all the cookies. If you want your cookies need to be expires before the expiration time that you have mentioned earlier, you just need to override the cookies information.
HttpCookie _userInfoCookies = new HttpCookie("UserInfo");
//Adding Expire Time of cookies before existing cookies time
_userInfoCookies.Expires = DateTime.Now.AddDays(-1);
//Adding cookies to current web response
Response.Cookies.Add(_userInfoCookies);
So Just Work on Expiration.
and take a look at This

Webapi oauth accestoken invalid expiration date

We are building a frontend application that is making extensive use of an webapi backend.
In this application we are using oauth to log a user in and store all of the claims that belong to that user inside off access tokens.
On the frontend we are using sentry error logging (http://www.getsentry.com) to log all of our javascript errors. This includes any webapi calls that somehow went wrong or do not return the result we are expecting. With every error we recieve we also log the cookie information along with it, which includes the access tokens that that specific user was using at that time.
Right now we are seeing alot of webapi calls that went wrong because the calls they made are forbidden. I checked some of their access tokens and immeadiately i noticed that the information was way out of date and should have been refreshed a long time ago because the access token should have expired already.
By using :
var ticket = Startup.OAuthOptions.AccessTokenFormat.Unprotect("tokenhere");
on my localhost machine inside the debugger i can unprotect the access tokens and view the information inside of them.
Like i said the information inside some of these tokens contains invalid information and should have been refreshed already..
Then i noticed that the reason they are not refreshed yet is because the ExpiresUtc is more than 2 years bigger than the IssuedUtc. In other words; The token wont expire until after 2 years.
Here is some example information of one of these tokens
IssuedUtc: { 20/02/2016 03:04:40 +00:00}
ExpiresUtc: {16/11/2018 03:04:40 +00:00}
We are using the default expire time from oauth (20 minutes) and somehow in the pipeline it is setting it to be bigger than 2 years. The only way a user can now refresh their claims is if he logs out and back in again, and obviously until they do so it is creating alot of errors on the frontend side.
By debugging my own tokens i can verify that it is setting it to 20 minutes and have never managed to reproduce it myself.

Solved, we had an controller method hidden somewhere that was issueing access tokens with an expiry date of 2 years.. Doh

invalidate aspx authentication cookie

I have an asp.net web form. when a user authenticate, it create a Secured cookie called .aspxauth
uppon logout, I call these 2 methods
FormsAuthentication.SignOut();
Session.Abandon()
Problem is that we had penetration test and if I steal the cookie, logout and manually reinsert the cookie, I become loggued in again. So the .aspauth isn't invalidated server side.
I've googled it and I can't find the answer to that security breach.

Microsoft has acknowledged this issue here: https://support.microsoft.com/en-us/kb/900111
They offer several ideas for mitigating this vulnerability:
protect the application by using SSL
Enforce TTL and absolute expiration
Use HttpOnly cookies and forms authentication in ASP.NET 2.0
Use the Membership class in ASP.NET 2.0
Regarding the last one, I'll paste the contents from the site for convenience/preservation:
When you implement forms authentication in ASP.NET 2.0, you have the option of storing user information in a Membership provider. This option is a new feature that is introduced in ASP.NET 2.0. The MembershipUser object contains specific users.
If the user is logged in, you can store this information in the Comment property of the MembershipUser object. If you use this property, you can develop a mechanism to reduce cookie replay issues in ASP.NET 2.0. This mechanism would follow these steps:
You create an HttpModule that hooks the PostAuthenticateRequest event.
If a FormsIdentity object is in the HttpContext.User property, the FormsAuthenticationModule class recognizes the forms authentication ticket as valid.
Then, the custom HttpModule class obtains a reference to the MembershipUser instance that is associated with the authenticated user.
You examine the Comment property to determine whether the user is currently logged in.
Important: You must store information in the Comment property that indicates when the user explicitly signed out. Also, you must clear the information that is in the Comment property when the customer eventually signs in again.
If the user is not currently logged in as indicated by the Comment property, you must take the following actions:
Clear the cookie.
Set the Response.Status property to 401.
Make a call to the Response.End method that will implicitly redirect the request to the logon page.
By using this method, the forms authentication cookie will only be accepted if the user has not been explicitly signed out and the forms authentication ticket has not yet expired.

Read this article about Session fixation and how to get rid of it once and for all:
http://www.dotnetfunda.com/articles/show/1395/how-to-avoid-the-session-fixation-vulnerability-in-aspnet

This remains an issue in .NET Framework. Everyone seems to think Session.Abandon() is the answer, but the sad truth is that command does not invalidate the session on the server's side. Anyone with the right token value can still resurrect a dead session, until the session expires based on the Web.config settings (default = 20minutes).
A similar questioner posed this question a long time ago here:
Session Fixation in ASP.NET
Most of those links are dead, and Microsoft has no new news on the topic.
https://forums.asp.net/t/2154458.aspx?Preventing+Cookie+Replay+Attacks+MS+support+article+is+now+a+dead+link
Worse still, you're still vulnerable to this cookie replay attack even if you're implementing a completely stateless MVC application and don't use the Session object to store data between views. You can even turn off session state in the web.config settings and still replay cookies to gain access to a logged-out session.
The true solution is hack-y and described here, and you need to have session data enabled InProc to use it.
When the user logs in, set a boolean value in the session data, like Session["LoggedIn"] = true;, which is stored on the server side.
When the user logs out, set that value to false.
Check the session value on every request--an attacker trying to replay a session isn't going to be nice to you and come in through the Login page only. It's probably easiest to do this using a custom filter and registering it globally in the global.asax file (so you don't have to duplicate the code everywhere, or attribute every controller/method).
Even if the attacker has all the cookie values, they won't be able to re-use that same session ID, and the server will automatically delete it once it reaches the specified timeout.

if you are using the FormsAuthentication, you can use this code. By using this code you can destroy the created cookies by setting the Expire property of HttpCookie. It will help you:
FormsAuthentication.SignOut();
Session.Clear();
Session.Abandon();
Session.RemoveAll();
// clear authentication cookie
HttpCookie httpCookie = new HttpCookie(FormsAuthentication.FormsCookieName, "");
httpCookie.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(httpCookie);

Testers says __RequestVerificationToken_Lw__ cookies should be expired on logout?

I am working on a MVC 4 web site, tester has informed me on Logout .ASPXAUTH cookies expired automatically but RequestVerificationToken_Lw cookies do not expires.
I am not sure is RequestVerificationToken_Lw suppose to expire on logout ? On logout user is returned to logon page which do not have Html.AntiForgeryToken() used in it. Any guidline please how I can set RequestVerificationToken_Lw to be expired on logout ?
Thanks for your help and guidance.

Why you need VerificationToken for the logout , its dont have any sense.. This is just protecting vs cross-site-scripting and fired all time when something changes in Cookie objects like FormAuthenticated values or some form data just it.

I just set this cookie to be expired as a normal cookie by setting its expiry date to -1d.