in reply to Subscription form script

My primary concern is validating all the parameters that aren't sent to the script, including the IP address and the referrer. The referrer is easily changed client side, sometimes not sent at all (proxies, web browsers, whatever don't have to send it). Think of it as tainted client supplied data (as if from your form) trust it and act on it about as much as a non required unverifyable field on your form.

-Waswas

Replies are listed 'Best First'.
Re: Re: Subscription form script
by Anonymous Monk on Aug 06, 2003 at 16:26 UTC
    My primary concern is validating all the parameters that aren't sent to the script, including the IP address and the referrer.

    Sorry, I meant s/aren't/are/;

    So, my primary concern is validating all input from the client, including the IP and referrer. I think we're basically saying the same thing although I can't type todya ;-)

      My point is you can't validate the referrer. It is an untrusted string that can be hand set to anything the client wants (or not set at all). Meaning if you are going to say, only show this page when the referrer is set to http://www.page_i_want_you_to_come_from.com/here.html and the source IP is 10.128.1.1, you must note that even though referrer is saying it is from http://www.page_i_want_you_to_come_from.com/here.html, it may not have actualy been there. Or even more doubious, if the referrrer is not set or not set to http://www.page_i_want_you_to_come_from.com/here.html the browser may still have come from that url. In short referrer is useless except for some very discountable logging tactics.

      -Waswas

        I could still filter it as a URL, so check for the proper structure and length. I think it's actually useful for some stats analysis as well (ie I've got 45 people coming from everywhere else and 12 000 from slashdot, hmm maybe I should take a look at slashdot?).