[plt-scheme] Looking for a security consultant with PLT web server experience

Neil Van Dyke wrote:
> YC wrote :
>> Another thing to be thinking about for stateful servlet is that the  
>> url is the key to the continuation. As long as the continuation is  
>> live, people can email urls to another person, and the other person  
>> will get to the exact same page.  Depending on the link in question  
>> - it can be a security issue.  If you want to add additional check  
>> such as verifying IP address (which doesn't work for customers  
>> behind an anonymous proxy) you'll have to build your own  
>> abstractions on top of send/suspend and co.
>
> To add to this, checking IP address provides a check that might give  
> a tiny bit more confidence, but it's not a solid security solution,  
> and fails in a variety of situations more common than anon proxies  
> (NAT, firewalls, shared machines, hijacked wire links, some wireless  
> roaming...).

I've been thinking about this one recently. I'm no expert in TCP/IP -  
is IP checking something that's reliable enough to be built into the  
web server (say, into the LRU)? You say it's not a solid security  
option, but I'm guessing it only ever produces false positives. If it  
doesn't produce false negatives, could it be built right in without  
fear of locking users out of their own continuations?

> Unless you always pair a continuation ID with an authentication  
> mechanism (or perhaps the continuation ID *is* the authentication  
> token), putting the ID in the URL exposes it a lot of places that  
> cookies do not, including on the link and in various HTTP proxies  
> and logs that look at requests.  Even if you use SSL, I don't have  
> 100% trust that the URLs themselves are hidden, as some browsers  
> will leak request URLs in the clear under some circumstances.

I only currently know about the stateful model, in which a  
continuation is associated with three numbers embedded into the URL:

   - a sequentially assigned "instance id", which corresponds to a  
chain of continuations created from a specific initial HTTP request;
   - a sequentially assigned "continuation id", which points to a  
continuation inside the instance;
   - a random "salt" number, which prevents accidental reloading of  
continuations created in old runs of the web server.

The salt is the thing that provides the security here. AFAIK it's just  
a regular random number with no particular emphasis on security. If  
that wasn't secure enough, I guess you could increase the size or  
randomness of the salt.

> I'm sure that Untyped or YC could investigate these concerns and  
> address if necessary.  Full disclosure: Untyped and I have  
> collaborated a bit, and I hope to work with them more in the  
> future.  (I'm not soliciting new consulting work myself right now,  
> as my university term appointment gets first priority on my time,  
> except for at 2am Saturday night. :)

One nice thing about the web server architecture is that all of these  
issues can be addressed (if they need to be addressed) by writing and  
plugging in a custom continuation manager. The Untypers have dabbled  
with the LRU manager a few times, implementing things like extra  
logging and some application specific continuation management. These  
security-related features seem like other natural extensions.

It'd be good to collaborate on something like this as and release it  
as a PLaneT package.

Cheers,

-- Dave