PHP Passing Variables Between Pages and Security

[Skeets]

i'm passing session and hidden variables between pages. not to mention
post values.

i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...

$base_name = basename($_SERVER['PHP_SELF']);

is this a good bet? is there a better way?

tia...

ps - posted this on php.general and, after 2 days w/o a response,
realized that probably wasn't the best place to post it.

[Peter Chant]

Skeets wrote:

is this a good bet? is there a better way?

tia...

Sessions? As a minimum though, in case someone uses a tabbed browser,
submit an id with form and check it against whatever script processes the
form to ensure that having multiple tabs on the same site do not cause data
corrumption.

--
http://www.petezilla.co.uk

[Gordon Burditt]

>i'm passing session and hidden variables between pages. not to mention

post values.
Hidden variables (fields with type="hidden" in HTML) appear at the
user's browser. They are easily seen with "view source" and easily
spoofed by that user.

Session variables are much harder to fake unless the attacker has
access to the server (to edit session data) or can sniff the
connection between the web server and a client ("session hijacking").
i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...

$base_name = basename($_SERVER['PHP_SELF']);

This is going to tell you the PHP page being run, which unless you
have a lot of includes going on, isn't going to tell you anything
you don't already know. It *WILL NOT* help if the attacker sucks
down a HTML copy of your page, edits it, puts it on his own server,
points the <FORM ACTION=...> to refer to your server, and then uses
it and submits it.

REFERER might help there, but that's easily faked also.

Gordon L. Burditt

[Justin Koivisto]

Skeets wrote:

i'm passing session and hidden variables between pages. not to mention
post values.

i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...

$base_name = basename($_SERVER['PHP_SELF']);

is this a good bet? is there a better way?

OK, instead of linking to the threads from before, here is an example
again for protecting against spoofed form submissions:

<?php
session_start();
$_SESSION['token']=md5('secret string'.time());
?>
<form method="post" action="process.php">
<input type="hidden" name="formToken" value="<?php echo
$_SESSION['token'] ?>" />
.....
</form>

In the process.php:
<?php
session_start();
if( isset($_POST['formToken'])
&& isset($_SESSION['token'])
&& $_POST['formToken']==$_SESSION['token']
){
// form submission legit
}else{
// spoofed form submit
}
?>
This allows you to be confident that the form was submitted from your
site. Of course, when doing defense in depth (as you should be), you'll
also want to filter input and escape output...

Anyway, I have yet to find a way to be able to spoof around this,
including using javascript to attempt to read the token value from a
remote site.

As always: untested, YMMV

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Peter Fox]

Following on from Skeets's message. . .

i'm passing session and hidden variables between pages. not to mention
post values.

i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...

Anything that can be seen can be hacked. So for example
<a href="deleteuser.php?id=44">remove your record</a>
would be a seriously bad idea! Hidden fields are also useless in this
respect.

So carry as much state as you can across in the session
AND
make all inputs/addresses hack-proof.
ONE way to do this is
[Untested code]
$r = rand(1000,1111111111);
$_SESSION['privatelinks'][$r] = $theStuffYouWouldPutInAnAddressEgID;
// could be a whole array or a serialized object
print("<a href=\"nextpage.php?J=$r\">Click here to do something</a>");

in nextpage.php you can do something like:-
$j = $_GET['J'];
$args = $_SESSION['privatelinks'][$j];
// now do something with $args
// (don't forget to unset $_SESSION['privatelinks'])
// Carefully think through the various error scenarios and how you will
respond.
I also tend to validate the 'came-from' to stop inappropriate bookmarks.
--
PETER FOX Not the same since the bra business went bust
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[Skeets]

Justin, thanks for the script. i think i get the basic idea, but i'm
missing one point. what is to stop someone from copying the script
form the first page, saving it on their computer and then pointing it
to the second page? it would seem that they could spoof it as long as
they had the code from the first page.

i see isset($_POST['formToken']) is checked, but that is independent of
the sending site, right?

isset($_SESSION['token']) is checked, but that is independent of the
sending site, right?

$_POST['formToken']==$_SESSION['token'] is checked, but, as long as the
first form's hidden element arrangement is the same, they would be
equal coming from a spoofing site, too, right?

the values would be different from those sent form the legit page, but
they would still equate to each other - and that's what is checked here
- their equality, not their aboslute values - which would be different,
of course.

or am i missing something here?

thanks to all for the good ideas.

[Gordon Burditt]

>OK, instead of linking to the threads from before, here is an example

again for protecting against spoofed form submissions:

<?php
session_start();
$_SESSION['token']=md5('secret string'.time());
?>
<form method="post" action="process.php">
<input type="hidden" name="formToken" value="<?php echo
$_SESSION['token'] ?>" />
....
</form>

In the process.php:
<?php
session_start();
if( isset($_POST['formToken'])
&& isset($_SESSION['token'])
&& $_POST['formToken']==$_SESSION['token']
){
// form submission legit
}else{
// spoofed form submit
}
?>
This allows you to be confident that the form was submitted from your
site.
Ok, define "submitted from your site".

It is possible, and I've done this sort of thing on a site where I
had legitimate access, to fetch the form from your site, (using,
e.g. CURL) find the HTML for formToken, pick up the value, and pass
it as a parameter in the next request (again using CURL). Along
the way I can add in any other variables I want and not run any
Javascript on the page. Granted, this *does* load the form
from your site. And I'd have to be logged in to do it, if
that is needed to get to the page.

Granted, it's not something your average spambot would do, but it
can be done.
Of course, when doing defense in depth (as you should be), you'll
also want to filter input and escape output...

Anyway, I have yet to find a way to be able to spoof around this,
including using javascript to attempt to read the token value from a
remote site.

Gordon L. Burditt

[Gordon Burditt]

>>i'm passing session and hidden variables between pages. not to mention

post values.

i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...
Anything that can be seen can be hacked. So for example
<a href="deleteuser.php?id=44">remove your record</a>
would be a seriously bad idea! Hidden fields are also useless in this
respect.

I see nothing particularly wrong with:
<a href="deleteuser.php?id=44">remove your record</a>

*IF* you VALIDATE THE REQUEST when it is submitted. (That is, check
that the user has the authority to remove the specific record he
is trying to remove when it is submitted, *AGAIN*, don't just check
when presenting the page with the link on it. If users have the
authority to remove their own records only, mucking with the id=
value will just get the request rejected.) And if you don't
validate the request at the time it is submitted, someone will find
another hole that's just as bad (e.g. guessing someone's "removal
request ticket").

Hidden fields are occasionally useful for protection against
simultaneous editing of a record. A user wants to edit a record.
You give him a form with fields to put changed values, plus hidden
fields with the old values. If, when the request is submitted, the
hidden fields don't match what's in the database, someone edited
the record while this user was making his changes, and you reject
the changes if they appear to conflict. This is much better than
trying to hold a database lock while someone else has an edit page
up and maybe went to lunch or on vacation.

In this situation, if you muck with the hidden fields, your request
is rejected, unless you can guess how someone else has edited that
field after you get the page. There really isn't that much incentive
to hack anyway, since if you can use the form you have the authority
to make changes without any hacking.

Gordon L. Burditt

[Peter Fox]

Following on from Gordon Burditt's message. . .

Anything that can be seen can be hacked. So for example
<a href="deleteuser.php?id=44">remove your record</a>
would be a seriously bad idea! Hidden fields are also useless in this
respect.

I see nothing particularly wrong with:

<a href="deleteuser.php?id=44">remove your record</a>

*IF* you VALIDATE THE REQUEST when it is submitted. (That is, check
that the user has the authority to remove the specific record he
is trying to remove when it is submitted, *AGAIN*, don't just check
when presenting the page with the link on it. If users have the
authority to remove their own records only, mucking with the id=
value will just get the request rejected.) And if you don't
validate the request at the time it is submitted, someone will find
another hole that's just as bad (e.g. guessing someone's "removal
request ticket").

You are quite right that each and every request has to be validated on
its own merits.

But using ?REF=FOO
(a) Tells viewers what keys I'm using to identify records
(b) Is an invitation to hack here /and all other places/
(c) Can leak who/what/how many is in the system that may be private

Suppose for sake of argument we have a list of people that was
alphabetically loaded
1=Amos
2=Betty
3=Charlie
etc.
We may be happy to have this whole list public for most purposes, but
supposing we had a confidential reporting system and listed them
"(submitter wants to remain anonymous) Click for details"
with a href of ... EMPNO=4 ....
Then it doesn't take much savvy to work out that it was Dave who was
making the report even if we get rejected when clicking the link (or the
link target might anonymise and let us through 'safely').
OK, being an ace designer who never makes these mistakes :) _I_ wouldn't
use EMPNO here, but if not leaking information is important then err...
don't leak it.

[Something similar was used to break the Dutch ID card key.]

--
PETER FOX Not the same since the poster business went to the wall
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[Justin Koivisto]

Gordon Burditt wrote:

OK, instead of linking to the threads from before, here is an example
again for protecting against spoofed form submissions:

<?php
session_start();
$_SESSION['token']=md5('secret string'.time());
?>
<form method="post" action="process.php">
<input type="hidden" name="formToken" value="<?php echo
$_SESSION['token'] ?>" />
....
</form>

In the process.php:
<?php
session_start();
if( isset($_POST['formToken'])
&& isset($_SESSION['token'])
&& $_POST['formToken']==$_SESSION['token']
){
// form submission legit
}else{
// spoofed form submit
}
?>

This allows you to be confident that the form was submitted from your
site.
Ok, define "submitted from your site".

It is possible, and I've done this sort of thing on a site where I
had legitimate access, to fetch the form from your site, (using,
e.g. CURL) find the HTML for formToken, pick up the value, and pass
it as a parameter in the next request (again using CURL). Along
the way I can add in any other variables I want and not run any
Javascript on the page. Granted, this *does* load the form
from your site. And I'd have to be logged in to do it, if
that is needed to get to the page.

I tried to do this before as well... Curl wouldn't hold the session id,
so when the post came through, there was no $_SESSION['token'] set to
compare against the $_POST['formToken']
Granted, it's not something your average spambot would do, but it
can be done.

When I get in to the office, I'll set up a simple little form for
testing this out again. However, the first tests I ran didn't work at
all. Maybe I'll post the URL of the test form for others to take a try
at. ;)

PS - I'm sure I've mentioned this before, but the method I have been
using comes from Chris Shiflett's "Essential PHP Secuirty," and I see
that the chapter where this is introduced is available for download from
the book's companion site: http://phpsecurity.org (chapter 2)

[Justin Koivisto]

Justin Koivisto wrote:

When I get in to the office, I'll set up a simple little form for
testing this out again. However, the first tests I ran didn't work at
all. Maybe I'll post the URL of the test form for others to take a try
at. ;)

OK, I worked on this a bit, and I have been able to spoof through this.
I will release some details and proof of concept when I have some more
time (maybe tomorrow).

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Justin Koivisto]

Justin Koivisto wrote:

Justin Koivisto wrote:

When I get in to the office, I'll set up a simple little form for
testing this out again. However, the first tests I ran didn't work at
all. Maybe I'll post the URL of the test form for others to take a try
at. ;)

OK, I worked on this a bit, and I have been able to spoof through this.
I will release some details and proof of concept when I have some more
time (maybe tomorrow).

Of course, I should re-state that this should be used only as a
first-line of defense, and you should still be filtering input and
escaping output. (Output being anything that you script sends to another
source: writing to files, sending queries to databases, storing cookie
or session vars, etc.)

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Kevin D.]

"Skeets" <sk*********@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

i'm passing session and hidden variables between pages. not to mention
post values.

i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...

$base_name = basename($_SERVER['PHP_SELF']);

is this a good bet? is there a better way?

tia...

ps - posted this on php.general and, after 2 days w/o a response,
realized that probably wasn't the best place to post it.

this is a very interesting thread and i'm learning a lot (of course some of
it is over my head)... i'd like to clarify something, what exactly are we
defending against?

in other words, i understand the concept of someone spoofing to hack my
application... but what does this mean if my application is a basic content
manager for a website? what are the true repercussions and possible
worst-case scenarios that can take place?

- kevin

[Gordon Burditt]

>>>This allows you to be confident that the form was submitted from your

site.

Ok, define "submitted from your site".

It is possible, and I've done this sort of thing on a site where I
had legitimate access, to fetch the form from your site, (using,
e.g. CURL) find the HTML for formToken, pick up the value, and pass
it as a parameter in the next request (again using CURL). Along
the way I can add in any other variables I want and not run any
Javascript on the page. Granted, this *does* load the form
from your site. And I'd have to be logged in to do it, if
that is needed to get to the page.

I tried to do this before as well... Curl wouldn't hold the session id,
so when the post came through, there was no $_SESSION['token'] set to
compare against the $_POST['formToken']

Command-line CURL can and will save cookies (specifically the session
cookie) picked up from one request so you can use them in the next
request. I haven't tried using CURL from PHP, but I assume the
ability to do that is in there also, and the documentation seems
to support this. That should make the first request and the second
be in the same session.

Certainly, it's *possible* to do this, as a browser operated by a
human does it, and it doesn't require any abilities from the human
that are hard to automate (like reading CAPTCHAs).

What exactly are you trying to protect against here? You can protect
against stupid bots that just have the formula for what to submit
for your form, and just keep re-using it. Malicious humans operating
manually are going to be able to get around it easily.

Granted, it's not something your average spambot would do, but it
can be done.

When I get in to the office, I'll set up a simple little form for
testing this out again. However, the first tests I ran didn't work at
all. Maybe I'll post the URL of the test form for others to take a try
at. ;)

PS - I'm sure I've mentioned this before, but the method I have been
using comes from Chris Shiflett's "Essential PHP Secuirty," and I see
that the chapter where this is introduced is available for download from
the book's companion site: http://phpsecurity.org (chapter 2)

Gordon L. Burditt

[Justin Koivisto]

Kevin D. wrote:

"Skeets" <sk*********@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

i'm passing session and hidden variables between pages. not to mention
post values.

i'm a little concerned that someone with sufficient knowledge could
spoof these vlaues and manipulate the program.

is this a valid concern? i'm thinking i can check the submitting page
setting up something around the following the following code...

$base_name = basename($_SERVER['PHP_SELF']);

is this a good bet? is there a better way?

tia...

ps - posted this on php.general and, after 2 days w/o a response,
realized that probably wasn't the best place to post it.

this is a very interesting thread and i'm learning a lot (of course some of
it is over my head)... i'd like to clarify something, what exactly are we
defending against?

in other words, i understand the concept of someone spoofing to hack my
application... but what does this mean if my application is a basic content
manager for a website? what are the true repercussions and possible
worst-case scenarios that can take place?

Worst-case? Total server control. More realistic case: access to your
data and code. If you store and kind of personal data (email addresses
of customers perhaps), then access to the database could mean stealing
and/or deleting all that data.

Things like SQL injection and cross-site scripting can be found using
things like form spoofing. By trusting any data from an outside source
(your definitions may vary, but files, databases, rss feeds, user input,
sessions, cookies, etc.), you may be open to attack - whether it's a
known or unknown type.

Take an example that I had once encountered in an application I had
taken over... An inexperienced php programmer created a form for
uploading a Word document. It was then parsed using a command-line
utility and the data was then saved in the database. The script didn't
check if it was actually a Word document, and the command-line utility
didn't either. By uploading the right file (a custom-made C binary for
linux in this case), I was able to run a buffer overflow in the machine,
start a new process which listened on a certain port, and connect to it.
In this case, it was basically a telnet daemon with root privileges and
no password... It was all very cool, but even more eye-opening. ;)

Just FYI - the reason this worked was because of specific versions of
specific software (and linux kernel options), but it was just a
demonstration as to why you must practice defense in depth for all
programming (not just the web).

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Gordon Burditt]

>this is a very interesting thread and i'm learning a lot (of course some of

it is over my head)... i'd like to clarify something, what exactly are we
defending against?

in other words, i understand the concept of someone spoofing to hack my
application... but what does this mean if my application is a basic content
manager for a website? what are the true repercussions and possible
worst-case scenarios that can take place?

You end up with Viagra ads and Make Money Fast scams on your website
replacing your content, your site is relaying SPAM and sending out
viruses, and it's gotten on so many black lists you'll never get
it off. And those men breaking your door down want to know why you
threatened a terrorist act.

Gordon L. Burditt

[Justin Koivisto]

Gordon Burditt wrote:

Justin Koivisto wrote:

Gordon Burditt wrote:

It is possible, and I've done this sort of thing on a site where I
had legitimate access, to fetch the form from your site, (using,
e.g. CURL) find the HTML for formToken, pick up the value, and pass
it as a parameter in the next request (again using CURL). Along
the way I can add in any other variables I want and not run any
Javascript on the page. Granted, this *does* load the form
from your site. And I'd have to be logged in to do it, if
that is needed to get to the page.

I tried to do this before as well... Curl wouldn't hold the session id,
so when the post came through, there was no $_SESSION['token'] set to
compare against the $_POST['formToken']

Command-line CURL can and will save cookies (specifically the session
cookie) picked up from one request so you can use them in the next
request. I haven't tried using CURL from PHP, but I assume the
ability to do that is in there also, and the documentation seems
to support this. That should make the first request and the second
be in the same session.

Certainly, it's *possible* to do this, as a browser operated by a
human does it, and it doesn't require any abilities from the human
that are hard to automate (like reading CAPTCHAs).

What exactly are you trying to protect against here? You can protect
against stupid bots that just have the formula for what to submit
for your form, and just keep re-using it. Malicious humans operating
manually are going to be able to get around it easily.

What am I protecting? Well, this is only a first line of defense for me.
From there, I compare vars that were submitted with ones that I expect
as well as filtering or validating the data for those vars. At first, it
was used prevent those darn spam bots from submitting all my forms and
sending me email without hindering an actual user. Again, this was/is
used in combination of other defense mechanisms as well.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Kevin D.]

"Justin Koivisto" <ju****@koivi.com> wrote in message
news:94********************@onvoy.com...

Justin Koivisto wrote:

When I get in to the office, I'll set up a simple little form for
testing this out again. However, the first tests I ran didn't work at
all. Maybe I'll post the URL of the test form for others to take a try
at. ;)

OK, I worked on this a bit, and I have been able to spoof through this.
I will release some details and proof of concept when I have some more
time (maybe tomorrow).

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

i'm very curious to see how you did spoof it... my own theory to spoof this
method is to manually create the session (cookie) on your own machine

in other words, the check you presented only works because the hidden form
token (which is easily copied and pasted onto the "spoofing" server) matches
the session token (i'm assuming this is stored in a cookie on the submitting
client)

i have no idea what it would take to manually create this cookie on your own
client, however

- kevin

[Gordon Burditt]

>> What exactly are you trying to protect against here? You can protect

against stupid bots that just have the formula for what to submit
for your form, and just keep re-using it. Malicious humans operating
manually are going to be able to get around it easily.

What am I protecting? Well, this is only a first line of defense for me.
From there, I compare vars that were submitted with ones that I expect
as well as filtering or validating the data for those vars. At first, it
was used prevent those darn spam bots from submitting all my forms and
sending me email without hindering an actual user. Again, this was/is
used in combination of other defense mechanisms as well.

No, I asked what you were trying to protect *AGAINST*.
The answer seems to be "stupid bots sending in corrupt data", since
humans actually going to your page and putting in malicious data
won't be stopped by it, nor will smarter bots that can keep a session
cookie and emulate the action of a browser.

I think you need to work on making your code bullet-proof no matter
WHOSE form is submitted to your server, and obviously you're
validating input which is an important part of that.

Gordon L. Burditt

[Skeets]

as the OP, i'm trying to protect against everything. while i hadn't
thought about bots, i had thought of a criminal minded dr evil computer
genius trying to hack my forms out of spite. while this is an unlikely
scenario, i like to do things right, if i can.

it seems to me one has to...

1. verify the submittal page is the correct one...
2. verify that the "salted" session variable from the submittal page is
the same as the one received.

based on responses, though, i'm thinking there is no way to do #1 with
certainty (referrer can be spoofed). w/o #1, #2 doesn't mean too much.

is that about it?

[Gordon Burditt]

>as the OP, i'm trying to protect against everything. while i hadn't

thought about bots, i had thought of a criminal minded dr evil computer
genius trying to hack my forms out of spite. while this is an unlikely
The approach of putting tokens on forms does nothing to protect
against users using a browser to pull up your form and put a bunch
of crap in it. It also does nothing to protect against smart bots
that can rapidly emulate what the aforementioned user does manually.
scenario, i like to do things right, if i can.

it seems to me one has to...

1. verify the submittal page is the correct one...
2. verify that the "salted" session variable from the submittal page is
the same as the one received.

based on responses, though, i'm thinking there is no way to do #1 with
certainty (referrer can be spoofed). w/o #1, #2 doesn't mean too much.

is that about it?

Ok, what happened to 3. *FORGET* about (1) and (2), and verify
that the submitted DATA, whereever it came from, is correct. This
would include stuff like not allowing carriage returns and line
feeds in text that will be included in email headers. Using YOUR
forms won't protect you when someone malicious fills them in.

Well, actually, (3) alone may not keep the web site operator sane
because someone can find some valid data and submit it a few million
times a week, which if it generates email to the operator, would
make his mailbox pretty useless.

Gordon L. Burditt

[Skeets]

probably the single worst case scenario is that a bunch of 13 year old
script kiddies laugh about you being pwn3d by them - and this can last
a while, too. -lol-

seriously, i think someone else answered your question, but i had to
get that in there, b/c it does happen.

can a script like this be modified to *know* that the form is being
sent from one's own site?

<?php
$host=apache_request_headers();
if(!eregi('domain.com',$host[Referer])){
//[...code to download file here...]
}else{
//[...code to download alternate file here...]
}
?>

it is a comment on php.net's manual $_server discussion.

iow, is...

$host=apache_request_headers();
if(!eregi('domain.com',$host[Referer])){

....spoofable or does it tell you where the page came from 100% of the
time?

[Skeets]

btw, i use bind variables when i'm inputting fuser orm information into
my db (postgresql). adodb's db abstraction layer (very good, btw) has
a pretty nice implementation. using bind variables means you don't
have to escape everything prior to submission and sql injection becomes
a non issue. if it is bad data, it doesn't get submitted, as i
understand it.

i posted this in another reply, but i'm not sure you will read it.

is this spoofable (i do use apache)?

$host=apache_request_headers();
if(!eregi('domain.com',$host[Referer])){
// good submission, do something
}else{
//bad submission, don't do anything
}

[Kevin D.]

"Skeets" <sk*********@yahoo.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

probably the single worst case scenario is that a bunch of 13 year old
script kiddies laugh about you being pwn3d by them - and this can last
a while, too. -lol-

seriously, i think someone else answered your question, but i had to
get that in there, b/c it does happen.

can a script like this be modified to *know* that the form is being
sent from one's own site?

<?php
$host=apache_request_headers();
if(!eregi('domain.com',$host[Referer])){
//[...code to download file here...]
}else{
//[...code to download alternate file here...]
}
?>

it is a comment on php.net's manual $_server discussion.

iow, is...

$host=apache_request_headers();
if(!eregi('domain.com',$host[Referer])){

...spoofable or does it tell you where the page came from 100% of the
time?

how does apache_request_headers differ from the information returned from
the _SERVER superglobal? at least if you're only looking at the hostname...
php documentation doesn't qualify the difference

[Gordon Burditt]

>can a script like this be modified to *know* that the form is being

sent from one's own site?

A form submission is sent from a BROWSER, not a server. If you
can't trust the browser, you can't be sure where the form came from
(REFERER might work, although it's trivially spoofed and
often removed by proxies).

Is it possible to make a vest that will protect me against
everything but my own gun? Maybe, but I'd think you're better
off protecting yourself against guns regardless of whether
it's your stolen gun or not. People can put crap data
into your form easily.

Gordon L. Burditt

[Kevin D.]

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

can a script like this be modified to *know* that the form is being
sent from one's own site?

A form submission is sent from a BROWSER, not a server. If you
can't trust the browser, you can't be sure where the form came from
(REFERER might work, although it's trivially spoofed and
often removed by proxies).

Is it possible to make a vest that will protect me against
everything but my own gun? Maybe, but I'd think you're better
off protecting yourself against guns regardless of whether
it's your stolen gun or not. People can put crap data
into your form easily.

Gordon L. Burditt

when it really comes down to it, i agree with gordon... forget where the
data is coming from and just verify the contents of it (he may not be saying
to completely ignore the origin of the data)

i think that's all you can really do, every other attempt to verify that the
data is coming from your own server seems futile (it's too easy to spoof and
doesn't really accomplish much even when it works)

[Justin Koivisto]

Skeets wrote:

btw, i use bind variables when i'm inputting fuser orm information into
my db (postgresql). adodb's db abstraction layer (very good, btw) has
a pretty nice implementation. using bind variables means you don't
have to escape everything prior to submission and sql injection becomes
a non issue. if it is bad data, it doesn't get submitted, as i
understand it.

i posted this in another reply, but i'm not sure you will read it.

is this spoofable (i do use apache)?

$host=apache_request_headers();
if(!eregi('domain.com',$host[Referer])){
// good submission, do something
}else{
//bad submission, don't do anything
}

The referrer is one of the easiest headers to forge. There are even
browser plug-ins for browsers like Firefox that allow you to send
whatever you want as the UA or referrer. In fact, wget and curl allow
you to write your own as well.

[Jasen Betts]

On 2006-02-10, Skeets <sk*********@yahoo.com> wrote:

probably the single worst case scenario is that a bunch of 13 year old
script kiddies laugh about you being pwn3d by them - and this can last
a while, too. -lol-

seriously, i think someone else answered your question, but i had to
get that in there, b/c it does happen.
can a script like this be modified to *know* that the form is being
sent from one's own site?
no.
if(!eregi('domain.com',$host[Referer])){

referer is easy to spoof.

--

Bye.
Jasen

[Justin Koivisto]

Kevin D. wrote:

"Justin Koivisto" <ju****@koivi.com> wrote in message
news:94********************@onvoy.com...

Justin Koivisto wrote:

When I get in to the office, I'll set up a simple little form for
testing this out again. However, the first tests I ran didn't work at
all. Maybe I'll post the URL of the test form for others to take a try
at. ;)

OK, I worked on this a bit, and I have been able to spoof through this.
I will release some details and proof of concept when I have some more
time (maybe tomorrow).

i'm very curious to see how you did spoof it... my own theory to spoof this
method is to manually create the session (cookie) on your own machine

in other words, the check you presented only works because the hidden form
token (which is easily copied and pasted onto the "spoofing" server) matches
the session token (i'm assuming this is stored in a cookie on the submitting
client)

i have no idea what it would take to manually create this cookie on your own
client, however

I just pulled out my code from my first attempt with php & curl. With
the correct settings, I was able to have the session id get saved (which
is what was failing last time).

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com