I can't address all of the considerations you raise, but I can report on a bit of experience using stateless #lang web-server servlets. (I have no real experience with the stateful version, which I believe presents different considerations.)
My understanding is that continuation URIs are not intended to be secret/protected by default, just as a URI like https://example.com/comment/confirm?post-id=12345&body=My+great+comment doesn't include any security measures. The main way to add security to the URIs, as I understand it, it through the "stuffer" interface. Using `HMAC-SHA1-stuffer` ( http://docs.racket-lang.org/web-server/stateless.html#%28def._%28%28lib._web-server%2Fstuffers%2Fhmac-sha1..rkt%29._.H.M.A.C-.S.H.A1-stuffer%29%29) signs the continuation URI to prevent tampering with the contents of the represented continuation, and functions like `hash-stuffer` could be used to create a stuffer that prevents end-users from inspecting the contents, though I haven't needed to do this. I haven't tried to use "stuffers" to enforce authentication or authorization requirements, though it might be a good idea. When I've needed authentication, I've taken inspiration from the web-server/dispatchers/dispatch-passwords module ( http://docs.racket-lang.org/web-server-internal/dispatch-passwords.html), which implements HTTP basic authentication with a function that wraps a dispatcher. Because the UX for basic auth is not great for end-users, I've made somewhat analogous dispatcher-wrappers based on the web-server/http/id-cookie library ( http://docs.racket-lang.org/web-server/http.html#%28part._id-cookie%29). I am very eager to hear other people's approaches, though, or flaws in what I've been doing! I've used #lang web-server in several projects, most extensively Digital Ricoeur (https://digitalricoeur.org/), and I've found it an absolute delight to work with, especially coming from a CGI background and having spent way too much time doing what I now realize was manually serializing continuations. Really the only drawback is that the community is small, which at times makes it hard to get a sense of best practices. Most of my #lang web-server code isn't public yet, but I'd love to factor out reusable parts and try to lower the barriers to entry for others. -Philip On Sat, Sep 1, 2018 at 8:06 PM Christopher Lemmer Webber < cweb...@dustycloud.org> wrote: > I appreciate the goal of the continuation web server in Racket as trying > to avoid the "inversion of control" problem which plagues much web > development. But I wonder if the default continuation web server is > very secure? > > Looking at the URI generated by the continuation web server... > > http://localhost:34691/servlets/standalone.rkt;(("k" . "(1 1 2810783)")) > > That's the id used to retrieve the continuation, right? Presumably this > is effectively the session of something someone is doing that's > important. This doesn't look very high entropy... I'm guessing I could > manage to intercept someone's continuation/session. A very large random > number would be needed to prevent this. > > Even then, keeping random identifiers "secret" is not easy due to > unfortunate ways the web has developed. For more on why: > > https://www.w3.org/TR/capability-urls/ > > Referer headers are especially nasty in this way. > > Waterken uses URI fragments to get around this in a secure way, since > browsers do not transmit the URI fragment to the server: > > http://waterken.sourceforge.net/web-key/ > > Unfortunately, in order to do this it must do its protocol over an > AJAX'y (or equivalent) type dynamic client interface, which is > frequently undesirable. > > It seems to me like the continuation web server can be used for cool > demos and low-security projects, but the continuation system is probably > not very safe for most production deployment? I wish this weren't the > conclusion I was drawing, as the design seems quite nice. > > Another way to get around this design problem would be to use cookies, > maybe signed if necessary (not sure it would be, since a large opaque > bearer token may be sufficient). I am not a huge fan of that design in > some ways but it may be the best option available given the options > available within the insecurity of modern web browser design. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
