WebApp Sec mailing list archives
Re: Session security with cookies
From: Aaron Shelmire <shelmire () psc edu>
Date: Thu, 06 Dec 2007 16:48:40 -0500
Hi all, Not to add another Aaron to the conversation, polluting the namespace and all, but my thoughts on the problem at hand. I don't see what keeping any of the cookie attributes secret buys you. I only see the need to make sure the integrity of the packet is the same, and to authenticate that the data came from the server. I also don't see any reason why there needs to be a key known by the client, or why there needs to be a key assigned to the client. As a proposal to resolve this, consider the following. For the example cookie without protection we have the attributes SessionID TimestampServer ItemPrice ItemQuantity ItemID OtherData Suppose we want to be able to deliver that information in the cookie, without worrying about the ItemPrice being changed and that the item price is still tied to the correct item. We also want to make the cookie short lived, which will require us to rely upon the TimestampServer field which we want to assure will not be altered. We don't want the sessionID to be changed. The entity that is generating this data, and the entity that is checking the data as it receives it to assure it hasn't been changed are one and the same. So why not use a message authentication code such that the cookie is now... SessionID TimestampServer ItemPrice ItemQuantity ItemID OtherData MAC( SessionID, TimestampServer, ItemPrice, ItemQuantity) under KeyServer. The server now only needs to keep the key a secret locally, and doesn't need to share it. Additionally MAC's are created using symmetric key encryption, meaning the operation is much faster than the encryption under the public key, and encryption under the private key(the signature). It may not be as fast as a hash but a hash doesn't tie the hashing function to any entity. The hashing function would be publicly known, and therefore anyone could take the cookie, edit the data, and generate a new hash. Whereas a MAC is only generated by those who know the secret key. We still allow the client to read all of the data in the cookie. Furthermore some information may still be edited, such as the ItemQuantity. Now suppose we want to tie this cookie to a particular Client and Server (and therefore don't want that information to be altered), This can be simply acheived with by adding information to specifically name that client and to identify the server for which it is bound such that the cookie now contains ClientID ServerID SessionID TimestampServer ItemPrice ItemQuantity ItemID OtherData MAC( ClientID, ServerID, SessionID, TimestampServer, ItemPrice, ItemQuantity) under KeyServer. Where ClientID is whatever you decide is best (perhaps userid concatenated with IP). The same with ServerID. Although I may have just screwed this up, since the ServerID can't be verified by client since it doesn't share the key used to verify the MAC. Although I know there was a reason I thought of it this way but have forgotten now. (I hatched this plan while riding and as such didn't write it down). There Server can identity that the data was bound for it, although it is able to do that via verification of the MAC so long as the secret key is only known by it and the encryption algorithm is secure (which if either is not the entire scheme fails). Thoughts? -aaron Aaron Katz wrote:
Till, Thank you for the clarification. There's another important question to answer: does the experience have to be a standard, transparent experience, or can you be a little more visible to the user? If you don't mind being less transparent, you could require the user run some additional software on their system. For example, you could implement your site in Flash, then use the Flash applet to tightly bind to the user's system. Of course, an insecure client running malware will still be able to intercept the session cookie, but the flash client could require certain software be running, such as antivirus software. There are problems with this, of course. There is some set of users (like myself) who don't run anything with flash - if I go to a website that is implemented in flash, I make every effort to go to a competitor. There's also a concern of privacy - the flash applet will need to bind itself to the client, in a manner that the server can confirm, without providing that private information to the server. Of course, malware can identify those same bindings, and an attacker can use a virtualized environment (with some effort) to reproduce those bindings. And there's the consideration that, if you're forcing customers to run additional software (AV software), your customers may not want to spend the time and money to on such software, and you may drive away business. You either have to trust your client, or not accept connections from that client. Someone smarter than myself might be able to solve this for you, but I don't see any way to trust a client with access while not trusting them with any way to gain access. Then, there's the consideration that we're focusing on a very small part of the whole picture. The session cookie is just like the user's password, where stealing it would give the attacker access, but it's not the only way to mitigate risk - and the degree of risk hasn't even been identified. What is the liklihood that the software will be attacked? What is the value of the software being attacked? What is the value of that which it protects? What are the real risks involved in a stolen session cookie? Is this an administrator's session cookie (where you _can_ add/recommend restrictions on sanitary browsing and hardened systems) or is it strictly user machines, which you cannot control? Are there any other means to mitigate risk (audit logs, IDS/IPS, canceling orders, blocking known bad IP blocks at the router, requiring acceptance of customer agreements, only sign up customers that etc.)? In the end, either you'll need to come up with an entirely new paradigm, or I think you'll need to further analyze (and quantify) this particular risk, and either accept it or find other ways to mitigate it. -- Aaron On Dec 5, 2007 5:48 AM, Till Elsner <till.elsner () uni-duesseldorf de> wrote:Hi Aaron, sorry if I didn't define the problem clearly enough. The only thing I'm talking about is session cookies, I just want to identify the user from login to logout. Short lifetimes for the cookie shouldn't be a problem. The environment would be the worst to think of, namely the internet. The is why I can't rely on the clients to secure their data. The data are client information in an online shop, so it includes some sensible data as well as things like shopping cards. All I want is to create cookies that will be unusable for a potential thief, since I guess I haven't the means to ensure the cookie won't be stolen from the clients computer. So basically my only question is if a short lifetime is the only way to protect me (and the client and its data) from the misuse of stolen cookies (at least for the time after the cookie has expired). Till Am 05.12.2007 um 06:04 schrieb Aaron Katz:So you're trying to somehow prevent cookies from being stolen, after they've been transmitted to the client. Are you talking about session cookies, or about cookies that persist data (sorry, I'm still not clear on the scope of the problem)? If you're trying to solve the problem of stolen session ids, as stored in cookies on the user's system, whether in memory or on disk, I'm not really sure what you can do. I mean, there are the standard things of marking it secure, so it shouldn't be sent without SSL; giving the cookie a short lifetime, so that stealing it is only useful for a short period of time; setting the various no-cache settings to keep it in RAM (or the page file); and, if the problem space is small enough (and the network in which the solution is provided is under strict enough control) you may be able to rely on IP addresses and such, but these (recommended) tacks only shrink the problem space to what you already seem to be considering: the security of an untrusted client. And they rely on the client behaving properly - it's always possible for a client to intentionally or unintentionally ignore the server's directives. Protecting session cookies with cryptography seems to be trying to allow a client to connect to a server and access that server's resources, without actually letting the client know the secret (the session ID) that identifies the client to the server. This would require sending the session cookie to the client, but not actually telling the client the raw session ID. As I mentioned, before, without tightly binding the cookie to the client, in some other way, the cookie can simply be replayed from another system. The only reason I can see for encrypting a session cookie is if the server doesn't trust the client - if the security of the client is not sufficient to protect the cookie. But, if the security isn't enough to protect the cookie, why would the security be strong enough to protect the encrypted/signed cookie? And, if it's not enough to protect the encrypted/signed cookie, why would it be enough to protect any data used to tightly bind the cookie to the client? If you're trying to solve persistent data, related to the user account, but stored on the client system, that problem seems solvable via cryptography. A key could be generated for each user. A particular user's key could be used to encrypt/sign the data before sending it to the client as a cookie. The key could then be used to decrypt/check the data when received by the server. Of course, this still requires the server to know which key to use, and still depends upon the security of the session. The big problem with this would be that cryptography is generally pretty slow, and servers need to be very responsive. If every request from every client requires the cookie be decrypted, reformed, and re-encrypted, this could be a huge drain on the server. The performance penalty would be highly dependent on the information being stored in the cookie. Additionally, it may be simpler to just store the data on the server - is there any reason why the information cannot be stored server side? I guess the problem still needs to be better defined. What is the environment? Is it the Internet, a home network, or a corporate network? What data is being protected? Is it just a shopping cart, or is it something that has extra storage restrictions, such as credit cards? What services does the server provide, and why can't the data be stored on the server (of course, if this is the session cookie, the answer would be self-evident)? -- Aaron On Dec 4, 2007 6:48 PM, Till Elsner <till.elsner@uni- duesseldorf.de> wrote:Hi Aaron, the second problem you're mentioning is definitely the one i'm more worrying about. In my eyes generating an ID the not (easily) pedictable is a solvable problem, but a stolen cookie is another thing. I think it would be okay for me to use short-living cookies, but i wonder if this is the only secure way to protect users from suffering from stolen cookies. Till Am 04.12.2007 um 23:13 schrieb Aaron Katz:Ron, It's unclear exactly what problem you're trying to solve. Encrypting & signing the cookie may stop tampering, but it won't prevent stealing the cookie and replaying it. So, you've basically got two types of data that might be in the cookie: the session identifier, or the state. In either case, you have to decide whether or not to tie the cookie to the client. If you don't tie the cookie to the client, (or possibly the current time, with a very short timeout, and automated replacement), then nothing prevents replay of the cookie. If you tie the cookie to the client, you've got the problem of uniquely identifying the client. You've got to use stuff that's available to the server, so that the server can confirm the cookie. The obvious ideas would be IP address, user agent, and such, but these don't seem to work very well. The IP address can be "duplicated" for multiple clients (NAT), and can theoretically change at inopportune times (DHCP). User agent agent isn't unique, and provides such little entropy (most people choose from the same small set of browsers (IE, Fx, Mozilla, Opera, Lynx)) that the dictionary attack to discover it is so easily overcome that it's probably not worth the effort. The problem of uniquely tying the cookie to the client seems to rely upon the problem of uniquely identifying the client. Uniquely identifying the client is what the session cookie is trying to solve. To improve this, you might consider client certificates, but that comes with its own problems. If you're tying the cookie to the current time (directly, by time stamp, or indirectly, if you choose to include the session identifier in a cookie that contains state), then you have to be sure that the cookie doesn't contain anything that absolutely must live longer than the timeout. For example, some shopping carts retain their content, between multiple sessions. Also, in some cases, it may be entirely appropriate to allow tampering (I can't think of one off the top of my head, but it seems like a reasonable assumption that this would be good, in some cases). As implied, above, it would be easier to comment on your thoughts if you identify the problem that you're trying to solve :) -- Aaron On Dec 4, 2007 1:47 PM, Ron <ronlists () skullsecurity com> wrote:Something I've recently been toying with is the idea of encrypting/signing cookies with a private key on the server. The the cookies can't be read or tampered with by the user, nor can they be stolen by cross-site attacks and the like. This isn't something I've done a lot of work with, however, so I may be missing something obvious, and am open to comments on the idea. Ron Till Elsner wrote:Hi, i'm investigating in web application security this time and i'm trying to find some information about session management with cookies and related security issues. Can anyone point me to tips on how to make cookie based sessions more secure and how to prevent session hijacking? How secure is session handling using cookies and what are the main risks? Is anyone aware of good literature on that topic? Thanks and have a nice day Till ------------------------------------------------------------------ -- ----- Sponsored by: WatchfireMethodologies & Tools for Web Application Security AssessmentWith the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx? id=70170000000940F ------------------------------------------------------------------ -- ------------------------------------------------------------------------ -- ---- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx? id=70170000000940F ------------------------------------------------------------------- -- ------------------------------------------------------------------------ -- --- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx? id=70170000000940F -------------------------------------------------------------------- -- ---------------------------------------------------------------------------- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F -------------------------------------------------------------------------
------------------------------------------------------------------------- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F -------------------------------------------------------------------------
Current thread:
- Re: Session security with cookies, (continued)
- Re: Session security with cookies Aaron Katz (Dec 05)
- Re: Session security with cookies Aaron Katz (Dec 05)
- Re: Session security with cookies Vicente Aguilera (Dec 05)
- RE: Session security with cookies WebAppSec (Dec 08)
- Re: Session security with cookies Ron (Dec 04)
- Re: Session security with cookies Aaron Katz (Dec 04)
- Re: Session security with cookies Till Elsner (Dec 05)
- Re: Session security with cookies Aaron Katz (Dec 05)
- Re: Session security with cookies Till Elsner (Dec 05)
- Re: Session security with cookies Aaron Katz (Dec 05)
- Re: Session security with cookies Aaron Shelmire (Dec 08)
- Re: Session security with cookies Eduardo Tongson (Dec 08)
- Cryptographically Generated Cookies Paul Johnston (Dec 12)
- Re: Cryptographically Generated Cookies Andy Steingruebl (Dec 14)
- Re: Cryptographically Generated Cookies Jamie Riden (Dec 14)
- Re: Session security with cookies Aaron Katz (Dec 04)
- RE: Session security with cookies Martin O'Neal (Dec 12)
- Re: Session security with cookies Scott C. Sanchez (Dec 04)
- RE: Session security with cookies Martin O'Neal (Dec 05)