On Wed, Dec 23, 2015 at 10:38 PM, Marc Kaufmann <marc.kaufman...@gmail.com> wrote: > Hi all, > > I am hopefully going to implement a minor website for gathering survey data > for some research I am doing. Due to data privacy and so on, I want to be > extra careful about security. First, I didn't understand the security > concerns about URLS at http://docs.racket-lang.org/web-server/faq.html, nor > its solution (see end of email for the full question which confuses me). > > Secondly, do I understand correctly that for a production-ready website, I > would use the Racket serve/servlet - or are there other/better servers I > would use? I've only used the serve/servlet on my local machine and wouldn't > understand the security concerns until I was hacked (and even then...).
There's just one serve and serve/servlet is the best way to start it, because it has the most options and controls, which you will probably want in a production system. > The question that left me more confused than reassured (primarily because I > don't understand what HTTP traffic in the clear is - as opposed to HTTPS?): Yes, if I am between you and your destination, then I can see everything you send and receive on HTTP (and change it). In contrast, if you use HTTPS, then I just know what server you are talking to, but I don't know what URLs you are looking at or what data you are sending and receiving. So, most issues related to URLs don't really apply to HTTPS. > "10.7. What special considerations are there for security with the Web Server? > > The biggest problem is that a naive usage of continuations will allow > continuations to subvert authentication mechanisms. Typically, all that is > necessary to execute a continuation is its URL. Thus, URLs must be as > protected as the information in the continuation. > > Consider if you link to a public site from a private continuation URL: the > Referrer field in the new HTTP request will contain the private URL. > Furthermore, if your HTTP traffic is in the clear, then these URLs can be > easily poached. > > One solution to this is to use a special cookie as an authenticator. This > way, if a URL escapes, it will not be able to be used, unless the cookie is > present. For advice about how to do this well, see Dos and Don’ts of Client > Authentication on the Web from the MIT Cookie Eaters. > > Note: It may be considered a great feature that URLs can be shared this way, > because delegation is easily built into an application via URLs." You haven't really asked a question, but let me try to give you an example. Suppose your main function is something like (define (main req) (define maybe-has-the-password-req (send/suspend (lambda (url) "Give me your password"))) (if (really-has-password? maybe-has-the-password-req) (secure-site maybe-has-the-password-req) (main maybe-has-the-password-req))) Once they type in the password, they get the secure site (define (secure-site req) (send/suspend/dispatch (lambda (embed-url) (list "Would you like launch missiles today?" (embed-url (lambda (req) (launch-missiles!) (secure-site req))))))) So, the URL they start at would be like 1. http://missiles.dod.mil After they type in the password it would be 2. http://missiles.dod.mil/?k=kljdaflkfjaflkdj And once they click launch missiles it would be 3. http://missiles.dod.mil/?k=qeriudfnafurf Either of the URLs, 2 or 3, when you click on them, you will immediately go to the secure site whether you typed in the password or not in your browser, because the authentication was in the past of the computation. So, if you did HTTPS just for the transition from 1->2 (as some Web sites do) but then use HTTP after that, then the URL could be snooped at middle-men could be your users. Similarly, if we changed the secure site to be... (define (secure-site req) (send/suspend/dispatch (lambda (embed-url) (list "Would you like launch missiles today?" (embed-url (lambda (req) (launch-missiles!) (secure-site req))) (a ([href "http://downforeveryoneorjustme.com/us.gov";] "Check to see if you should launch"))))) Then when you click on the link, the HTTP(S) request to downforeveryoneorjustme.com will look like GET /us.gov HTTP/1.1 Referrer: http://missiles.dod.mil/?k=kljdaflkfjaflkdj Thus, the admins there could launch the missiles by looking at their logs and clicking on the link. This referrer is always sent unless a link is from an HTTPS site to an HTTP site. So, basically, the summary is to not do this. Instead, make it so that once you type in the password, you set an authentication cookie and when you get to any page that requires authentication, check that the cookie is already there. The Racket Web server comes with a library for doing this: http://docs.racket-lang.org/web-server/http.html?q=web-server%2Fhttp%2Fid-cookie#%28mod-path._web-server%2Fhttp%2Fid-cookie%29 Jay -- Jay McCarthy Associate Professor PLT @ CS @ UMass Lowell http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- 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.
