Check where a form came from...

ElectricRain

I want to stop people posting to my forms from other websites.

HTTP REFERER is unreliable, so thats out.

Someone tells me you can use sessions. Which seems like a fantastic idea initially, but if you dont refresh the page, you can jump to pages (at least pages youve accessed before- didnt test it on new pages) and then back to your site without destroying the session.

So I either need to find a neat way to destroy session everytime someone sets foot off my site, or else another way of checking where the form came from.

Also, Im not 100% sure Im doing this right, I was thinking for each form I wanted to perform this kind of validation on Id have

$_SESSION["ubersecretkey"] = "somestring";

to set the session and

if ($_SESSION["ubersecretkey"] == "somestring") { 
$_SESSION["ubersecretkey"] = ""; //unset
//carry on and do stuff

But somestring would haveto be a constant, I think. Is THAT itself secure?

This is my first proper attempt at sessions so maybe Im oversimplifying.. I dunno.

What dyou guys do to make sure your form submissions come from inside your site?

MarkR

This is called CSRF prevention.

The method I'd use would be:

On the form page, generate a random value and store it in the session.
Serve the form, with a hidden field containing this random value.
When the form is posted, check this hidden field is consistent with the session value, if not, refuse to process the form.

You should ensure that your site uses only cookies to maintain session state. This can be done by using setting session.use_only_cookies. Query strings leak info out all over the place.

I believe this method is fairly secure against CSRF attempts. The reason is: although a third party web site could retrieve the form from your server and serve it to a client, they wouldn't have the same session, as they wouldn't have the session ID cookie set for that domain (sites cannot set third party sites' cookies).

This means that the random value would belong to a different session, and hence either not match or be absent.

Mark

radam

ElectricRain,

I'm not sure that sessions will do what you want as securely as you want it. Of the top of my head I can think of two alternatives:

Option One

(You have probably seen this on other sites)

On your form page, create an image of some distorted text and display it. Then, as part of the form entry procedure, the user would have to enter the text displayed into a textbox. The nice thing being that it is very difficult for a simple web app (i.e. other sites) to perform OCR on distorted text, hence preventing them from using your form.

How do you verify the text without sending the text to the client also? Send a hash (md5 for example) of the generated text to the browser in a hidden field. When the form is submitted, hash the users entry and compared with the hash sent to the browser. They should match.

I am quite sure that there are php utils out there to generate distorted text. Can anyone suggest one?

Option Two

(less secure than one, but less hassle for the user)

Have a submission_tokens table in your DB. When the form page is requested, use a hidden field to store a token id, which specifies a row on the submission_tokens table.

The submission_tokens table would have the columns:

tokenid (preferably a pseudo random string or int)
creationDate (the tokens creation date)
requestersIP

When the form is submitted, check the tokenid's creation date in the database. If the date has been exceeded, then throw them an error.

Option two - part B

Of course, another website could simply grab a form page from your site and extract the token id. So, you could also monitor the IP of each client that requests a token (i.e. the form page) using the requestersIP field. If you have handed out more than a few tokens to them in the last x minutes/hours then you should present them with an error.

Well, what do you think? 🙂

ElectricRain

Hmm. I like Marks idea... I was almost THERE and then decided I didnt want to send the random string in a hidden form field, (because thats visible) but if the session is set purely with cookies as you said then Im guessing they cant use dynamic code to pull a the appropriate var out of it and set that as their hidden form field value before sending the data back to my site. Err.. can they? Im 99% sure session cookies are only accesiable by the site that set them.

Randam I thank ya for the information, I actually am going to attempt to employ the distorted text idea at some point, but more to make sure my users are real live humans. 🙂

MarkR

ElectricRain wrote:
Hmm. I like Marks idea... I was almost THERE and then decided I didnt want to send the random string in a hidden form field, (because thats visible)

Visible, yes, but if they tamper with it it will simply not work.

but if the session is set purely with cookies as you said then Im guessing they cant use dynamic code to pull a the appropriate var out of it and set that as their hidden form field value before sending the data back to my site. Err.. can they?

No. A third party site cannot obtain your users' cookies. Unless your site is vulnerable to a XSS exploit. You do escape absolutely every string you display to the browser appropriately, don't you?

Im 99% sure session cookies are only accesiable by the site that set them.

Depends on the domain set on the session cookie. Usually, yes. Browsers don't usually allow a cookie to be set across all domains, or many domains, e.g. setting a cookie for .com or .co.uk

Randam I thank ya for the information, I actually am going to attempt to employ the distorted text idea at some point, but more to make sure my users are real live humans. 🙂

A CAPTCHA is another idea, and is for a different purpose. If you're sure you're going to have a problem with robots, then use one. Bear in mind that most robots don't submit forms, and the ones which do usually don't bother reading the HTML of the form first, or support cookies, so they would mostly fail the above. But in principle someone could easily write a robot which would do it.

Mark

ElectricRain

MarkR wrote:
No. A third party site cannot obtain your users' cookies. Unless your site is vulnerable to a XSS exploit. You do escape absolutely every string you display to the browser appropriately, don't you?

Hmm. Escaping things is just putting the backslash before and " marks isnt it? Like you do for database entries? How does that affect XSS vulnerability?
I need to go read up on this stuff.
does that

When I set sessions to use only cookies in my php.ini file, I found session.cookie_path and session.cookie_domain vars, would it be a good idea to set those to my domain? (theyre currently nothing) I read the manual but Im not sure I entirely get it.

MarkR

ElectricRain wrote:
Hmm. Escaping things is just putting the backslash before and " marks isnt it?

No, it is not. Not in this context.

Ignoring databases, if you do echo $_GET['blah'], you're creating a XSS vulnerability, as someone could insert Javascript code etc, into 'blah'.

For example, on another site, someone puts in

<iframe src="http://yoursite.example.com/vulnerable.php?blah=&lt;script&gt;some_evil_javascript"></iframe>

This could invisibly cause some javascript code to be executed in the context of your site, with the cookies belonging to your user, and send the contents of those cookies to evil.hacker.example.com.

The escaping you need to do varies by context, but usually htmlspecialchars()

It is absolutely vital that EVERYTHING you output to the browser, in any context, that could possibly have originated by the user, is escaped appropriately. This includes even data from the database which could have come from the user originally.

When I set sessions to use only cookies in my php.ini file, I found session.cookie_path and session.cookie_domain vars, would it be a good idea to set those to my domain? (theyre currently nothing) I read the manual but Im not sure I entirely get it.

By default it will use the current domain and the root path (I think). Therefore you should NOT set cookie_path or cookie_domain

Mark

ElectricRain

Hmm. The only things I pass in the url are pages (ie mysite.com?page=signup) or users (mysite.com?page=profile&user=me)

Pages isnt vulnerable is it because on my index template is the list of pages and a final else include home.php.

users.. hmm.. so it would be $user = htmlspecialcharacters($_GET['user']); or something along those lines. Yes.. that makes sense. Thanks 🙂

MarkR

No, you need to escape stuff before you send it to the browser, not at any other time.

So don't do $user = htmlspecialcharacters($_GET['user']) !!

If you want to output their username, do it then:

echo "Successfully registered your user:" . htmlspecialcharacters($user);

For example.

Mark

ElectricRain

uhh.. why? Whats the difference?