[Ur] Securing sessions in Ur/Web

[Adam Chlipala]

On 1/18/19 10:14 AM, Simon Van Casteren wrote:
> When a person logs in, username-password style, I make a cookie with 
> this form:
>
> { Role: <ADT, admin or not basically>
> , Email: string
> , CreatedOn: time}
>
> I'm saving the role in the cookie, so subsequent security checks in 
> the page generators and rpc functions don't need to hit the database.
Actually, that's an insecure method.  The Ur/Web implementation is not 
meant to prevent cookie forgery!  Rather, it just tries to make sure any 
side-effecting operation that reads a cookie was triggered by an 
explicit form submission within your application (that's XSRF protection).
> 1. Is this safe? Is this a good solution? Or am I better off 
> abandoning the whole thing and going back to putting just a SessionId 
> inside a cookie and going to the database with that SessionId to check 
> for authorization? Or another solution that I'm not thinking of at the 
> moment?

Creating a unique and effectively unguessable session identifier to 
store in the database is a pretty good solution.  Actually, however, I 
recommend avoiding implementing your own authentication whenever 
possible!  You could consider using the Ur/Web World library 
<https://github.com/urweb/world>, which is growing in a lazy manner, as 
different usage modes are requested.  Specifically, it's only been used 
for authentication via GitHub, as far as I know.

Passwords are just a sordid business, so best to avoid or at least push 
off onto some other web service, IMO.

> 2. A problem I'm having is storing the key that is needed to run the 
> digest. My plan was to pass it via an environment variable to my 
> program, but getenv inside a page generator causes the compiler to 
> complain, saying that it could cause side-effects... Anybody have any 
> ideas how to handle this? I feel like putting my key in plain text 
> inside my source code is not very good, but maybe I'm wrong about that?

I don't see a fundamental security advantage of a sensitive value in a 
source file (and therefore compiled into the application) vs. in an 
environment variable (and therefore presumably appearing as plaintext in 
a script somewhere to set the variable).  I would even think there is a 
teeny bit of extra security in compiling the key into a binary on a 
build machine and then uploading the binary to a server that will only 
have the key appearing in the binary instead of a more-easily-viewed 
text file.  (Of course, even a modestly sophisticated adversary can grab 
a password out of a binary.)

However... it was an oversight that the compiler didn't recognize getenv 
as having only benign effects!  I believe I have fixed that issue now in 
the compiler, so please let me know if that method hasn't switched to 
working.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20190120/d4eed8bb/attachment.html>