Ttdfjt

A typical web authentication workflow looks like this:

1. User provides their credentials.


2. Server validates credentials.


3. If credentials are valid
   
   
   • Server generates a token.
   
   
   • Server keeps this token.
   
   
   • Server responds to the login with this token.
   
   


4. Browser stores token.


5. Browser makes requests with token.


6. Server validates token and responds accordingly.

Normally, this token is stored in a cookie. The presence and validity of the token in a request lets the server know if the client making the request is authenticated. No token, no entry, which is effectively the same as not being logged in. So...

• Can I just log out by wiping cookies instead of hitting logout?


• What are the issues of just wiping cookies versus clicking the logout button?

Can I just log out by wiping cookies instead of hitting logout?

Frequently yes, for the reasons you supplied in your question: Without the session token in your cookies, a typical web application won't know who you are.

What are the issues of just wiping cookies versus clicking the logout button?

Web applications that manage authentication following the OWASP session management guidelines will invalidate the session on the server side when you log out explicitly. If you simply discard the cookie with the session token, the session may be subject to session hijacking.

Using door locks as an analogy for those who are not familiar with best practices of developing web applications (thanks to discussion in the comments):

Your account can be seen as a room in a building. When you log in, the building's owner creates a door and puts an automatic lock on it, so that only you can enter. Your session token is your key, and is typically stored in your browser's cookies, but can be stored in other places.

Discarding your token by deleting your cookies, clearing cache, etc., is simply destroying your copy of the key.

Explicitly logging off is asking the building owner to brick up the doorway. There's nothing guaranteeing that they'll secure your account, but as the user, you're explicitly making your wishes known.

There are various ways that an attacker can get a copy of your key, known as session hijacking, that are the responsibility of the site owner to mitigate, not the users.

First, the attacker can just guess. If the site generates session keys sequentially, or uses a low entropy pseudorandom generation method, this makes guessing much easier. Sites mitigate this through using high entropy tokens and periodic session recycling. Recycling sessions doesn't prevent access, but it makes it obvious when unauthorized access has been granted.

Second, the attacker can use session fixation: They give you a key before you log in, which you continue to use after you've logged in. Sites mitigate this by explicitly recycling the session when you log in.

Third, a Man-in-the-Middle attack. The attacker can see your key directly. TLS mitigates this. It is possible to decrypt TLS traffic through downgrade attacks, insecure implementations, and zero-day attacks, but these are far outside a user's domain, rare, and zero-day attacks against TLS tend to raise a LOT of noise when they're discovered (Heartbleed, et al).

As a user, your responsibilities are to log off and to hold the site accountable when they take shortcuts with security, much as your responsibility with your car in a public parking lot is to lock your doors. If the door locks are trivially bypassed, then its the manufacturer's fault, not yours.

Some websites make use of non cookie based methods of storing data on a users computer, such as HTML5 local storage and flash player cache that may contain sensitive information.

For example your email client may store your draft email in local storage so that in the event you accidentally refresh the page/close the browser you will be able to resume where you left off. This sensitive data will normally be removed when you click the logout button on a well designed website and would not be removed by merely deleting your cookies.

Can I just log out by wiping cookies instead of hitting logout?

Yes,Since the web application uses cookies to uniquely identify you,deleting cookies will log you out.

What are the issues of just wiping cookies versus clicking the logout
button?

The logout button severs a special purpose that it sends a request to delete the session and returns a response to delete the cookie in your browser as well.If you dont send a request to delete the session then the session still remains alive server side.Sessions do have a maximum lifetime and will be deleted by the garbage collector eventually

There are no risks.

Someone has pointed out that it might increase the risk of session hijacking. But that is not true. If the application has session (is stateful), this session has a timeout. And after session expires there is nothing to hijack. If session is active, then the chances to hijack a session of an active user are are almost the same as for a "orphaned" session. Taking into account tools that quickly detect multiple request with invalid session IDs of somebody who tries to brute force session ID, there is no additional risk on the server side.

On the client side there can be more risk in case of log out than in case of deleting cookies. Log out invalidates session, but can keep some other sensitive data. For instance, when you log out from Google Mail, your user name is still kept in cookies; and when you go to Google Mail, you will see your user name prefilled. First, may be you don't want anybody behind your shoulder to see this user ID. Second, if in hurry, you may log in into a wrong account (of your multiple accounts). Similar problems may happen in other applications. Where as when you delete cookies your are sure there is nothing kept in your browser what you are not aware of; you will not be surprised by any data stored in cookies. So actually in case of log out the risk of negative surprises is higher than in case of deleting cookies. I have to say that when one deletes cookies one should also consider deleting local storage.

A single disadvantage that I see in case of deleting cookies is that server will use slightly more resources to keep session data until session is time out. But the question in OP is about risks for the client. So there are no risks. And now days the most applications have no state on the server; logging out means in such case just invalidating the token; there are often no resources blocked by session. So even "orphaned" session doesn't take any additional resources.

One more aspect to consider: Depending on application and on internet connection, logging out may take considerable time, a couple of seconds. Where as deleting cookies (and local storage) happens immediately and does not depend on server and on internet connection.

May be somebody will find other important points that I overlooked and will criticize my point of view. That's fine. I just wanted to encourage users not to follow any rules blindly, but to think about what is happening actually.

There is also the risk that you forget the password, although this is more likely to be an issue for someone who only rarely needs it not every session they go to a particular site.