Re: [PHP] Re: setcookie security concerns [medium]
Rafael:
?php
$thestyle= htmlentities($_POST['thestyle']);
setcookie ('thestyle', $set, time()+31536000, '/', '', 0);
header(Location: $HTTP_REFERER);
?
Actually, you receive $set via GET, so you should use $_GET
instead of $_POST.
Yes, you are correct.
In my example --
http://www.sperling.com/examples/styleswitch/
-- the value doesn't look like it is being added to the url and thus
I mistakenly thought it was a POST. I wonder why the value isn't
apparently attached to the url in this case?
tedd
--
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: setcookie security concerns [medium]
Rafael wrote:
Actually, you receive $set via GET, so you should use $_GET
instead of $_POST. A lot of people use $_REQUEST (wich is a
combination of $_POST, $_GET and $_COOKIE -check the manual), but I
read somewhere that this isn't a good practice, though I don't
recall why :p
From what I've read (PHP Cookbook by Sklar and other sources) the
reason why you don't want to use $_REQUEST is because it holds all
the variables from six global arrays, namely $_GET, $_POST, $_FILES,
$_COOKIE, $_SERVER, and $_ENV.
When PHP creates $_REQUEST, it does so by adding the global arrays
together in a certain order, namely EGPCS. Normally, this would be
OK, but if two (or more) of those arrays have a key with the same
name, then that key value will be replaced with the last value read.
For example, the value provided by $_GET('mykey') will be replaced by
the value found in $_COOKIE ('mykey') in generating the value for
$_REQUEST('mykey').
So, if you use $_REQUEST, then you can't reply upon where its values
are derived.
tedd
--
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: setcookie security concerns [medium]
Rafael wrote: A tipical example would be a login script that uses the data as it arrives, for example: $login = $_POST['login']; $passw = $_POST['passw']; $sql = SELECT * FROM user\n .WHERE( login = '$login' AND passw = '$passw' ); In this case, what happens if I send something like login: ' OR '1'='1' OR '0 passw: doesnt care ? (I avoided the ' in the passw, just in case) Well, we'll end up with an SQL similar to this SELECT * FROM user WHERE( login = '' OR '1'='1' OR '0' AND passw = 'doesnt care' ) and because of the priority of the AND / OR, we would have 3 separated conditions each enough to validate the user, as '1'='1' is true, then we have a validated user. At first, your description confused me, but now I understand. You simply want to keep a user out of your code. In other words, if you don't validate the input, then a user can alter your code by injecting additional code into your query to bypass your authorization protocol -- very clever. Thanks for the lesson. tedd -- http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: setcookie security concerns [medium]
I just picked up this thread, so excuse me if I'm repeating or have totally missed the point. Another concern I picked up from a PHP security book is using '--' - which simply comments out the remainder of the line (with MySQL anyway). Therefore if your SQL is SELECT * FROM table WHERE user = '$user' AND pass = '$pass' a malicious visitor could enter a valid username followed by '-- which may allow them entry to that person's account by creating the following: SELECT * FROM table WHERE user = 'valid_user'--' AND pass = '$pass' Obviously restricting/validating form input entry would avoid this issue. HTH, Kevin -Original Message- From: tedd [mailto:[EMAIL PROTECTED] Sent: 17 March 2006 14:49 To: php-general@lists.php.net; Rafael Subject: Re: [PHP] Re: setcookie security concerns [medium] Rafael wrote: A tipical example would be a login script that uses the data as it arrives, for example: $login = $_POST['login']; $passw = $_POST['passw']; $sql = SELECT * FROM user\n .WHERE( login = '$login' AND passw = '$passw' ); In this case, what happens if I send something like login: ' OR '1'='1' OR '0 passw: doesnt care ? (I avoided the ' in the passw, just in case) Well, we'll end up with an SQL similar to this SELECT * FROM user WHERE( login = '' OR '1'='1' OR '0' AND passw = 'doesnt care' ) and because of the priority of the AND / OR, we would have 3 separated conditions each enough to validate the user, as '1'='1' is true, then we have a validated user. At first, your description confused me, but now I understand. You simply want to keep a user out of your code. In other words, if you don't validate the input, then a user can alter your code by injecting additional code into your query to bypass your authorization protocol -- very clever. Thanks for the lesson. tedd -- http://sperling.com -- 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] Re: setcookie security concerns [medium]
(Comments inline)
tedd wrote:
[···]
From what I've read (PHP Cookbook by Sklar and other sources) the
reason why you don't want to use $_REQUEST is because it holds all the
variables from six global arrays, namely $_GET, $_POST, $_FILES,
$_COOKIE, $_SERVER, and $_ENV.
Actually, the super-global variables used in $_REQUEST are $_GET,
$_POST and $_COOKIE¹, and though there is a gpc directive I'm not sure
if you can control the order they are read (but my guess would be that
you do)
¹http://php.net/manual/en/reserved.variables.php#reserved.variables.request
When PHP creates $_REQUEST, it does so by adding the global arrays
together in a certain order, namely EGPCS. Normally, this would be OK,
but if two (or more) of those arrays have a key with the same name, then
that key value will be replaced with the last value read. For example,
the value provided by $_GET('mykey') will be replaced by the value found
in $_COOKIE ('mykey') in generating the value for $_REQUEST('mykey').
So, if you use $_REQUEST, then you can't reply upon where its values are
derived.
Well, I still don't remember the reason, but this could be a valid one
:) By the way, these are variables (arrays), so you should use
square-brackets instead of parenthesis to specify an index (e.g.
$_SERVER['SCRIPT_NAME'])
--
Atentamente,
J. Rafael Salazar Magaña
Innox - Innovación Inteligente
Tel: +52 (33) 3615 5348 ext. 205 / 01 800 2-SOFTWARE
http://www.innox.com.mx
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: setcookie security concerns [medium]
The value doesn't show up in the URL as you are redirecting the user back to
the referring URL... so only the referrer will be shown (unless the
redirecting script breaks :) )
Dan
-
Dan Parry
Senior Developer
Virtua Webtech Ltd
http://www.virtuawebtech.co.uk
-Original Message-
From: tedd [mailto:[EMAIL PROTECTED]
Sent: 17 March 2006 14:30
To: php-general@lists.php.net; Rafael
Subject: Re: [PHP] Re: setcookie security concerns [medium]
Rafael:
?php
$thestyle= htmlentities($_POST['thestyle']);
setcookie ('thestyle', $set, time()+31536000, '/', '', 0);
header(Location: $HTTP_REFERER);
?
Actually, you receive $set via GET, so you should use $_GET
instead of $_POST.
Yes, you are correct.
In my example --
http://www.sperling.com/examples/styleswitch/
-- the value doesn't look like it is being added to the url and thus
I mistakenly thought it was a POST. I wonder why the value isn't
apparently attached to the url in this case?
tedd
--
http://sperling.com
--
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] Re: setcookie security concerns [medium]
On Friday 17 March 2006 15:10, Kevin Davies - Bonhurst Consulting wrote: I just picked up this thread, so excuse me if I'm repeating or have totally missed the point. Another concern I picked up from a PHP security book is using '--' - which simply comments out the remainder of the line (with MySQL anyway). Therefore if your SQL is SELECT * FROM table WHERE user = '$user' AND pass = '$pass' a malicious visitor could enter a valid username followed by '-- which may allow them entry to that person's account by creating the following: SELECT * FROM table WHERE user = 'valid_user'--' AND pass = '$pass' A benefit to using something like PEAR::DB is access to the quotesmart() function, which quotes the input for you. Your query can then look like SELECT * FROM table WHERE user=$q_user AND pass=$q_pass q_user and q_pass are derived from form input which is passed to quotesmart(). Even if funky characters like ' and -- are included, the quoting should help prevent injection. Validating input helps, but some input literally can be most characters under the sun. It's easier to defend the entire system with some general purpose protections than try to guess every attack (imo). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: setcookie security concerns [medium]
(Comments inline)
tedd wrote:
[···]
One last question, considering the above code, would the following code
be a suitable replacement?
?php
$thestyle= htmlentities($_POST['thestyle']);
setcookie ('thestyle', $set, time()+31536000, '/', '', 0);
header(Location: $HTTP_REFERER);
?
Actually, you receive $set via GET, so you should use $_GET instead of
$_POST. A lot of people use $_REQUEST (wich is a combination of $_POST,
$_GET and $_COOKIE —check the manual), but I read somewhere that this
isn't a good practice, though I don't recall why :p
$set = $_GET['set'];
or even better would be something like
$set = ( isset($_GET['set']) ? $_GET['set'] : $default_value );
I've used htmlentities() before to filter out user's input, but I don't
know if that's sufficient to protect from all types of injections -- is it?
No, it doesn't suffice this way --it does for the script we're talking
about, but that's because you only use the data as part of the HTML
code, so no more harm can be done with it.
A tipical example would be a login script that uses the data as it
arrives, for example:
$login = $_POST['login'];
$passw = $_POST['passw'];
$sql = SELECT * FROM user\n
.WHERE( login = '$login' AND passw = '$passw' );
In this case, what happens if I send something like
login: ' OR '1'='1' OR '0
passw: doesnt care
? (I avoided the ' in the passw, just in case)
Well, we'll end up with an SQL similar to this
SELECT * FROM user
WHERE( login = '' OR '1'='1' OR '0' AND passw = 'doesnt care' )
and because of the priority of the AND / OR, we would have 3 separated
conditions each enough to validate the user, as '1'='1' is true, then we
have a validated user.
Now, if I can do this, I could change the logic a little...
login: admin' AND '1'='1' OR '0
WHERE( login = 'admin' AND '1'='1' OR '0' AND passw = 'doesnt care' )
In this case you should care about ' and (depending on which one are
you using) Again, I read somewhere that the safest way is to use
(emulated?) prepared SQL statements, such the ? SQL-parameters in
ADODB, PEAR-DB and others.
By the way, even causing an SQL error that is displayed to the user
(the whole message or just a part of it) can reveal info that could be
used to bypass your protection.
--
Atentamente,
J. Rafael Salazar Magaña
Innox - Innovación Inteligente
Tel: +52 (33) 3615 5348 ext. 205 / 01 800 2-SOFTWARE
http://www.innox.com.mx
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
