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_at_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
-------------------------------------------------------------------------
Received on Dec 05 2007
Intro
