We Keep Coding

ASP.NET WebForms Authentication Logout, Cookie can still be used to access site

I have been banging my head against the wall and searching the web for this but I think I am having issues understanding the whole process of logging users out of an asp.net webforms application. The issue:
I am able to log in to my application and it uses cookies, so I have my cookie set in the browser.
here is the config forms authentication section,
<forms loginUrl="login.aspx" timeout="15" protection="All" name="Domain.MYDOMAIN" path="/" domain="mysite.local" cookieless="UseDeviceProfile"/>
here is the front end control
<li><asp:LoginStatus ID="LoginStatus1" runat="server" OnLoggedOut="OnLoggedOut" /></li>
In the OnLoggedOut Method we do something like this.
protected void OnLoggedOut(object sender, EventArgs e)
{
FormsAuthentication.SignOut();
/* Abandon session object to destroy all session variables */
HttpContext.Current.Session.Clear();
HttpContext.Current.Session.Abandon();
Response.Redirect("~/login.aspx");
}
This will clear the cookies from the browser. But if before I do this I copy the cookie name pair value of Domain.MYDOMAIN = "what ever it would be"
and add that to a postman call, it is still showing me as logged in! Very frustrating.
when I am logged in
I log out using the logout button mentioned above and the cookie is removed
Then I take that cookie to Postman and make the call to the landing / default page and it is showing me as logged in still!!!
I have been reading that the cookie is related to a "ticket" but I am not sure how to expire that ticket on the server side. Once the user clicks logout I dont want this cookie value to be used again to reach a page, any page within the application. Any help would be appreciated! Thank You!
Side Note: I have my session state set to InProc
<sessionState mode="InProc" />

Ones the user is authenticate with user name and password, then we set a cookie that have a time out and this cookie let him login.
Even if you delete the cookie from one browser, if you still have it and place it again – you permit to login again because the cookie is gives the “OK” to do that.
This is not only on asp.net but everywhere (Microsoft, google, Facebook).
To add an extra layer of security, and avoid to someone steal the cookie:
First step is to force only the SSL for the cookies (*). <httpCookies httpOnlyCookies="true" requireSSL="true" />. Using that you make it difficult to impossible to steal the cookie
Second step is on logout to save that cookie on a database, then on every request check if the cookies have been logged out
Third step is to also check if the cookie come from the same browser id.
So, you connect the cookie with the browser data, and with a flag that the user press the logout.
You make that checks on global.asax
protected void Application_BeginRequest(Object sender, EventArgs e)
(*) The first step : Can some hacker steal a web browser cookie from a user and login with that name on a web site?
The difficult way is to add the database extra layer of protection and connect the cookie with other user information's as I say, the browser id, and a flag if have been logged out. The main idea is to keep on server the authenticated cookie that you have set and double check it - now you don't do that.

ASP.NET Cookie Expiration 01/01/1970

I've got a question about an ASP.NET MVC web application I wrote. More specifically, it is about the cookies the application saves. We recently discovered that the default ASP.NET Identity cookies have an expiry date in the past. For example, if you look at the ".AspNet.ExternalCookie" or ".AspNet.TwoFactorCookie", it says "expires=Thu, 01-Jan-1970 00:00:00 GMT". Here is a screenshot:
When you look at the cookies in the browser, the expiration date says "When browsing session ends". So, my question is, is it correct that the expiration date is 01/01/1970 or is this not best-practice? I read over at the owasp site (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Life_Cycle - in the Session Expiration paragraph), that you should set an expiry date in the past if you want to invalidate a cookie.
I'm not sure if I should change something in the Startup.Auth.cs or just let it go and trust Microsoft on this? What do you think?
Thank you very much,
Sascha

How to know the page on which session ended?

I am in Session_End() of Global.asax.cs
There is an operation I need to do only if the session was ended on a specific page. The parameters (sender and eventArgs) are not of any help. Is there a way to figure out last page the user was on?
Thanks in advance.

You can probably use HttpContext.Request property but not sure whether that will still be valid after session expire.
In such case, you need to explicitly write the page URL in cookies every time user request a new page. That way, even though session expires you can check the cookie object and see what was the last requested page.
General scenario, once session expires end user should be re-authenticating himself and thus you should redirect to login page directly and if you are using Forms Authentication then you can just say FormsAuthentication.RedirectToLoginPage();

You can store the URL of the last page accessed in Session with each request. That way when the session ends (global.asax Session_End) you can read what page the user had last visited before the session ended.
That's because most events are triggered by a request, but unless it's explicitly abandoned the session end is caused by a lack of activity. It's determined by the server when there hasn't been a request for a period. By definition there won't be any communication coming from the user indicating that the session is ending. They may have closed their browser five minutes ago.
(That's only if the session-state HttpSessionState.Mode property value is InProc. Otherwise the event won't fire.)

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);

How to delete facebook cookie from server side with c#?

I'm using facebook to authenticate users at my website. I need to delete facebook cookie on logout from serverside with C#. could you please show me how to do it? tested and working example

Assuming you know the name of the cookie, you can set it's expiry date to some time in the past. When the browser receives the cookie, it will see that it's expired and delete it.
If you're using a System.Web.HttpCookieCollection, this MSDN article has example code which demonstrates this (example adapted from that on MSDN):
if (Request.Cookies["NameOfFacebookCookie"] != null) {
HttpCookie myCookie = new HttpCookie("NameOfFacebookCookie");
myCookie.Expires = DateTime.Now.AddDays(-1d);
Response.Cookies.Add(myCookie);
}
Since you're authenticating users through Facebook, I'm assuming you're using OAuth. In this case, you don't know the name of the cookie, and in any case it isn't your cookie, it's set by facebook.com during the login process. To log off a user who's signed in via Facebook, see this answer.

I don't understand why I can't "comment" when, but whatever; to add to the discussion between Alexei and Cameron above, the assumption there is that the cookie is controlled by Facebook. If you used the Javascript SDK, then yes, Cameron's comment is true. However, if instead you created a manual login flow (no SDK) so that you could server-side handle the login, then you likely created your own cookie to save the retrieved access_token, and of course, you could delete that.