[CentralOH] WebPy and Cookies

[Brian Costlow]

On Mon, Sep 8, 2008 at 8:27 PM, Mark Erbaugh <mark at microenh.com> wrote:

> This is probably due to my lack of understanding.  I'm using WebPy to
> create a Python based web application.
>
> According to "Javascript: The Definitive Guide" by Flannagan:
>
> "[cookies] are still uploaded to the web server in the request for any
> web page with which they are associated."
>
> WebPy has a function to retrieve the cookies passed to the CGI app.
> Basically, that just extracts the HTTP_COOKIE environment variable. In
> my app, that is always coming back empty.


Whenever I see this kind of issue, it almost always ends up being some kind
of mismatch between the site address in the cookie, and what the server
thinks this address should be.

First make sure you are not getting some kind of subtle WebPy bug (it
happens with the best of frameworks) by setting a cookie on the server side
and reading it back.

Next set a cookie with a different name, but otherwise identical settings
from the server, and on that page, in JavaScript, and examine them both from
the client side (i.e. FireBug or similar) to see if they are otherwise
identical.




>
>
> Another thing I though I could use the cookie for is to make sure that
> the user has arrived at this page after going through the initial logon
> page. I know it's not rock-solid security, but when the user visits the
> logon page, they enter their name and password. That is then validated
> by the server which re-directs them to the application main menu. That
> main menu page creates the cookie including their user id.  I was
> thinking that if the server ever received a request for a page inside
> the application and there was no cookie (or the cookie didn't have a
> user id), the server could redirect them back to the logon screen. That
> would prevent someone bypassing the logon by entering the page address
> directly.
>

I don't know the security requirements of your site, but the first thing I
always tell people is unless the entire session is ssl encrypted, you are
subject to a possible man in the middle attack.

The larger issue with just using the user id in plaintext in a cookie, is
once a successful man in the middle occurs (or someone snoops cookies on the
users computer) they can fake the cookie and compromise your site
permanently.

You really should hash the cookie using a salt that changes.

One way is to compute a hash on every page request, keep a copy of the hash
in  local session store, and return to the browser in a cookie. On the next
request, you can make sure they match, then change the hash. However because
you must keep state on the server, this will present issues when it comes to
horizontal scaling.

Another way is to add a fixed salt and the id to a changing value such as
usertime and hash them (I've seen some folks advocating hashing that again
-- if there are any crypto guys weigh in on whether this helps or introduces
patterns). Put the time and the salt in the cookie. Then you can
reauthenticate based on the hash matching and change the hash by updating
the timestamp. There are other variations on this, such as always rounding
usertime down to the nearest hour so you don't need it in plaintext in the
cookie, that have their own pros and cons.

All of these methods are still susceptible to man in the middle, but at
least a compromise isn't permanent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/mailman/private/centraloh/attachments/20080909/8da537e7/attachment.htm>