RE: [PHP] extract($_POST)
[snip] Lets say you have a statement like: $query = "SELECT * FROM mytable WHERE firstname=$firstname"; And if $firstname is set to: "xyz"; DELETE FROM mytable Then this is executed as: SELECT* FROM mytable WHERE firstname="xyz";DELETE FROM mytable This can wipe out your table...a bad thing... [/snip] Ah! But only if the database user has permissions for DELETE. That is why security must be carefully thought out, because there are so many levels for it to be implemented on. This has been a great thread, lots of useful information. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Or, You can use this: http://www.php.net/manual/en/function.is-numeric.php - E "John W. Holmes" <[EMAIL PROTECTED]> wrote: > > > Then make sure $id is a number. You can use is_int, or (int), or > > whatever. > > > > It appears that any numeric values passed via the URL (..?param=10001) > are > > automatically treated as strings. If I pass ?param=1001 to the > following > > script... > > So turn it into an integer. > ...[snip]... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
> > Bottom line is that you want to use addslashes() or magic_quotes_gpc() > > on any variable you're going to insert into a query string. If you're > > inserting a variable that should be a number, make sure it is one. > > If I have magic quotes turned on, do I still need to worry about using > addslashes? No, it's automatic. You may want to program in a check that sees if magic_quotes is on or off, though, and act accordingly. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
John W. Holmes wrote: > > Bottom line is that you want to use addslashes() or magic_quotes_gpc() > on any variable you're going to insert into a query string. If you're > inserting a variable that should be a number, make sure it is one. If I have magic quotes turned on, do I still need to worry about using addslashes? Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
> > Then make sure $id is a number. You can use is_int, or (int), or > whatever. > > It appears that any numeric values passed via the URL (..?param=10001) are > automatically treated as strings. If I pass ?param=1001 to the following > script... So turn it into an integer. $param = (int)$_POST['param']; It'll be turned into an integer or anything after a string part will be chopped off. 10001 => 10001 1000f => 1000 f1000 => 0 Validating can be that simple. You may also want to check the range of the number. Again, validating is unique to your application. What do you expect the value to be? If the value is XXX, how does that affect my application? ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
John W. Holmes wrote:
> Then make sure $id is a number. You can use is_int, or (int), or whatever.
It appears that any numeric values passed via the URL (..?param=10001) are
automatically treated as strings. If I pass ?param=1001 to the following
script...
$type = '';
if (is_string($param)) { $type = 'string'; }
if (is_int($param)) { $type = 'integer'; }
echo 'Type: '.$type;
... I get the following result:
Type: string
But, it should be integer because 10001 is meant to be a number. How does
this work for $_GET values?
Monty
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
> I'm confused about when I should escape single or double quotes. Should > all > quotes be stored as \" or \' in a database as well? Escape both, just use addslashes. The key here is that if you are inserting a variable into a string (which is all a query is), then you want to make sure that the contents of that variable don't unexpectedly terminate the string. > Regarding your suggestion above, is this what I should do? ... > > $name = "John AND fname = 'Mary'"; > > $name = addslashes($name); > > // $name now holds: "John AND fname = \'Mary\'" > > This forces MySQL to read \' as a character rather than as the beginning > of > a variable value. So, in essence, this would produce a mySQL error instead > of executing the query, is that correct? It depends on what you're doing with $name. Remember, you're just creating a string that has to be logical when it's sent to MySQL SELECT * FROM table WHERE name = '$name' SELECT * FROM table WHERE name = "$name" Either way you do it, you want to make sure that the contents of $name don't have a quote that'll end the name string. If you have $name = "John AND fname = 'Mary'"; and you don't escape quotes, then you have a query like SELECT * FROM table WHERE name = 'John AND fname = 'Mary' SELECT * FROM table WHERE name = "John AND fname = 'Mary' Where the first one will cause an error and the second one will just not match any rows, more than likely. If you have $name = "John' AND fname='Mary"; and you don't escape quotes, you'll get SELECT * FROM table WHERE name = 'John' AND fname='Mary' SELECT * FROM table WHERE name = "John' AND fname='Mary" Where the first is a valid query and could return rows you didn't normally intend for it to return. The second will probably not match any rows again. Now, don't think that double quotes are any safer. You can change $name to use double quotes to manipulate the queries, too. Bottom line is that you want to use addslashes() or magic_quotes_gpc() on any variable you're going to insert into a query string. If you're inserting a variable that should be a number, make sure it is one. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
John W. Holmes wrote: > Then make sure $name has all single quotes escaped within it. If all of > them are escaped, then it's just a string and can't do any harm. If they > aren't escaped, then the user can break out of your own SQL and put > their own. I'm confused about when I should escape single or double quotes. Should all quotes be stored as \" or \' in a database as well? Regarding your suggestion above, is this what I should do? ... $name = "John AND fname = 'Mary'"; $name = addslashes($name); // $name now holds: "John AND fname = \'Mary\'" This forces MySQL to read \' as a character rather than as the beginning of a variable value. So, in essence, this would produce a mySQL error instead of executing the query, is that correct? Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
> > You can still use extract($_POST). > > It is as safe/vulernable as $_POST['isAdmin']. > > > > In either case, use only variables that you know are yours and be > certain > > these contain values which you believe to be safe. For instance, if you > expect > > a variable called $firstname to contain a name to be stored in a SQL > database, > > be certain it does not contain SQL commands which can damage your > database. > > > > Okay, I know I can use strip_tags() and/or htmlspecialchars() to strip out > or modify HTML and PHP code in a string, but, how does one do the same > with > MySQL code in a string to prevent tampering? You pass a string or an number to your query. You have to make sure the data you're passing is a string, or a number. If you're expecting a number, and use a query like: WHERE id = $id Then make sure $id is a number. You can use is_int, or (int), or whatever. If you're passing a string WHERE username = '$name' Then make sure $name has all single quotes escaped within it. If all of them are escaped, then it's just a string and can't do any harm. If they aren't escaped, then the user can break out of your own SQL and put their own. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Rick Emery wrote: > You can still use extract($_POST). > It is as safe/vulernable as $_POST['isAdmin']. > > In either case, use only variables that you know are yours and be certain > these contain values which you believe to be safe. For instance, if you expect > a variable called $firstname to contain a name to be stored in a SQL database, > be certain it does not contain SQL commands which can damage your database. > Okay, I know I can use strip_tags() and/or htmlspecialchars() to strip out or modify HTML and PHP code in a string, but, how does one do the same with MySQL code in a string to prevent tampering? Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
> Well, one way you can avoid similar things to happen is, you can do > something like, say, create a user that can only SELECT. If the user can > only SELECT then it cannot DELETE. This is a great suggestion from Rick. I already use this method. I have several MySQL users set up for various functions: one that can only SELECT, which is the one I use the most, another that can SELECT, UPDATE and INSERT, and another that can do all of the following plus DELETE. Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
Yes, true. My mistake.
Someone else also mentioned subqueries. Those could be a problem if your
database supports it, too.
---John Holmes...
> -Original Message-
> From: Rick Emery [mailto:remery@;emeryloftus.com]
> Sent: Friday, October 25, 2002 6:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP] extract($_POST)
>
>
> You assume mysql.
> Other SQL databases allow multiple statements.
>
> > -Original Message-
> > From: Rick Emery [mailto:remery@;emeryloftus.com]
> > Sent: Friday, October 25, 2002 4:59 PM
> > To: Chris Boget; [EMAIL PROTECTED]; Monty
> > Subject: Re: [PHP] extract($_POST)
> >
> > Lets say you have a statement like:
> > $query = "SELECT * FROM mytable WHERE firstname=$firstname";
> >
> > And if $firstname is set to:
> > "xyz"; DELETE FROM mytable
> >
> > Then this is executed as: SELECT* FROM mytable WHERE
> > firstname="xyz";DELETE FROM mytable
> >
> > This can wipe out your table...a bad thing...
> >
> > - Original Message -
> > From: "Chris Boget" <[EMAIL PROTECTED]>
> > To: "Rick Emery" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>;
> > "Monty"
> > <[EMAIL PROTECTED]>
> > Sent: Friday, October 25, 2002 3:41 PM
> > Subject: Re: [PHP] extract($_POST)
> >
> >
> > This thread has been great! I've learned so much useful stuff.
> >
> > > For instance, if you expect a variable called $firstname to
contain
> > > a name to be stored in a SQL database, be certain it does not
> contain
> > > SQL commands which can damage your database.
> >
> > This is another thing I'd be interested in hearing more about. If
all
> you
> > are doing is storing and retrieving data, what commands could
possibly
> > be defined that could damage your database?
> >
> > $firstName = "Chris";
> > mysql_query( "INSERT INTO names ( first_name ) VALUES (
\"$firstName\"
> )"
> > );
> > $result = mysql_query( "SELECT first_name FROM names" );
> > while( $dataArray = mysql_fetch_assoc( $result )) {
> > echo $dataArray["first_name"]
> >
> > }
> >
> > If $firstName was set by a form submission, what malicious SQL code
> could
> > damage your database? All you are doing is storing, retreiving and
> > displaying
> > data...
> >
> > Chris
> >
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
True. That's why I said: > > then you can check whether the value > > is_numeric() or something. I think this narrows down what you're checking. So, if you send me "any value" my script would just reject it. Besides, this is just a hint--there are many ways to validate. Of course, you know that... :) > > Or, even if it's a text field, perhaps you can > > use some regex to make sure that you only accept certain characters. > > (i.e. alphabet, etc.) ;) - E "John W. Holmes" <[EMAIL PROTECTED]> wrote: > [snip] > > There are many places (websites) wherein you can choose the country > from a > > pulldown menu. This prevents somebody (somehow) from posting something > > illegal. Besides, if the values assigned are numbers (e.g. > value="100">My Country) then you can check whether the value > > is_numeric() or something. Or, even if it's a text field, perhaps you > can > > use some regex to make sure that you only accept certain characters. > (i.e. > > alphabet, etc.) > > A drop down doesn't save you from validating what the user sent. Just > because your form has a drop down, it doesn't mean the one I re-create > on my page has one (while I'm spoofing HTTP_REFERRER, mind you). It may > have a text box so I can send you any value. > > ---John Holmes.. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
You assume mysql.
Other SQL databases allow multiple statements.
> -Original Message-
> From: Rick Emery [mailto:remery@;emeryloftus.com]
> Sent: Friday, October 25, 2002 4:59 PM
> To: Chris Boget; [EMAIL PROTECTED]; Monty
> Subject: Re: [PHP] extract($_POST)
>
> Lets say you have a statement like:
> $query = "SELECT * FROM mytable WHERE firstname=$firstname";
>
> And if $firstname is set to:
> "xyz"; DELETE FROM mytable
>
> Then this is executed as: SELECT* FROM mytable WHERE
> firstname="xyz";DELETE FROM mytable
>
> This can wipe out your table...a bad thing...
>
> - Original Message -
> From: "Chris Boget" <[EMAIL PROTECTED]>
> To: "Rick Emery" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>;
> "Monty"
> <[EMAIL PROTECTED]>
> Sent: Friday, October 25, 2002 3:41 PM
> Subject: Re: [PHP] extract($_POST)
>
>
> This thread has been great! I've learned so much useful stuff.
>
> > For instance, if you expect a variable called $firstname to contain
> > a name to be stored in a SQL database, be certain it does not
contain
> > SQL commands which can damage your database.
>
> This is another thing I'd be interested in hearing more about. If all
you
> are doing is storing and retrieving data, what commands could possibly
> be defined that could damage your database?
>
> $firstName = "Chris";
> mysql_query( "INSERT INTO names ( first_name ) VALUES ( \"$firstName\"
)"
> );
> $result = mysql_query( "SELECT first_name FROM names" );
> while( $dataArray = mysql_fetch_assoc( $result )) {
> echo $dataArray["first_name"]
>
> }
>
> If $firstName was set by a form submission, what malicious SQL code
could
> damage your database? All you are doing is storing, retreiving and
> displaying
> data...
>
> Chris
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
You can still create a sub-query to do the damage.
Jason
-Original Message-
From: John W. Holmes [mailto:holmes072000@;charter.net]
Sent: Friday, October 25, 2002 4:01 PM
To: 'Rick Emery'; 'Chris Boget'; [EMAIL PROTECTED]; 'Monty'
Subject: RE: [PHP] extract($_POST)
No, this can't happen. There can only be one SQL query per
mysql_query().
Google for SQL injection or something and I'm sure you'll find examples.
---John Holmes...
> -Original Message-
> From: Rick Emery [mailto:remery@;emeryloftus.com]
> Sent: Friday, October 25, 2002 4:59 PM
> To: Chris Boget; [EMAIL PROTECTED]; Monty
> Subject: Re: [PHP] extract($_POST)
>
> Lets say you have a statement like:
> $query = "SELECT * FROM mytable WHERE firstname=$firstname";
>
> And if $firstname is set to:
> "xyz"; DELETE FROM mytable
>
> Then this is executed as: SELECT* FROM mytable WHERE
> firstname="xyz";DELETE FROM mytable
>
> This can wipe out your table...a bad thing...
>
> - Original Message -
> From: "Chris Boget" <[EMAIL PROTECTED]>
> To: "Rick Emery" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>;
> "Monty"
> <[EMAIL PROTECTED]>
> Sent: Friday, October 25, 2002 3:41 PM
> Subject: Re: [PHP] extract($_POST)
>
>
> This thread has been great! I've learned so much useful stuff.
>
> > For instance, if you expect a variable called $firstname to contain
> > a name to be stored in a SQL database, be certain it does not
contain
> > SQL commands which can damage your database.
>
> This is another thing I'd be interested in hearing more about. If all
you
> are doing is storing and retrieving data, what commands could possibly
> be defined that could damage your database?
>
> $firstName = "Chris";
> mysql_query( "INSERT INTO names ( first_name ) VALUES ( \"$firstName\"
)"
> );
> $result = mysql_query( "SELECT first_name FROM names" );
> while( $dataArray = mysql_fetch_assoc( $result )) {
> echo $dataArray["first_name"]
>
> }
>
> If $firstName was set by a form submission, what malicious SQL code
could
> damage your database? All you are doing is storing, retreiving and
> displaying
> data...
>
> Chris
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
This is all really simple, actually. Get in the habit, now, of just
using $_POST['var'] directly. Quit assigning it to a simpler variable
name. It's really not that hard to type.
Next, you should never use an _POST, _GET, or _COOKIE var directly in an
SQL query or in anything that echo's it back to the screen.
___ EVERYTHING FROM THE USER MUST BE VALIDATED ___
and you only use that validated value in your SQL and echo's.
I'm in the habit of assigning all of my validated user input into an
$input[] array and using that for any output/SQL further in the page.
---John Holmes...
> -Original Message-
> From: Rick Emery [mailto:remery@;emeryloftus.com]
> Sent: Friday, October 25, 2002 4:27 PM
> To: [EMAIL PROTECTED]; Monty
> Subject: Re: [PHP] extract($_POST)
>
> You can still use extract($_POST).
> It is as safe/vulernable as $_POST['isAdmin'].
>
> In either case, use only variables that you know are yours and be
certain
> these contain
> values which you believe to be safe.
> For instance, if you expect a variable called $firstname to contain a
name
> to be stored in
> a SQL database, be certain it does not contain SQL commands which can
> damage your
> database.
>
> Also, if a cracker simply floods your script with variables, they will
not
> do damage if
> you have verified their contents. For instance:
>
> $isAdmin = "";
> extract($_POST);
> if( $isAdmin=="JohnDoe")
> {
> do secure stuff;
> }
>
> In the above code, if a cracker has inserted a variable called
$isAdmin,
> it will be nulled
> before extracting from the form. Be advised, that a cracker can
create
> his own form with
> $isAdmin in it and submit it to your script. Using $_POST['isAdmin']
will
> NOT protect
> you.
> Bottom line: you can be cracked. There are no certain protections.
>
> - Original Message -
> From: "Monty" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, October 25, 2002 3:13 PM
> Subject: Re: [PHP] extract($_POST)
>
>
> Okay, I really want to understand how to make $_GET and $_POST more
secure
> because it means changing a fundamental way my scripts are now
working.
>
> So, it sounds like what I need to do in order to make form data more
> secure
> is something like this...
>
> $isAdmin = $_POST['isAdmin'];
> $myName = $_POST['myName'];
> $myPrefs = $_GET['myPrefs'];
>
> Instead of this...
>
> extract($_POST);
> extract($_GET);
>
> Is this correct?? Now, I can see how this will prevent a cracker from
> flooding a script with invalid variables that are all extracted into
local
> vars, but, I don't see how this will prevent someone from hijacking
the
> vars
> and inserting their own data. Validating that kind of attack seems
almost
> impossible to do especially for things like forms that collect contact
> info.
> I really don't want to have to validate every field for every legal
> possibility (especially fields like Country).
>
> I've read here that HTTP_REFERER is unreliable and can be easily
spoofed,
> but, is there a more reliable way to know where the $_POST and $_GET
data
> is
> coming from? Perhaps by IP of my server, or using
$_SERVER['SERVER_NAME']?
>
> Is there any superglobal variable that would be unique to my web
server
> that
> CANNOT be spoofed or easily changed by a cracker that I can use as a
check
> to be sure the data is being submitted from a form on my site on not
from
> someone else's site?
>
> Thanks a lot, guys!
>
> Monty
>
>
> > From: [EMAIL PROTECTED] (Paul Nicholson)
> > Organization: WebPower Design
> > Newsgroups: php.general
> > Date: Fri, 25 Oct 2002 13:06:10 -0400
> > To: "Johnson, Kirk" <[EMAIL PROTECTED]>, PHP General
> > <[EMAIL PROTECTED]>
> > Subject: Re: [PHP] extract($_POST)
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote:
> >>> And what should these precautions be? If a malicious user can
submit
> >>> his own form and you are looking for a POST variable, how can you
> >>> ensure that $admin came from your form and not that user's?
> >>
> >> The problem is when a cracker uses form variables in an attempt to
set
> the
> >> values of "flag" variables kept only in the session, for example,
> $isAdmin.
> >> As far as the form variables *you* put in your form, it doesn't
matter
> >> whether the user submits your form or a form they made themselves.
> Those
>
RE: [PHP] extract($_POST)
[snip] > There are many places (websites) wherein you can choose the country from a > pulldown menu. This prevents somebody (somehow) from posting something > illegal. Besides, if the values assigned are numbers (e.g. value="100">My Country) then you can check whether the value > is_numeric() or something. Or, even if it's a text field, perhaps you can > use some regex to make sure that you only accept certain characters. (i.e. > alphabet, etc.) A drop down doesn't save you from validating what the user sent. Just because your form has a drop down, it doesn't mean the one I re-create on my page has one (while I'm spoofing HTTP_REFERRER, mind you). It may have a text box so I can send you any value. ---John Holmes.. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
> This thread has been great! I've learned so much useful stuff.
>
> > For instance, if you expect a variable called $firstname to contain
> > a name to be stored in a SQL database, be certain it does not
contain
> > SQL commands which can damage your database.
>
> This is another thing I'd be interested in hearing more about. If all
you
> are doing is storing and retrieving data, what commands could possibly
> be defined that could damage your database?
>
> $firstName = "Chris";
> mysql_query( "INSERT INTO names ( first_name ) VALUES ( \"$firstName\"
)"
> );
> $result = mysql_query( "SELECT first_name FROM names" );
> while( $dataArray = mysql_fetch_assoc( $result )) {
> echo $dataArray["first_name"]
>
> }
>
> If $firstName was set by a form submission, what malicious SQL code
could
> damage your database? All you are doing is storing, retreiving and
> displaying
> data...
If you are using addslashes() or magic_quotes_gpc on $firstName, then
you're safe from any SQL attack. Also, you are safer because you are
first naming the column your updating, then providing the value. If
there is any injection to affect another column, it'll cause an error.
Say you are doing this to insert a general user who is not an admin
(admin=0)
INSERT INTO table (name,admin) values ('$name',0)
If you are not checking name, and escaping single quotes, a malicious
user could submit this value:
John',1)#
Which will make a name of john, set admin to one, and make the remainder
of the SQL a comment.
---John Holmes...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
No, this can't happen. There can only be one SQL query per
mysql_query().
Google for SQL injection or something and I'm sure you'll find examples.
---John Holmes...
> -Original Message-
> From: Rick Emery [mailto:remery@;emeryloftus.com]
> Sent: Friday, October 25, 2002 4:59 PM
> To: Chris Boget; [EMAIL PROTECTED]; Monty
> Subject: Re: [PHP] extract($_POST)
>
> Lets say you have a statement like:
> $query = "SELECT * FROM mytable WHERE firstname=$firstname";
>
> And if $firstname is set to:
> "xyz"; DELETE FROM mytable
>
> Then this is executed as: SELECT* FROM mytable WHERE
> firstname="xyz";DELETE FROM mytable
>
> This can wipe out your table...a bad thing...
>
> - Original Message -
> From: "Chris Boget" <[EMAIL PROTECTED]>
> To: "Rick Emery" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>;
> "Monty"
> <[EMAIL PROTECTED]>
> Sent: Friday, October 25, 2002 3:41 PM
> Subject: Re: [PHP] extract($_POST)
>
>
> This thread has been great! I've learned so much useful stuff.
>
> > For instance, if you expect a variable called $firstname to contain
> > a name to be stored in a SQL database, be certain it does not
contain
> > SQL commands which can damage your database.
>
> This is another thing I'd be interested in hearing more about. If all
you
> are doing is storing and retrieving data, what commands could possibly
> be defined that could damage your database?
>
> $firstName = "Chris";
> mysql_query( "INSERT INTO names ( first_name ) VALUES ( \"$firstName\"
)"
> );
> $result = mysql_query( "SELECT first_name FROM names" );
> while( $dataArray = mysql_fetch_assoc( $result )) {
> echo $dataArray["first_name"]
>
> }
>
> If $firstName was set by a form submission, what malicious SQL code
could
> damage your database? All you are doing is storing, retreiving and
> displaying
> data...
>
> Chris
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Hello, "Rick Emery" <[EMAIL PROTECTED]> wrote: > Lets say you have a statement like: > $query = "SELECT * FROM mytable WHERE firstname=$firstname"; > > And if $firstname is set to: > "xyz"; DELETE FROM mytable > > Then this is executed as: SELECT* FROM mytable WHERE firstname="xyz";DELETE FROM mytable > > This can wipe out your table...a bad thing... Well, one way you can avoid similar things to happen is, you can do something like, say, create a user that can only SELECT. If the user can only SELECT then it cannot DELETE. - E ...[snip]... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Lets say you have a statement like:
$query = "SELECT * FROM mytable WHERE firstname=$firstname";
And if $firstname is set to:
"xyz"; DELETE FROM mytable
Then this is executed as: SELECT* FROM mytable WHERE firstname="xyz";DELETE FROM
mytable
This can wipe out your table...a bad thing...
- Original Message -
From: "Chris Boget" <[EMAIL PROTECTED]>
To: "Rick Emery" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Monty"
<[EMAIL PROTECTED]>
Sent: Friday, October 25, 2002 3:41 PM
Subject: Re: [PHP] extract($_POST)
This thread has been great! I've learned so much useful stuff.
> For instance, if you expect a variable called $firstname to contain
> a name to be stored in a SQL database, be certain it does not contain
> SQL commands which can damage your database.
This is another thing I'd be interested in hearing more about. If all you
are doing is storing and retrieving data, what commands could possibly
be defined that could damage your database?
$firstName = "Chris";
mysql_query( "INSERT INTO names ( first_name ) VALUES ( \"$firstName\" )" );
$result = mysql_query( "SELECT first_name FROM names" );
while( $dataArray = mysql_fetch_assoc( $result )) {
echo $dataArray["first_name"]
}
If $firstName was set by a form submission, what malicious SQL code could
damage your database? All you are doing is storing, retreiving and displaying
data...
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
This thread has been great! I've learned so much useful stuff.
> For instance, if you expect a variable called $firstname to contain
> a name to be stored in a SQL database, be certain it does not contain
> SQL commands which can damage your database.
This is another thing I'd be interested in hearing more about. If all you
are doing is storing and retrieving data, what commands could possibly
be defined that could damage your database?
$firstName = "Chris";
mysql_query( "INSERT INTO names ( first_name ) VALUES ( \"$firstName\" )" );
$result = mysql_query( "SELECT first_name FROM names" );
while( $dataArray = mysql_fetch_assoc( $result )) {
echo $dataArray["first_name"]
}
If $firstName was set by a form submission, what malicious SQL code could
damage your database? All you are doing is storing, retreiving and displaying
data...
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Hello, "Monty" <[EMAIL PROTECTED]> wrote: > Okay, I really want to understand how to make $_GET and $_POST more secure > because it means changing a fundamental way my scripts are now working. > > So, it sounds like what I need to do in order to make form data more secure > is something like this... > > $isAdmin = $_POST['isAdmin']; > $myName = $_POST['myName']; > $myPrefs = $_GET['myPrefs']; > > Instead of this... > > extract($_POST); > extract($_GET); > > Is this correct?? Yes and no. I think it'd be a better idea to validate your $_POST['something'] or $_GET['something'] before assigning them to $something. > Now, I can see how this will prevent a cracker from > flooding a script with invalid variables that are all extracted into local > vars, but, I don't see how this will prevent someone from hijacking the vars > and inserting their own data. I'm not really sure what you meant by this but the point is nothing is really secure and you should validate the data that'll come from the user. As always pointed out, "never trust the user". > Validating that kind of attack seems almost > impossible to do especially for things like forms that collect contact info. > I really don't want to have to validate every field for every legal > possibility (especially fields like Country). There are many places (websites) wherein you can choose the country from a pulldown menu. This prevents somebody (somehow) from posting something illegal. Besides, if the values assigned are numbers (e.g. My Country) then you can check whether the value is_numeric() or something. Or, even if it's a text field, perhaps you can use some regex to make sure that you only accept certain characters. (i.e. alphabet, etc.) Just some ideas... - E ...[snip]... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
You can still use extract($_POST).
It is as safe/vulernable as $_POST['isAdmin'].
In either case, use only variables that you know are yours and be certain these contain
values which you believe to be safe.
For instance, if you expect a variable called $firstname to contain a name to be
stored in
a SQL database, be certain it does not contain SQL commands which can damage your
database.
Also, if a cracker simply floods your script with variables, they will not do damage if
you have verified their contents. For instance:
$isAdmin = "";
extract($_POST);
if( $isAdmin=="JohnDoe")
{
do secure stuff;
}
In the above code, if a cracker has inserted a variable called $isAdmin, it will be
nulled
before extracting from the form. Be advised, that a cracker can create his own form
with
$isAdmin in it and submit it to your script. Using $_POST['isAdmin'] will NOT protect
you.
Bottom line: you can be cracked. There are no certain protections.
- Original Message -
From: "Monty" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 25, 2002 3:13 PM
Subject: Re: [PHP] extract($_POST)
Okay, I really want to understand how to make $_GET and $_POST more secure
because it means changing a fundamental way my scripts are now working.
So, it sounds like what I need to do in order to make form data more secure
is something like this...
$isAdmin = $_POST['isAdmin'];
$myName = $_POST['myName'];
$myPrefs = $_GET['myPrefs'];
Instead of this...
extract($_POST);
extract($_GET);
Is this correct?? Now, I can see how this will prevent a cracker from
flooding a script with invalid variables that are all extracted into local
vars, but, I don't see how this will prevent someone from hijacking the vars
and inserting their own data. Validating that kind of attack seems almost
impossible to do especially for things like forms that collect contact info.
I really don't want to have to validate every field for every legal
possibility (especially fields like Country).
I've read here that HTTP_REFERER is unreliable and can be easily spoofed,
but, is there a more reliable way to know where the $_POST and $_GET data is
coming from? Perhaps by IP of my server, or using $_SERVER['SERVER_NAME']?
Is there any superglobal variable that would be unique to my web server that
CANNOT be spoofed or easily changed by a cracker that I can use as a check
to be sure the data is being submitted from a form on my site on not from
someone else's site?
Thanks a lot, guys!
Monty
> From: [EMAIL PROTECTED] (Paul Nicholson)
> Organization: WebPower Design
> Newsgroups: php.general
> Date: Fri, 25 Oct 2002 13:06:10 -0400
> To: "Johnson, Kirk" <[EMAIL PROTECTED]>, PHP General
> <[EMAIL PROTECTED]>
> Subject: Re: [PHP] extract($_POST)
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote:
>>> And what should these precautions be? If a malicious user can submit
>>> his own form and you are looking for a POST variable, how can you
>>> ensure that $admin came from your form and not that user's?
>>
>> The problem is when a cracker uses form variables in an attempt to set the
>> values of "flag" variables kept only in the session, for example, $isAdmin.
>> As far as the form variables *you* put in your form, it doesn't matter
>> whether the user submits your form or a form they made themselves. Those
>> form variables are just data you are trying to collect.
>>
>> With register_globals on, PHP takes *all* variables (GET, POST, COOKIE)
>> received from the client and assigns them to global variables. So if the
>> user posts a value for $isAdmin, she can give herself admin privileges.
>>
>> The key is to retrieve *only* the form variables *you* put in the form from
>> the the $_POST array. So don't write a loop and grab *everything* from that
>> array.
>>
>> Kirk
>
> Exactly! Not only should you retrieve *only* the vars you need from POST,
> you should also filter them to make sure they contain what you're looking
> for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha'
> functionI created that as part of a filtering class.
>
> ~Paul
>
>
> - --
> ~Paul Nicholson
> Design Specialist @ WebPower Design
> "The webthe way you want it!"
> [EMAIL PROTECTED]
>
> "It said uses Windows 98 or better, so I loaded Linux!"
> Registered Linux User #183202 using Register Linux System # 81891
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7
> z5+ja1P4NtWUwVMCMsFVt2M=
> =UG2o
> -END PGP SIGNATURE-
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Okay, I really want to understand how to make $_GET and $_POST more secure because it means changing a fundamental way my scripts are now working. So, it sounds like what I need to do in order to make form data more secure is something like this... $isAdmin = $_POST['isAdmin']; $myName = $_POST['myName']; $myPrefs = $_GET['myPrefs']; Instead of this... extract($_POST); extract($_GET); Is this correct?? Now, I can see how this will prevent a cracker from flooding a script with invalid variables that are all extracted into local vars, but, I don't see how this will prevent someone from hijacking the vars and inserting their own data. Validating that kind of attack seems almost impossible to do especially for things like forms that collect contact info. I really don't want to have to validate every field for every legal possibility (especially fields like Country). I've read here that HTTP_REFERER is unreliable and can be easily spoofed, but, is there a more reliable way to know where the $_POST and $_GET data is coming from? Perhaps by IP of my server, or using $_SERVER['SERVER_NAME']? Is there any superglobal variable that would be unique to my web server that CANNOT be spoofed or easily changed by a cracker that I can use as a check to be sure the data is being submitted from a form on my site on not from someone else's site? Thanks a lot, guys! Monty > From: [EMAIL PROTECTED] (Paul Nicholson) > Organization: WebPower Design > Newsgroups: php.general > Date: Fri, 25 Oct 2002 13:06:10 -0400 > To: "Johnson, Kirk" <[EMAIL PROTECTED]>, PHP General > <[EMAIL PROTECTED]> > Subject: Re: [PHP] extract($_POST) > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote: >>> And what should these precautions be? If a malicious user can submit >>> his own form and you are looking for a POST variable, how can you >>> ensure that $admin came from your form and not that user's? >> >> The problem is when a cracker uses form variables in an attempt to set the >> values of "flag" variables kept only in the session, for example, $isAdmin. >> As far as the form variables *you* put in your form, it doesn't matter >> whether the user submits your form or a form they made themselves. Those >> form variables are just data you are trying to collect. >> >> With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) >> received from the client and assigns them to global variables. So if the >> user posts a value for $isAdmin, she can give herself admin privileges. >> >> The key is to retrieve *only* the form variables *you* put in the form from >> the the $_POST array. So don't write a loop and grab *everything* from that >> array. >> >> Kirk > > Exactly! Not only should you retrieve *only* the vars you need from POST, > you should also filter them to make sure they contain what you're looking > for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha' > functionI created that as part of a filtering class. > > ~Paul > > > - -- > ~Paul Nicholson > Design Specialist @ WebPower Design > "The webthe way you want it!" > [EMAIL PROTECTED] > > "It said uses Windows 98 or better, so I loaded Linux!" > Registered Linux User #183202 using Register Linux System # 81891 > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7 > z5+ja1P4NtWUwVMCMsFVt2M= > =UG2o > -END PGP SIGNATURE- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
Yes, but that's what we've been discussing. Nothing is bulletproof, unless your box has no route to the outside world, no Nic, no modem, etc. But, depending on how security conscience (paranoid *G*) you may be, there are different steps to 'add' security, and keep out all but the most determined hackers. I guess if you even want to go crazy overboard with security, you could set a cookie on your form page, and check for it's existance on the processing end. Or randomly generate an image with a number on the form page, and have the user input that number. 1LT John W. Holmes wrote: HTTP_REFERRER can be spoofed, so don't rely on it for much. ---John Holmes... - Original Message - From: "John Nichel" <[EMAIL PROTECTED]> To: "Paul Nicholson" <[EMAIL PROTECTED]> Cc: "Johnson, Kirk" <[EMAIL PROTECTED]>; "PHP General" <[EMAIL PROTECTED]> Sent: Friday, October 25, 2002 2:07 PM Subject: Re: [PHP] extract($_POST) And if you want to take it a step further, to ensure that the values are submitted from YOUR form, check the $_SERVER['HTTP_REFERER'] to see if it's coming from your domain | page. Paul Nicholson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote: And what should these precautions be? If a malicious user can submit his own form and you are looking for a POST variable, how can you ensure that $admin came from your form and not that user's? The problem is when a cracker uses form variables in an attempt to set the values of "flag" variables kept only in the session, for example, $isAdmin. As far as the form variables *you* put in your form, it doesn't matter whether the user submits your form or a form they made themselves. Those form variables are just data you are trying to collect. With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) received from the client and assigns them to global variables. So if the user posts a value for $isAdmin, she can give herself admin privileges. The key is to retrieve *only* the form variables *you* put in the form from the the $_POST array. So don't write a loop and grab *everything* from that array. Kirk Exactly! Not only should you retrieve *only* the vars you need from POST, you should also filter them to make sure they contain what you're looking for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha' functionI created that as part of a filtering class. ~Paul - -- ~Paul Nicholson Design Specialist @ WebPower Design "The webthe way you want it!" [EMAIL PROTECTED] "It said uses Windows 98 or better, so I loaded Linux!" Registered Linux User #183202 using Register Linux System # 81891 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7 z5+ja1P4NtWUwVMCMsFVt2M= =UG2o -END PGP SIGNATURE- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
I thought of this was well and into the PHP documentation about this option. Here's a side note that the documentation includes: Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted. Even thought it's not a sure-fire method, it can be included along with other security methods to increase the amount of security on a script. Ed Curtis On Fri, 25 Oct 2002, John Nichel wrote: > And if you want to take it a step further, to ensure that the values are > submitted from YOUR form, check the $_SERVER['HTTP_REFERER'] to see if > it's coming from your domain | page. > > Paul Nicholson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote: > > > >>>And what should these precautions be? If a malicious user can submit > >>>his own form and you are looking for a POST variable, how can you > >>>ensure that $admin came from your form and not that user's? > >> > >>The problem is when a cracker uses form variables in an attempt to set the > >>values of "flag" variables kept only in the session, for example, $isAdmin. > >>As far as the form variables *you* put in your form, it doesn't matter > >>whether the user submits your form or a form they made themselves. Those > >>form variables are just data you are trying to collect. > >> > >>With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) > >>received from the client and assigns them to global variables. So if the > >>user posts a value for $isAdmin, she can give herself admin privileges. > >> > >>The key is to retrieve *only* the form variables *you* put in the form from > >>the the $_POST array. So don't write a loop and grab *everything* from that > >>array. > >> > >>Kirk > > > > > > Exactly! Not only should you retrieve *only* the vars you need from POST, > > you should also filter them to make sure they contain what you're looking > > for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha' > > functionI created that as part of a filtering class. > > > > ~Paul > > > > > > - -- > > ~Paul Nicholson > > Design Specialist @ WebPower Design > > "The webthe way you want it!" > > [EMAIL PROTECTED] > > > > "It said uses Windows 98 or better, so I loaded Linux!" > > Registered Linux User #183202 using Register Linux System # 81891 > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.0.6 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7 > > z5+ja1P4NtWUwVMCMsFVt2M= > > =UG2o > > -END PGP SIGNATURE- > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
HTTP_REFERRER can be spoofed, so don't rely on it for much. ---John Holmes... - Original Message - From: "John Nichel" <[EMAIL PROTECTED]> To: "Paul Nicholson" <[EMAIL PROTECTED]> Cc: "Johnson, Kirk" <[EMAIL PROTECTED]>; "PHP General" <[EMAIL PROTECTED]> Sent: Friday, October 25, 2002 2:07 PM Subject: Re: [PHP] extract($_POST) > And if you want to take it a step further, to ensure that the values are > submitted from YOUR form, check the $_SERVER['HTTP_REFERER'] to see if > it's coming from your domain | page. > > Paul Nicholson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote: > > > >>>And what should these precautions be? If a malicious user can submit > >>>his own form and you are looking for a POST variable, how can you > >>>ensure that $admin came from your form and not that user's? > >> > >>The problem is when a cracker uses form variables in an attempt to set the > >>values of "flag" variables kept only in the session, for example, $isAdmin. > >>As far as the form variables *you* put in your form, it doesn't matter > >>whether the user submits your form or a form they made themselves. Those > >>form variables are just data you are trying to collect. > >> > >>With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) > >>received from the client and assigns them to global variables. So if the > >>user posts a value for $isAdmin, she can give herself admin privileges. > >> > >>The key is to retrieve *only* the form variables *you* put in the form from > >>the the $_POST array. So don't write a loop and grab *everything* from that > >>array. > >> > >>Kirk > > > > > > Exactly! Not only should you retrieve *only* the vars you need from POST, > > you should also filter them to make sure they contain what you're looking > > for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha' > > functionI created that as part of a filtering class. > > > > ~Paul > > > > > > - -- > > ~Paul Nicholson > > Design Specialist @ WebPower Design > > "The webthe way you want it!" > > [EMAIL PROTECTED] > > > > "It said uses Windows 98 or better, so I loaded Linux!" > > Registered Linux User #183202 using Register Linux System # 81891 > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.0.6 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7 > > z5+ja1P4NtWUwVMCMsFVt2M= > > =UG2o > > -END PGP SIGNATURE- > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
And if you want to take it a step further, to ensure that the values are submitted from YOUR form, check the $_SERVER['HTTP_REFERER'] to see if it's coming from your domain | page. Paul Nicholson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote: And what should these precautions be? If a malicious user can submit his own form and you are looking for a POST variable, how can you ensure that $admin came from your form and not that user's? The problem is when a cracker uses form variables in an attempt to set the values of "flag" variables kept only in the session, for example, $isAdmin. As far as the form variables *you* put in your form, it doesn't matter whether the user submits your form or a form they made themselves. Those form variables are just data you are trying to collect. With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) received from the client and assigns them to global variables. So if the user posts a value for $isAdmin, she can give herself admin privileges. The key is to retrieve *only* the form variables *you* put in the form from the the $_POST array. So don't write a loop and grab *everything* from that array. Kirk Exactly! Not only should you retrieve *only* the vars you need from POST, you should also filter them to make sure they contain what you're looking for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha' functionI created that as part of a filtering class. ~Paul - -- ~Paul Nicholson Design Specialist @ WebPower Design "The webthe way you want it!" [EMAIL PROTECTED] "It said uses Windows 98 or better, so I loaded Linux!" Registered Linux User #183202 using Register Linux System # 81891 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7 z5+ja1P4NtWUwVMCMsFVt2M= =UG2o -END PGP SIGNATURE- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 25 October 2002 11:23 am, Johnson, Kirk wrote: > > And what should these precautions be? If a malicious user can submit > > his own form and you are looking for a POST variable, how can you > > ensure that $admin came from your form and not that user's? > > The problem is when a cracker uses form variables in an attempt to set the > values of "flag" variables kept only in the session, for example, $isAdmin. > As far as the form variables *you* put in your form, it doesn't matter > whether the user submits your form or a form they made themselves. Those > form variables are just data you are trying to collect. > > With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) > received from the client and assigns them to global variables. So if the > user posts a value for $isAdmin, she can give herself admin privileges. > > The key is to retrieve *only* the form variables *you* put in the form from > the the $_POST array. So don't write a loop and grab *everything* from that > array. > > Kirk Exactly! Not only should you retrieve *only* the vars you need from POST, you should also filter them to make sure they contain what you're looking for.is_alpha($_POST['name']). And no, php doesn't have an 'is_alpha' functionI created that as part of a filtering class. ~Paul - -- ~Paul Nicholson Design Specialist @ WebPower Design "The webthe way you want it!" [EMAIL PROTECTED] "It said uses Windows 98 or better, so I loaded Linux!" Registered Linux User #183202 using Register Linux System # 81891 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9uXoKDyXNIUN3+UQRAkugAJ0aftPjxhmV0tSk125UZSTCuWp47QCfaKJ7 z5+ja1P4NtWUwVMCMsFVt2M= =UG2o -END PGP SIGNATURE- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
> And what should these precautions be? If a malicious user can submit > his own form and you are looking for a POST variable, how can you > ensure that $admin came from your form and not that user's? The problem is when a cracker uses form variables in an attempt to set the values of "flag" variables kept only in the session, for example, $isAdmin. As far as the form variables *you* put in your form, it doesn't matter whether the user submits your form or a form they made themselves. Those form variables are just data you are trying to collect. With register_globals on, PHP takes *all* variables (GET, POST, COOKIE) received from the client and assigns them to global variables. So if the user posts a value for $isAdmin, she can give herself admin privileges. The key is to retrieve *only* the form variables *you* put in the form from the the $_POST array. So don't write a loop and grab *everything* from that array. Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
A determined hacker can get through. Period. Additional safeguards might include username/password authentication against a database. You can only make it more difficult for a hacker to break-in. You can never have absolute certainty he won't. - Original Message - From: "Chris Boget" <[EMAIL PROTECTED]> To: "Rick Emery" <[EMAIL PROTECTED]> Cc: "PHP General" <[EMAIL PROTECTED]> Sent: Friday, October 25, 2002 8:53 AM Subject: Re: [PHP] extract($_POST) > The more secure method ensures it MUST come from a form. Be > advised: the user can create his own form with $admin as a variable > and submit it to your PHP script. Therefore, additional precautions > and authentication are warranted. And what should these precautions be? If a malicious user can submit his own form and you are looking for a POST variable, how can you ensure that $admin came from your form and not that user's? And if that same user can hijack a session, that makes it so you have even less precautions you can take. I'm honestly interested in this. I've read the security section of the manual, read similar threads and each time, I've come to the conclusion that you can really only ever be so secure. And that all of the tests, checks, balances you may implement are all for naught where a really determined malicious user is concerned. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
> The more secure method ensures it MUST come from a form. Be > advised: the user can create his own form with $admin as a variable > and submit it to your PHP script. Therefore, additional precautions > and authentication are warranted. And what should these precautions be? If a malicious user can submit his own form and you are looking for a POST variable, how can you ensure that $admin came from your form and not that user's? And if that same user can hijack a session, that makes it so you have even less precautions you can take. I'm honestly interested in this. I've read the security section of the manual, read similar threads and each time, I've come to the conclusion that you can really only ever be so secure. And that all of the tests, checks, balances you may implement are all for naught where a really determined malicious user is concerned. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
$_GET is definately insecure because the user can insert values into the URL line,
which may expose data which should be secure (depending upon how you've written your
scripts).
$_POST is more secure, if you add additional protective coding. An excellent example
was provided a couple days ago. In the following, assume $admin must be set to
"trustme" and is set from a form:
INSECURE method 1:
if( ISSET($admin) )
{
print $sensitive_data;
}
INSECURE method 2:
if( $admin=="trustme" )
{
print $sensitive data;
}
MORE SECURE method:
$admin = "";
extract($_POST);
if( $admin == "trustme" )
{
print $sensitive_data;
}
The insecure methods can be fooled by the user guessing/inserting a variable named
$admin, set to "trustme" in the URL.
The more secure method ensures it MUST come from a form. Be advised: the user can
create his own form with $admin as a variable and submit it to your PHP script.
Therefore, additional precautions and authentication are warranted.
- Original Message -
From: "Monty" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 25, 2002 12:37 AM
Subject: Re: [PHP] extract($_POST)
I'm devastated to hear that extract($_POST) or extract($_GET) are security
risks because that's the method I went with for a bunch of scripts I'm
writing now. But I don't understand how this...
$admin = $_POST['admin'];
... is more secure? Isn't the security risk that they can hijack your var
data? If so, I don't see how the above would make it possible to know
whether the data in $_POST isn't coming from your own scripts. Especially
for forms where it's not really efficient to validate every possibility for
a field, such as a Country field.
But maybe I'm missing the point, and if so I'd like to understand so I can
make my scripts more secure when passing data. It seems like I will need to
basically re-define every form field and GET variable at the beginning of
each script literally.
Monty
> From: [EMAIL PROTECTED] (Mike Ford)
> Newsgroups: php.general
> Date: Thu, 24 Oct 2002 18:41:04 +0100
> To: "'1LT John W. Holmes'" <[EMAIL PROTECTED]>, Rick Emery
> <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: RE: [PHP] extract($_POST)
>
>> -Original Message-
>> From: 1LT John W. Holmes [mailto:holmes072000@;charter.net]
>> Sent: 23 October 2002 19:51
>>
>> Say you have something like this:
>>
>> if($_POST['name'] == "John")
>> { $admin = TRUE; }
>>
>> if($admin)
>> { show_sensitive_data(); }
>>
>> Now, if you're using extract(), I can send $admin through the
>> post data and
>> you'll extract it into your script. That's where the security
>> flaw lies, but
>> the flaw is in the programming, not PHP.
>>
>> You can have a secure example by doing this:
>>
>> $admin = FALSE;
>> if($_POST['name'] == "John")
>> { $admin = TRUE; }
>
> Or just $admin = $_POST['name']=="John";
>
> Actually, I'd also collapse this into the subsequent if, and write it like
> this:
>
> if ($admin = $_POST['name']=="John"):
> show_sensitive_data();
> endif;
>
> I love languages where assignments are expressions!
>
> Cheers!
>
> Mike
>
> -
> Mike Ford, Electronic Information Services Adviser,
> Learning Support Services, Learning & Information Services,
> JG125, James Graham Building, Leeds Metropolitan University,
> Beckett Park, LEEDS, LS6 3QS, United Kingdom
> Email: [EMAIL PROTECTED]
> Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] extract($_POST)
I'm devastated to hear that extract($_POST) or extract($_GET) are security
risks because that's the method I went with for a bunch of scripts I'm
writing now. But I don't understand how this...
$admin = $_POST['admin'];
... is more secure? Isn't the security risk that they can hijack your var
data? If so, I don't see how the above would make it possible to know
whether the data in $_POST isn't coming from your own scripts. Especially
for forms where it's not really efficient to validate every possibility for
a field, such as a Country field.
But maybe I'm missing the point, and if so I'd like to understand so I can
make my scripts more secure when passing data. It seems like I will need to
basically re-define every form field and GET variable at the beginning of
each script literally.
Monty
> From: [EMAIL PROTECTED] (Mike Ford)
> Newsgroups: php.general
> Date: Thu, 24 Oct 2002 18:41:04 +0100
> To: "'1LT John W. Holmes'" <[EMAIL PROTECTED]>, Rick Emery
> <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: RE: [PHP] extract($_POST)
>
>> -Original Message-
>> From: 1LT John W. Holmes [mailto:holmes072000@;charter.net]
>> Sent: 23 October 2002 19:51
>>
>> Say you have something like this:
>>
>> if($_POST['name'] == "John")
>> { $admin = TRUE; }
>>
>> if($admin)
>> { show_sensitive_data(); }
>>
>> Now, if you're using extract(), I can send $admin through the
>> post data and
>> you'll extract it into your script. That's where the security
>> flaw lies, but
>> the flaw is in the programming, not PHP.
>>
>> You can have a secure example by doing this:
>>
>> $admin = FALSE;
>> if($_POST['name'] == "John")
>> { $admin = TRUE; }
>
> Or just $admin = $_POST['name']=="John";
>
> Actually, I'd also collapse this into the subsequent if, and write it like
> this:
>
> if ($admin = $_POST['name']=="John"):
> show_sensitive_data();
> endif;
>
> I love languages where assignments are expressions!
>
> Cheers!
>
> Mike
>
> -
> Mike Ford, Electronic Information Services Adviser,
> Learning Support Services, Learning & Information Services,
> JG125, James Graham Building, Leeds Metropolitan University,
> Beckett Park, LEEDS, LS6 3QS, United Kingdom
> Email: [EMAIL PROTECTED]
> Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
