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 <[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. > > > -- 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.
