[Owasp-testing] Copy Cookies

dinis cruz dinis.cruz at owasp.org
Thu Jul 22 04:26:15 EDT 2010


Hey Dave, you're providing great guidance, but do you have a place we can
point developers to get UnitTests to check for the correct implementation of
these? (these unit tests should test from the browser point of view and the
correct source-code implementation).

The developers would customize these UnitTests to their app, but don't you
think that we need to show them working examples of these recomendations?

Dinis Cruz


On 22 July 2010 08:50, Dave van Stein <dvstein at gmail.com> wrote:

> Assuming you are talking about some sort of session token in the cookie
> that can be reused on another client some other relevant tips from
> http://www.owasp.org/index.php/Session_Management
>  All session tokens in high value applications SHOULD be tied to a
> specific HTTP client instance (session identifier and IP address).
> Application servers SHOULD use private temporary file areas per
> client/application to store session data.
> All applications SHOULD use a cryptographically secure page or form nonce
> in a hidden form field.
> Each form or page nonce SHOULD be removed from the active list as soon as
> it is submitted.
>  Session tokens should be regenerated prior to any significant high value
> transaction.
> In high-value applications, session tokens should be regenerated after a
> certain number of requests.
> In high-value applications, session tokens should be regenerated after a
> certain period of time.
>
> In general you can say the less predictable a session token is, the more
> secure it is.
> So to make your appplication as secure as possible:
> - make it difficult to predict
> - link it to the client with an difficult to predict property
> - reuse each token as little as possible and regenerate as often as
> possible
> - make use of a second (unpredictable) token and validate and reissue that
> for every request (also helps against CSRF)
>
> regards, Dave
>
>
>
> 2010/7/22 Nam T. Nguyen <namn at bluemoon.com.vn>
>
> A few ways:
>>
>> 1. Embed some specific information such as REMOTE_ADDRESS into the cookie.
>>
>> 2. It is unclear whether the cookie stores username/password. If it does,
>> DON'T.
>>
>> 3. Give the cookie a shorter time out.
>>
>> Well, these don't complete solve the problem. But they will help limit the
>> possibilities.
>>
>> Besides, if one can obtain a cookie, he pretty much can do anything else.
>> That's how CSS and CSRF works, isn't it? In your case, this requires access
>> to that particular machine (to __copy the cookies__). You have a bigger
>> problem to worry about then.
>>
>> Cheers
>> Nam
>>
>> On Jul 22, 2010, at 10:03 AM, Zaki Akhmad wrote:
>>
>> > Hello,
>> >
>> > I found the web application that I test is vulnerable with its
>> > cookies. After I successfully login with userid and password provided,
>> > I can copy the cookies to another browser/computer so that he/she can
>> > enter the web application without login.
>> >
>> > How do I fix this vulnerability?
>> >
>> > Thanks!
>> > --
>> > Zaki Akhmad
>> > _______________________________________________
>> > Owasp-testing mailing list
>> > Owasp-testing at lists.owasp.org
>> > https://lists.owasp.org/mailman/listinfo/owasp-testing
>>
>> Nam Nguyen, CISA, CISSP, CSSLP
>> Blue Moon Consulting Co., Ltd.
>> http://www.bluemoon.com.vn
>>
>> _______________________________________________
>> Owasp-testing mailing list
>> Owasp-testing at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-testing
>>
>
>
> _______________________________________________
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-testing
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-testing/attachments/20100722/dad0dd02/attachment.html 


More information about the Owasp-testing mailing list