Well, actually, I overlooked that information in the prior posts. Sorry for the noise and thanks for the summary! Daniel.
Am 29.12.2015 um 14:10 schrieb Jay McCarthy: > I don't understand your question. The net-cookies package is very good > for arbitrary cookies and the id-cookie library I linked to is very > good for just authentication. The posts prior to your question contain > this information, so what are you asking? > > Jay > > On Sat, Dec 26, 2015 at 8:33 AM, Daniel Brunner <dan...@dbrunner.de> wrote: >> Btw, what's the "standard" way to handle cookies? I learned from the >> documentation one should use the net-cookies package? >> >> (I am writing a small http client script and need to handle the >> authentication cookies as well). >> >> Kind regards, >> Daniel >> >> Am 24.12.2015 um 15:50 schrieb Marc Kaufmann: >>> In short, do HTTPS with cookies and I should be fine (modulo bugs, weak >>> passwords, etc). >>> >>> Thanks, that does answer very well the question that I didn't ask. >>> >>> On Thu, Dec 24, 2015 at 8:28 AM, Jay McCarthy <jay.mccar...@gmail.com >>> <mailto:jay.mccar...@gmail.com>> wrote: >>> >>> On Wed, Dec 23, 2015 at 10:38 PM, Marc Kaufmann >>> <marc.kaufman...@gmail.com <mailto: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 <http://downforeveryoneorjustme.com> >>> will look like >>> >>> GET /us.gov <http://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 >>> <mailto: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. > > > -- 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.
