On Tue, 2003-08-12 at 12:11, Wade Preston Shearer wrote: > i am currently preventing leeching of PDF downloads for a company's > website by checking the referring URL (with PHP). > > this works beautifully, except that there is an bug in internet > explorer/PDF that causes an error. i have written a little 'detect the > browser' code in there that generally fixes it, but customers are still > having problems. i would like to tell them to just use a real browser, > but hey... unfortunately most of the customers use IE. > > to make things easier, i cam considering replacing the 'check the > referring url' bit of my script with a 'check for cookie' bit. i would > set a cookie when a user first entered the site. and then, if they > tried to download a file, the script would simply check for the > existence of the cookie. > > what-a-ya'll think about using cookies for validating in an anti-leech > script?
Better than trusting an easily spoofed referrer. If I were doing it, I'd make the cookie available only over https and have it deleted at the end of session (never written to disk). That way, the only way left to leach is to copy the cookie by hand--something very few people will bother doing. Don't forget include enough encrypted information to verify that the cookie hasn't been stolen. You know, encrypted IP of client, agent type, a timestamp, some type of canary like an MD5 hash of cookie plus a secret string on the server. You could even include SSL session information if you're not load balancing. :-) But then I tend to go overboard when designing. -- Stuart Jansen <[EMAIL PROTECTED], AIM:StuartMJansen> When in doubt, use brute force. -- Ken Thompson, co-creator of Unix
signature.asc
Description: This is a digitally signed message part
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
