Re: [racket-users] Security of continuation web server?
Christopher Lemmer Webber wrote on 09/03/2018 06:18 AM: https://docs.racket-lang.org/web-server/faq.html#%28part._.What_special_considerations_are_there_for_security_with_the_.Web_.Server_%29 (I agree with the FAQ btw that a cookie-based approach has major downsides fwiw.) For a credible authentication session that works with current browsers, today,[1] I think you'll probably end up making cookies a part of it. HTTP Basic authentication has limited uses, which might include things like student homework assignments, but not general Web purposes. If you try to do it from JS (such as by trusting HTML5 storage security more than that of cookies, or going much more anti-Web AJAX-y for content loading), or making all your requests `POST` (with some unusual framework), I think you'll have problems in practice. And anything that appears in the URL will tend to get leaked numerous ways by many browser configurations (regardless of HTTPS, or which Hierarchical URI component you put it in). For some much narrower purposes, HTTPS client certs have a place (and I kinda like them), but they are an administrative headache, there's a prohibitive usability burden for bringing on new users in for the general case of Web sites/services, usability burdens tend to create security weaknesses, browser support is strangely starting to disappear, and the browsers and "stacks" are full of holes anyway (such that there are weaker points to harden before cookies). The new work on Web browser support for hardware keys conceivably might include something generally useful, at some point, but adult supervision is needed, when it's being pushed by parties in the business of doing ubiquitous mass surveillance and/or selling hardware keys. [1] And I don't think cookies will be going away anytime soon. Almost everyone is using them for surveillance (mostly gratuitous wrt purported service) and essential authentication session tokens. Mozilla is just now starting to be a little principled against certain kind of cookie abuses for surveillance, but their funding is based on being dotcom-friendly, and I suspect that they won't actually break the current surveillance-funded industry anytime soon (nor be willing to have their browser stop working with the most popular sites, without compromise, if it comes to a standoff). Although, one of their former top VIPs, now at Brave, seems to be working on breaking various surveillance methods, while setting up a new middleperson for monetization. If Brave gets uptake from privacy-conscious people, I suppose that might light a fire under Mozilla, to reorient more thoroughly to privacy-respecting, throughout everything they do (since they have a fleet of executives who have seen them lose large chunks of market share before, on earlier differentiators). Probably, some standards will be broken, and perhaps standards eventually changed to permit that breakage (they could call it a standards "profile", if that helps diplomacy), and the dawn of a new skepticism of dotcom intentions and the technology decisions they push. Regardless, I think cookies will still work for at least first-party session authentication for a while. :) -- 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.
Re: [racket-users] Security of continuation web server?
Philip McGrath writes: > 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=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. Ah! OK, I hadn't seen this. This seems like a good solution. > 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 Cool. Thanks for your feedback. I'm happy to hear you had such a good experience. Racket's web server tools do seem indeed quite cool. It looks like the flexibility of the manager/stuffer systems are probably good enough that I can achieve what I want while keeping it secure enough (well, within the range of what's possible given the leakiness of security on the modern web). -- 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.
Re: [racket-users] Security of continuation web server?
Neil Van Dyke writes: > Christopher Lemmer Webber wrote on 09/01/2018 09:05 PM: > >> Waterken uses URI fragments to get around this in a secure way, since >> browsers do not transmit the URI fragment to the server: > > There's lots of ways that URL fragment identifiers can leak from a > browser, to untrustworthy parties, or to weaker storage, with all the > cloudy/snoopy 'services' going on. I've also seen fragment > identifiers in `Referer` fields of access logs. Wow. That's definitely violating the spec, but I guess I'm not surprised. :( -- 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.
Re: [racket-users] Security of continuation web server?
Greg Hendershott writes: > 1. The web server FAQ has a brief section about this: > > https://docs.racket-lang.org/web-server/faq.html#%28part._.What_special_considerations_are_there_for_security_with_the_.Web_.Server_%29 Ah, hadn't seen that! It also refers to the Referer issue. (I agree with the FAQ btw that a cookie-based approach has major downsides fwiw.) -- 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.
Re: [racket-users] Security of continuation web server?
Jesse Alama writes:
> On 2 Sep 2018, at 3:05, Christopher Lemmer Webber wrote:
>
>> 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.
>
> Another consideration here is to use HTTPS. That way, the URL is not
> exposed: even if I were eavesdropping on your connection, I wouldn't
> have the URL. (I *would* be able to know that you're contacting a
> certain server on a particular port, but that falls short of knowing
> the URL being accessed.)
Hi,
Just FYI the attack I described assumed HTTPS. The attack is that you
know a URL where these continuation-session URLs are accessed and you
guess numbers within the range until you hit a session.
Within high enough entropy this shouldn't be a problem, but the default
continuation manager appears to use a combination of a linearly
increasing id and (random 1) for the "salt". I think 2^128
random bytes is considered best practice for today, at which case the
linearly increasing id could also be simply dropped.
It does look like the continuation manager is configureable though,
which I had not seen previously. So I think it would be possible to add
a more secure manager which uses this behavior.
--
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.
Re: [racket-users] Security of continuation web server?
1. The web server FAQ has a brief section about this: https://docs.racket-lang.org/web-server/faq.html#%28part._.What_special_considerations_are_there_for_security_with_the_.Web_.Server_%29 2. SSL is good to use in any case. Even if you believe your site doesn't handle any sensitive user information. For example you probably don't want third parties to inject their own content like ads or phish bait. -- 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.
Re: [racket-users] Security of continuation web server?
Hi Christopher,
On 2 Sep 2018, at 3:05, Christopher Lemmer Webber 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.
Another consideration here is to use HTTPS. That way, the URL is not
exposed: even if I were eavesdropping on your connection, I wouldn't
have the URL. (I *would* be able to know that you're contacting a
certain server on a particular port, but that falls short of knowing the
URL being accessed.)
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.
Cookies are a nice technique to use here. I'm not sure what signing them
would add (you want to validate the requester and not yourself, right?).
Some web frameworks allow you to set up your server so that it uses
one-time cookies, which may also allay some of your security concerns.
Jesse
--
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.
Re: [racket-users] Security of continuation web server?
Christopher Lemmer Webber wrote on 09/01/2018 09:05 PM: Waterken uses URI fragments to get around this in a secure way, since browsers do not transmit the URI fragment to the server: There's lots of ways that URL fragment identifiers can leak from a browser, to untrustworthy parties, or to weaker storage, with all the cloudy/snoopy 'services' going on. I've also seen fragment identifiers in `Referer` fields of access logs. 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. I defer to the framework authors on this framework, but some generic Web approach, for the list... Offhand, using large random cookie values for authentication tokens sounds plausible to me. To be clear, I don't think that the cookie would reference server-side continuations (if that's the role of the URL query/parameters). Rather, the cookie could provide access control to a set of continuations (for a session or user), and each continuation would be associated with exactly-one authentication token (or with user or session ID, if you want to do it that way). This authentication token doesn't have to be part of a login mechanism. For the appropriate HTTP request methods, you can use whatever cookie the browser sends, and, if no cookie is offered, do a redirect to set the cookie. If you do this without login, try to make cookie not expire, to avoid having to implement mitigating complexity to keep a user from suddenly losing access to their continuations. (If the cookie instead gets cleared by the browser for other reasons, like due to privacy settings for when closing the browser, or Ctrl-Shift-Del, at least the user is less likely to be surprised that their "session" is gone.) Cookies go back to the early browser wars, and will work in almost all browser setups (even when disabling JS, disabling third-party cookies, not having a certain kind of HTML5 storage, a particular browser vendor deciding that a kind of local storage is very ephemeral). The Web is mostly funded by cookies. :) Cookies are also pretty familiar, and still pretty simple, and might not confuse any demonstrative or pedagogic intent of academic work on the framework, compared to some other options. (I suspect that HTTP Basic authentication, HTTP `POST` method `form` fields, HTML5 storage, and superbug trickery all have bigger downsides than cookies for this. But, I haven't used that particular framework in several years, so, without looking at it now, I could be missing a better opportunity.) -- 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.
Re: [racket-users] Security of continuation web server?
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=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.
[racket-users] Security of continuation web server?
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.
