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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Dec 23, 2015 at 10:38 PM, Marc Kaufmann >> <[email protected] <mailto:[email protected]>> 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 [email protected] >> <mailto:[email protected]>. >> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
