form action

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

form action

Post by s.dot »

How do I make sure a forms contents are only being processed from my domain?

For instance, I recently had a guy save my forms HTML to his computer, alter a select box, and input an option that wasn't in the option list. He submitted this altered form to my PHP script, and it processed it.

I'm guessing somewhere in the $_SERVER I can check to make sure the form is only being submitted from my domain?
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
foobar
Forum Regular
Posts: 613
Joined: Wed Sep 28, 2005 10:08 am

Re: form action

Post by foobar »

scrotaye wrote: I'm guessing somewhere in the $_SERVER I can check to make sure the form is only being submitted from my domain?
You could use $_SERVER['HTTP_REFERER'], but you can cloak that pretty easily. What would make more sense is to run a server side check on whether the option sent is actually an allowed option.

Like so:

Code: Select all

$bla = $_POST['bla'];
$allowed = array(1, 2, 3);

if (!in_array($bla, $allowed)) {
  die('Hax0r!!!1');
}
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post by s.dot »

hmm, how would $_SERVER['HTTP_REFERRER'] be fooled?

And i think i shall combine both security options to be safe.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
Dark[NSF]
Forum Newbie
Posts: 18
Joined: Thu Oct 06, 2005 9:25 am
Location: Palm Bay, FL
Contact:

Post by Dark[NSF] »

scrotaye wrote:hmm, how would $_SERVER['HTTP_REFERRER'] be fooled?

And i think i shall combine both security options to be safe.
any local webserver can change it's dns, i suppose that's one way of doing it.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

checking the sent information against what generated the form on the submitting page.. that's the only real way to make sure.. referrer isn't reliable in any direction. Remember: verify, validate, and sanitize anything that comes from any external source. If you are truely paranoid, you even do that for internal sources..
User avatar
wtf
Forum Contributor
Posts: 331
Joined: Thu Nov 03, 2005 5:27 pm

Post by wtf »

What about sessions

page form create session set session id

proccess page, verify current session against incoming one?

Would that work???
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post by s.dot »

well i am going to check to make sure its coming from my domain first of all...

that should thwart off some people, since apparently faking the http_referrer is possible.

then i can begin the process of checking all my select boxes to make sure the option they chose is in the select box.

why can't everyone just be nice instead of being hax0ring bastards :(
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post by n00b Saibot »

scrotaye wrote:why can't everyone just be nice instead of being hax0ring bastards :(
b'cos it's geek 8)
j/k :wink:
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

One method of disuasion is to add a token to every form requested from your site, validate this against the user's session stored token (both should equal) or else discard the request entirely. Also the usual input filtering; if its not expected, don't accept it. $_SERVER variables based on user sourced data are never trustworthy. Being completely paranoid I actually discard everything in $_SERVER unless required. Much of its contents need to be properly filtered before use either way - its not trustworthy in any shape or form since much is (whether the majority of developers realise it or not) sourced in user data, and can be tainted as easily as the traditional POST, GET, COOKIE...

The token practice isn't foolproof (obviously) but it's another inconvenience to overcome. Even obscurity is worthwhile if it forces a hacker to edit their script for every single request... Filtering is the key here however.
User avatar
wtf
Forum Contributor
Posts: 331
Joined: Thu Nov 03, 2005 5:27 pm

Post by wtf »

or you can always go captcha way
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I dislike CAPTCHA; imagine you're struck blind tomorrow - now see how much you like it. It's a curse on people with visual impairments. Far as I'm concerned if you can't navigate a site with its graphics disabled completely, then its called bad design.
Post Reply