Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
For any nonsense or banter that doesn't fit anywhere else. LoL! omg! ROFL! 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Consequences of user credentials not expiring on the client side?
Posted by: kuza55
Date: March 15, 2007 04:04AM

I was reading a book on web app security, and came along the following snippet:

"Does the Client Store the Token After the Session Ends?

This is a problem because the user may be connecting from a shared computer. The client's browser stores persistent cookies, keeps a history of URLs, and caches visited pages, making this a challenge for all types of tokens."

And either I'm missing something, or this is not really much of a threat. (Frankly, the browser has a cache of all the pages viewed, which is something much more harmful, IMO)

As I see it, if you only store a session identifier (you do only store an identifier, right?) then there is no way to use that session identifier for anything, since it should be completely random.

I understand that some sites store other things in Javascript, and this could be a threat to those, but I just want to check that I am not missing any other issues that may arise from this which would affect web apps.

[EDIT]: P.S. The extremely short snippet above is the ONLY mention I could find in the book, which is why I'm asking.



Edited 1 time(s). Last edit at 03/15/2007 04:05AM by kuza55.

Options: ReplyQuote
Re: Consequences of user credentials not expiring on the client side?
Posted by: rsnake
Date: March 15, 2007 12:18PM

Even if you tell the browser not to cache it could still keep the cookies. Maybe that's what they are saying. Who knows? In general if you are using a shared computer you are pretty owned no matter what you do.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Consequences of user credentials not expiring on the client side?
Posted by: thrill
Date: March 15, 2007 12:23PM

Actually, if you run a site that involves a database, you could set the state of the user on both a cookie and the database.. unless they match, the user shouldn't be allowed to browse because even if the cookie is reset and/or deleted, we know that's easily fixed by someone like you.. :)

--thrill

Options: ReplyQuote


Sorry, only registered users may post in this forum.