Re: [PHP] Script ID?
At 1:47 PM -0400 5/21/11, Adam Richardson wrote: On Sat, May 21, 2011 at 10:11 AM, tedd mailto:t...@sperling.comt...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternativeshttp://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? Cheers, tedd Tedd, I'm sorry for the confusion. When I referenced that article, I was speaking to Alex as to why it wouldn't be prudent for you to use PHP_SELF (as he had suggested to avoid an additional function call) as opposed to what you were currently using, basename($_SERVER['SCRIPT_FILENAME']). My point, and the point of the article, was that PHP_SELF requires special precautions. However, script_filename is not susceptible to this type of attack, as it does not include data from the user: http://php.about.com/od/learnphp/qt/_SERVER_PHP.htmhttp://php.about.com/od/learnphp/qt/_SERVER_PHP.htm In fact, basename($_SERVER['SCRIPT_FILENAME']), and basename(__FILE__) were two of the mitigation methods mentioned in the closing of the article. http://php.about.com/od/learnphp/qt/_SERVER_PHP.htmTry it out on your server: h1PHP_SELF (dangerous)/h1 p?php echo $_SERVER['PHP_SELF']; ?/p h1$_SERVER['SCRIPT_FILENAME']/h1 p?php echo $_SERVER['SCRIPT_FILENAME']; ?/p h1$_SERVER['REQUEST_URI'] (dangerous)/h1 p?php echo $_SERVER['REQUEST_URI']; ?/p h1__FILE__/h1 p?php echo __FILE__; ?/p h1basename(__FILE__)/h1 p?php echo basename(__FILE__); ?/p h1basename($_SERVER['SCRIPT_NAME'])/h1 p?php echo basename($_SERVER['SCRIPT_NAME']); ?/p Try to enter the attack vector and you'll see PHP_SELF could be terrible, but the basename option for script_filename and __FILE__ are immune. Again, sorry for the confusion. Adam Adam: Very interesting. As I understand things, to remove a XSS threat from the method, you have to get the script name from something other than a SuperGlobal because SuperGlobals are subject to XXS attacks, right? As such, using a predefined constant should be safe. I don't know how, nor where, PHP gets the value, but I'm assuming it's not from something that can be altered by someone outside the server. So, is that the reason why you say that using __FILE__ is better at getting the running script's name than using $_SERVER['PHP_SELF']? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 3:11 PM, tedd t...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? If you want the form to submit to the same URL that generated the form, I'd recommend using $_SERVER['REQUEST_URI']. You can also omit the action attribute entirely which, in my experience, will cause the browser to submit to the current URL. I have no idea whether that's part of the HTML spec, but that's the behaviour I've always observed. Alternatively, by my reckoning, you could make your use of PHP_SELF safe by applying rawurlencode to $self when you put it in the action, but that's only after 30 seconds of thinking about it. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
RE: [PHP] Script ID?
I use
define('page1, 1);
Richard L. Buskirk
-Original Message-
From: tedd [mailto:t...@sperling.com]
Sent: Saturday, May 21, 2011 10:11 AM
To: PHP General
Subject: [PHP] Script ID?
Hi gang:
Okay, so,what's the best (i.e., most secure) way for your script to
identify itself *IF* you plan on using that information later, such
as the value in an action attribute in a form?
For example, I was using:
$self = basename($_SERVER['SCRIPT_NAME']);
form name=my_form action=?php echo($self); ? method=post
However, that was susceptible to XSS.
http://www.mc2design.com/blog/php_self-safe-alternatives
says a simple action=# would work.
But is there a better way?
What would do you do solve this?
Cheers,
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] Script ID?
On Sat, 2011-05-21 at 10:11 -0400, tedd wrote:
Hi gang:
Okay, so,what's the best (i.e., most secure) way for your script to
identify itself *IF* you plan on using that information later, such
as the value in an action attribute in a form?
For example, I was using:
$self = basename($_SERVER['SCRIPT_NAME']);
form name=my_form action=?php echo($self); ? method=post
However, that was susceptible to XSS.
http://www.mc2design.com/blog/php_self-safe-alternatives
says a simple action=# would work.
But is there a better way?
What would do you do solve this?
Cheers,
tedd
--
---
http://sperling.com/
I never use the action attribute if the form is posting to itself, as
the default action I've seen in any browser since the days of IE3 has
been for forms to post to themselves if no other action has been
specified. Having read that link you posted, I realise that missing the
action attribute out altogether would too be affected by the base
element.
However, looking at the output of $_SERVER again, couldn't you just
subtract the value of PATH_INFO from the value of PHP_SELF, or only use
the portion of PHP self that didn't include PATH_INFO?
?php
if(isset($_SERVER['PATH_INFO'])
{
$safe_self = substr($_SERVER['PHP_SELF'], 0,
strpos($_SERVER['PHP_SELF'], $_SERVER['PATH_INFO']));
}
else
{
$safe_self = $_SERVER['PHP_SELF'];
}
echo $safe_self;
?
I've just tested this here and it seems to do the trick
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
RE: [PHP] Script ID?
So sorry Tedd,
I was typing away with the rest of that and after hitting send I
notice all I sent was the define.
define('PAGE_1', 1);
I use define because sometimes I want o know what script included another
and if that script does not have a defined value I do not allow it to run.
Just be careful I noticed with integers it will fail to hold the value if it
has a leading zero.
Richard L. Buskirk
-Original Message-
From: tedd [mailto:t...@sperling.com]
Sent: Saturday, May 21, 2011 10:11 AM
To: PHP General
Subject: [PHP] Script ID?
Hi gang:
Okay, so,what's the best (i.e., most secure) way for your script to
identify itself *IF* you plan on using that information later, such
as the value in an action attribute in a form?
For example, I was using:
$self = basename($_SERVER['SCRIPT_NAME']);
form name=my_form action=?php echo($self); ? method=post
However, that was susceptible to XSS.
http://www.mc2design.com/blog/php_self-safe-alternatives
says a simple action=# would work.
But is there a better way?
What would do you do solve this?
Cheers,
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] Script ID?
On 21 May 2011 16:18, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 3:11 PM, tedd t...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? If you want the form to submit to the same URL that generated the form, I'd recommend using $_SERVER['REQUEST_URI']. You can also omit the action attribute entirely which, in my experience, will cause the browser to submit to the current URL. I have no idea whether that's part of the HTML spec, but that's the behaviour I've always observed. REQUEST_URI is as susceptible to XSS as the others. Omitting url entirely (in case of posting a form, say) works in most browsers but is known to fail in others (atm I can't recall which but Google should know). Both '?' and '#' will generally work, but are prone to problems with the base element. Alternatively, by my reckoning, you could make your use of PHP_SELF safe by applying rawurlencode to $self when you put it in the action, but that's only after 30 seconds of thinking about it. rawurlencode encodes forward slashes (and many other things). Not what you're looking for. Apart from that, there is no single solution to the issue: if you're doing url rewrites, then you could use your route-to-url function instead of relying on any server variables. If your script is called directly instead, then use the part of the request uri up till and including the match for __FILE__. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 3:35 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 16:18, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 3:11 PM, tedd t...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? If you want the form to submit to the same URL that generated the form, I'd recommend using $_SERVER['REQUEST_URI']. You can also omit the action attribute entirely which, in my experience, will cause the browser to submit to the current URL. I have no idea whether that's part of the HTML spec, but that's the behaviour I've always observed. REQUEST_URI is as susceptible to XSS as the others. Omitting url entirely (in case of posting a form, say) works in most browsers but is known to fail in others (atm I can't recall which but Google should know). Both '?' and '#' will generally work, but are prone to problems with the base element. Yup, should have said that anything you use should be escaped. Alternatively, by my reckoning, you could make your use of PHP_SELF safe by applying rawurlencode to $self when you put it in the action, but that's only after 30 seconds of thinking about it. rawurlencode encodes forward slashes (and many other things). Not what you're looking for. Note that I said your use, and tedd is running basename on the PHP_SELF variable before using it so the escaping of forward slashes is not an issue here hence why I didn't mention it. Apart from that, there is no single solution to the issue: if you're doing url rewrites, then you could use your route-to-url function instead of relying on any server variables. If your script is called directly instead, then use the part of the request uri up till and including the match for __FILE__. There is a single solution... know what URL you should be using at any given point without making it depend on user(/browser)-supplied data. If you don't know what URL you should be using at any given point, your architecture is fundamentally flawed, whether than means passing it into shared code from elsewhere, or using a single block of code to generate your URLs. In my opinion you should never be generating URLs based on the URL that was used to request the page. If you must generate it using that source, rawurlencode is still the way to go. To get around the forward slash issue, replace all / with ~~~ (or similar text that won't be modified by rawurlencode), run rawurlencode then replace ~~~ with /. Wrap that up in a nice little function, and apply liberally. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On 21 May 2011 17:01, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 3:35 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 16:18, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 3:11 PM, tedd t...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? If you want the form to submit to the same URL that generated the form, I'd recommend using $_SERVER['REQUEST_URI']. You can also omit the action attribute entirely which, in my experience, will cause the browser to submit to the current URL. I have no idea whether that's part of the HTML spec, but that's the behaviour I've always observed. REQUEST_URI is as susceptible to XSS as the others. Omitting url entirely (in case of posting a form, say) works in most browsers but is known to fail in others (atm I can't recall which but Google should know). Both '?' and '#' will generally work, but are prone to problems with the base element. Yup, should have said that anything you use should be escaped. Alternatively, by my reckoning, you could make your use of PHP_SELF safe by applying rawurlencode to $self when you put it in the action, but that's only after 30 seconds of thinking about it. rawurlencode encodes forward slashes (and many other things). Not what you're looking for. Note that I said your use, and tedd is running basename on the PHP_SELF variable before using it so the escaping of forward slashes is not an issue here hence why I didn't mention it. Apart from that, there is no single solution to the issue: if you're doing url rewrites, then you could use your route-to-url function instead of relying on any server variables. If your script is called directly instead, then use the part of the request uri up till and including the match for __FILE__. There is a single solution... know what URL you should be using at any given point without making it depend on user(/browser)-supplied data. If you don't know what URL you should be using at any given point, your architecture is fundamentally flawed, whether than means passing it into shared code from elsewhere, or using a single block of code to generate your URLs. In my opinion you should never be generating URLs based on the URL that was used to request the page. That is not a single solution - that is a general approach, for which the solution will look different based on whether or not you use url rewriting, actual script filenames, etc. etc. The point wasn't that there are no solutions, just that the solution to Tedd's problem depends upon how he's doing PHP in general. If you must generate it using that source, rawurlencode is still the way to go. To get around the forward slash issue, replace all / with ~~~ (or similar text that won't be modified by rawurlencode), run rawurlencode then replace ~~~ with /. Wrap that up in a nice little function, and apply liberally. Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 4:07 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:01, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 3:35 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 16:18, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 3:11 PM, tedd t...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? If you want the form to submit to the same URL that generated the form, I'd recommend using $_SERVER['REQUEST_URI']. You can also omit the action attribute entirely which, in my experience, will cause the browser to submit to the current URL. I have no idea whether that's part of the HTML spec, but that's the behaviour I've always observed. REQUEST_URI is as susceptible to XSS as the others. Omitting url entirely (in case of posting a form, say) works in most browsers but is known to fail in others (atm I can't recall which but Google should know). Both '?' and '#' will generally work, but are prone to problems with the base element. Yup, should have said that anything you use should be escaped. Alternatively, by my reckoning, you could make your use of PHP_SELF safe by applying rawurlencode to $self when you put it in the action, but that's only after 30 seconds of thinking about it. rawurlencode encodes forward slashes (and many other things). Not what you're looking for. Note that I said your use, and tedd is running basename on the PHP_SELF variable before using it so the escaping of forward slashes is not an issue here hence why I didn't mention it. Apart from that, there is no single solution to the issue: if you're doing url rewrites, then you could use your route-to-url function instead of relying on any server variables. If your script is called directly instead, then use the part of the request uri up till and including the match for __FILE__. There is a single solution... know what URL you should be using at any given point without making it depend on user(/browser)-supplied data. If you don't know what URL you should be using at any given point, your architecture is fundamentally flawed, whether than means passing it into shared code from elsewhere, or using a single block of code to generate your URLs. In my opinion you should never be generating URLs based on the URL that was used to request the page. That is not a single solution - that is a general approach, for which the solution will look different based on whether or not you use url rewriting, actual script filenames, etc. etc. The point wasn't that there are no solutions, just that the solution to Tedd's problem depends upon how he's doing PHP in general. I disagree, but I think it's more semantics than substance. By taking the general approach of knowing what URLs you should be using everywhere in your site without needing to take hints from the current URL, the problem goes away... ergo it's a solution. The way you know what URLs you need at any given point may look slightly different (whether you hard-code them or use a central function to generate them), but the general approach is a solution to the problem of XSS coming from the use of derived URLs. If you must generate it using that source, rawurlencode is still the way to go. To get around the forward slash issue, replace all / with ~~~ (or similar text that won't be modified by rawurlencode), run rawurlencode then replace ~~~ with /. Wrap that up in a nice little function, and apply liberally. Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote: *snip* Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart Having to replace several times just in order to figure out the path to your script is pointless if you know the name of the script (which you always do - it's __FILE__ ) and you're using a one-to-one request-to-script scheme. Then just grab the part of the url up to and including your scriptname. Note I used the word good - doing several str_replace() and other calls is not what I consider a good solution if there's something simpler available with as good a result. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote: *snip* Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart Having to replace several times just in order to figure out the path to your script is pointless if you know the name of the script (which you always do - it's __FILE__ ) and you're using a one-to-one request-to-script scheme. Then just grab the part of the url up to and including your scriptname. Well, it would be basename(__FILE__), but that's beside the point. In this particular case, where the PHP filename is the last part of the URL, that will indeed work. However, as you have pointed out several times that's not always the case and I tend to write generic, defensive code rather than make assumptions. Note I used the word good - doing several str_replace() and other calls is not what I consider a good solution if there's something simpler available with as good a result. Obviously that's your choice to make, but these days I very rarely work on projects where there is a one-to-one mapping, and even if I did I would not rely on that always being the case. I've worked on a number of projects where the URL structure has been massively changed (a couple from one-to-one to controller-based) where it would have taking an excessive amount of time to undo that assumption. Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely future-proof and takes no more effort than the manipulation you are doing on __FILE__ to get the same result. Given the choice I'll always go for 10% extra work now to save 90% extra work later, even if it's only potential work later. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote: On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote: *snip* Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart Having to replace several times just in order to figure out the path to your script is pointless if you know the name of the script (which you always do - it's __FILE__ ) and you're using a one-to-one request-to-script scheme. Then just grab the part of the url up to and including your scriptname. Well, it would be basename(__FILE__), but that's beside the point. In this particular case, where the PHP filename is the last part of the URL, that will indeed work. However, as you have pointed out several times that's not always the case and I tend to write generic, defensive code rather than make assumptions. Note I used the word good - doing several str_replace() and other calls is not what I consider a good solution if there's something simpler available with as good a result. Obviously that's your choice to make, but these days I very rarely work on projects where there is a one-to-one mapping, and even if I did I would not rely on that always being the case. I've worked on a number of projects where the URL structure has been massively changed (a couple from one-to-one to controller-based) where it would have taking an excessive amount of time to undo that assumption. Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely future-proof and takes no more effort than the manipulation you are doing on __FILE__ to get the same result. Given the choice I'll always go for 10% extra work now to save 90% extra work later, even if it's only potential work later. -Stuart I'm not sure if anyone had the chance to look over my code suggestion, but afaict it does the job, although I've only given it very rudimentary testing. It doesn't require you to know the page the form is on in advance, it strips out the correct info from the supplied URL, and is simple enough that you could even run it all on one line if you didn't mind nested tertiary conditionals. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote:
*snip*
Again, this depends upon what your url scheme looks like - and without
knowing that, there's simple no clue as to whether or not this is a
good solution to the problem (though it might be a good solution to A
problem).
Again, I disagree. If you have an example of a URL structure where this
would not work I'd love to hear it.
-Stuart
Having to replace several times just in order to figure out the path
to your script is pointless if you know the name of the script (which
you always do - it's __FILE__ ) and you're using a one-to-one
request-to-script scheme. Then just grab the part of the url up to and
including your scriptname.
Well, it would be basename(__FILE__), but that's beside the point. In this
particular case, where the PHP filename is the last part of the URL, that
will indeed work. However, as you have pointed out several times that's not
always the case and I tend to write generic, defensive code rather than make
assumptions.
Note I used the word good - doing several str_replace() and other
calls is not what I consider a good solution if there's something
simpler available with as good a result.
Obviously that's your choice to make, but these days I very rarely work on
projects where there is a one-to-one mapping, and even if I did I would not
rely on that always being the case. I've worked on a number of projects
where the URL structure has been massively changed (a couple from one-to-one
to controller-based) where it would have taking an excessive amount of time
to undo that assumption.
Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
future-proof and takes no more effort than the manipulation you are doing on
__FILE__ to get the same result. Given the choice I'll always go for 10%
extra work now to save 90% extra work later, even if it's only potential
work later.
-Stuart
I'm not sure if anyone had the chance to look over my code suggestion, but
afaict it does the job, although I've only given it very rudimentary
testing. It doesn't require you to know the page the form is on in advance,
it strips out the correct info from the supplied URL, and is simple enough
that you could even run it all on one line if you didn't mind nested
tertiary conditionals.
If 404 responses show a custom page containing a form that uses your code
then it's still an XSS risk, but other than that it looks safe. However,
based on that single risk (and there may be others) I'd never use it because
you never know when someone will change the server config.
-Stuart
What would the risk on the 404 page be? I must admit, I don't know a huge
amount about XSS attacks, so this one is new to me.
A similar URL to the one in the URL tedd posted (
http://www.mc2design.com/blog/php_self-safe-alternatives).
Something like this...
http://www.server.com/%22%3E%3Cscript%3Ealert('xss attack')%3C/script%3E
That script code will not be seen as PATH_INFO, it will simply be part of
the URL.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Re: [PHP] Script ID?
On Sat, 2011-05-21 at 16:53 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com
wrote:
On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote:
*snip*
Again, this depends upon what your url scheme looks like - and
without
knowing that, there's simple no clue as to whether or not this is a
good solution to the problem (though it might be a good solution to A
problem).
Again, I disagree. If you have an example of a URL structure where
this
would not work I'd love to hear it.
-Stuart
Having to replace several times just in order to figure out the path
to your script is pointless if you know the name of the script (which
you always do - it's __FILE__ ) and you're using a one-to-one
request-to-script scheme. Then just grab the part of the url up to and
including your scriptname.
Well, it would be basename(__FILE__), but that's beside the point. In this
particular case, where the PHP filename is the last part of the URL, that
will indeed work. However, as you have pointed out several times that's
not
always the case and I tend to write generic, defensive code rather than
make
assumptions.
Note I used the word good - doing several str_replace() and other
calls is not what I consider a good solution if there's something
simpler available with as good a result.
Obviously that's your choice to make, but these days I very rarely work on
projects where there is a one-to-one mapping, and even if I did I would
not
rely on that always being the case. I've worked on a number of projects
where the URL structure has been massively changed (a couple from
one-to-one
to controller-based) where it would have taking an excessive amount of
time
to undo that assumption.
Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
future-proof and takes no more effort than the manipulation you are doing
on
__FILE__ to get the same result. Given the choice I'll always go for 10%
extra work now to save 90% extra work later, even if it's only potential
work later.
-Stuart
I'm not sure if anyone had the chance to look over my code suggestion, but
afaict it does the job, although I've only given it very rudimentary
testing. It doesn't require you to know the page the form is on in
advance,
it strips out the correct info from the supplied URL, and is simple enough
that you could even run it all on one line if you didn't mind nested
tertiary conditionals.
If 404 responses show a custom page containing a form that uses your code
then it's still an XSS risk, but other than that it looks safe. However,
based on that single risk (and there may be others) I'd never use it because
you never know when someone will change the server config.
-Stuart
What would the risk on the 404 page be? I must admit, I don't know a huge
amount about XSS attacks, so this one is new to me.
A similar URL to the one in the URL tedd posted (
http://www.mc2design.com/blog/php_self-safe-alternatives).
Something like this...
http://www.server.com/%22%3E%3Cscript%3Ealert('xss attack')%3C/script%3E
That script code will not be seen as PATH_INFO, it will simply be part of
the URL.
-Stuart
Ah, I see, but it shouldn't be too difficult to use some other variable
in the $_SERVER array. Anyway, if you are displaying a form on a 404
error page, you won't want it to post to itself, as where is the
processing going to be done? If you have a system that can process it,
then it should be capable of ensuring the form posts back to a safe
area, such as the home area of the site.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 4:57 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:34, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote: *snip* Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart Having to replace several times just in order to figure out the path to your script is pointless if you know the name of the script (which you always do - it's __FILE__ ) and you're using a one-to-one request-to-script scheme. Then just grab the part of the url up to and including your scriptname. Well, it would be basename(__FILE__), but that's beside the point. In this particular case, where the PHP filename is the last part of the URL, that will indeed work. However, as you have pointed out several times that's not always the case and I tend to write generic, defensive code rather than make assumptions. Not a bad habit. I would personally go with let's either find out or make a decision instead of wasting time on coding for situations that will crop up. Assumptions cost money, and if you haven't discovered that yet then you've either not been in the software development game very long or you've been lucky so far. Hold on to that feeling, cos you can't get it back when it's gone! -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 5:02 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:53 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com
wrote:
On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote:
*snip*
Again, this depends upon what your url scheme looks like - and
without
knowing that, there's simple no clue as to whether or not this is a
good solution to the problem (though it might be a good solution to A
problem).
Again, I disagree. If you have an example of a URL structure where
this
would not work I'd love to hear it.
-Stuart
Having to replace several times just in order to figure out the path
to your script is pointless if you know the name of the script (which
you always do - it's __FILE__ ) and you're using a one-to-one
request-to-script scheme. Then just grab the part of the url up to and
including your scriptname.
Well, it would be basename(__FILE__), but that's beside the point. In this
particular case, where the PHP filename is the last part of the URL, that
will indeed work. However, as you have pointed out several times that's
not
always the case and I tend to write generic, defensive code rather than
make
assumptions.
Note I used the word good - doing several str_replace() and other
calls is not what I consider a good solution if there's something
simpler available with as good a result.
Obviously that's your choice to make, but these days I very rarely work on
projects where there is a one-to-one mapping, and even if I did I would
not
rely on that always being the case. I've worked on a number of projects
where the URL structure has been massively changed (a couple from
one-to-one
to controller-based) where it would have taking an excessive amount of
time
to undo that assumption.
Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
future-proof and takes no more effort than the manipulation you are doing
on
__FILE__ to get the same result. Given the choice I'll always go for 10%
extra work now to save 90% extra work later, even if it's only potential
work later.
-Stuart
I'm not sure if anyone had the chance to look over my code suggestion, but
afaict it does the job, although I've only given it very rudimentary
testing. It doesn't require you to know the page the form is on in
advance,
it strips out the correct info from the supplied URL, and is simple enough
that you could even run it all on one line if you didn't mind nested
tertiary conditionals.
If 404 responses show a custom page containing a form that uses your code
then it's still an XSS risk, but other than that it looks safe. However,
based on that single risk (and there may be others) I'd never use it because
you never know when someone will change the server config.
-Stuart
What would the risk on the 404 page be? I must admit, I don't know a huge
amount about XSS attacks, so this one is new to me.
A similar URL to the one in the URL tedd posted
(http://www.mc2design.com/blog/php_self-safe-alternatives).
Something like this...
http://www.server.com/%22%3E%3Cscript%3Ealert('xss attack')%3C/script%3E
That script code will not be seen as PATH_INFO, it will simply be part of
the URL.
-Stuart
Ah, I see, but it shouldn't be too difficult to use some other variable in
the $_SERVER array. Anyway, if you are displaying a form on a 404 error
page, you won't want it to post to itself, as where is the processing going
to be done? If you have a system that can process it, then it should be
capable of ensuring the form posts back to a safe area, such as the home
area of the site.
Any variable in the $_SERVER array that contains the current URL in some
form will likely suffer from the same issue.
The example I gave there was very simple. Imagine a site with a very dynamic
and complex URL structure and you can imagine a situation where this
vulnerability might crop up.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Re: [PHP] Script ID?
On 21 May 2011 18:05, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 4:57 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:34, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote: *snip* Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart Having to replace several times just in order to figure out the path to your script is pointless if you know the name of the script (which you always do - it's __FILE__ ) and you're using a one-to-one request-to-script scheme. Then just grab the part of the url up to and including your scriptname. Well, it would be basename(__FILE__), but that's beside the point. In this particular case, where the PHP filename is the last part of the URL, that will indeed work. However, as you have pointed out several times that's not always the case and I tend to write generic, defensive code rather than make assumptions. Not a bad habit. I would personally go with let's either find out or make a decision instead of wasting time on coding for situations that will crop up. Assumptions cost money, and if you haven't discovered that yet then you've either not been in the software development game very long or you've been lucky so far. Hold on to that feeling, cos you can't get it back when it's gone! Assumptions and knowledge are two different things. If you haven't discovered that yet then you've either not been in the software development game very long or you've been doing things wrong so far. I suggest spending some time checking up on the difference. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 5:14 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 18:05, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 4:57 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:34, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 4:24 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 17:18, Stuart Dallas stu...@3ft9.com wrote: *snip* Again, this depends upon what your url scheme looks like - and without knowing that, there's simple no clue as to whether or not this is a good solution to the problem (though it might be a good solution to A problem). Again, I disagree. If you have an example of a URL structure where this would not work I'd love to hear it. -Stuart Having to replace several times just in order to figure out the path to your script is pointless if you know the name of the script (which you always do - it's __FILE__ ) and you're using a one-to-one request-to-script scheme. Then just grab the part of the url up to and including your scriptname. Well, it would be basename(__FILE__), but that's beside the point. In this particular case, where the PHP filename is the last part of the URL, that will indeed work. However, as you have pointed out several times that's not always the case and I tend to write generic, defensive code rather than make assumptions. Not a bad habit. I would personally go with let's either find out or make a decision instead of wasting time on coding for situations that will crop up. Assumptions cost money, and if you haven't discovered that yet then you've either not been in the software development game very long or you've been lucky so far. Hold on to that feeling, cos you can't get it back when it's gone! Assumptions and knowledge are two different things. If you haven't discovered that yet then you've either not been in the software development game very long or you've been doing things wrong so far. I suggest spending some time checking up on the difference. You can't know everything, and anything you do know is only true as of right now. You can't control the future and all predictions you make are based on assumptions, and if/when your assumptions turn out to be wrong it will cost money. Trust me on that. http://en.wikipedia.org/wiki/Defensive_programming You do things your way and I'll do things my way. Best of luck to you. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On 21 May 2011 18:26, Stuart Dallas stu...@3ft9.com wrote: *snip* http://en.wikipedia.org/wiki/Defensive_programming You do things your way and I'll do things my way. Best of luck to you. Thank you for your condescending tone. Best of luck to you too. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On 21 May 2011 18:42, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 5:33 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 18:26, Stuart Dallas stu...@3ft9.com wrote: *snip* http://en.wikipedia.org/wiki/Defensive_programming You do things your way and I'll do things my way. Best of luck to you. Thank you for your condescending tone. Best of luck to you too. It is regrettable if you took offence, but I stand by my tone. I've cleaned up too many messes over the years that were caused by careless (and in some cases incompetent) assumptions that I have little time for anyone who doesn't see the value in expecting the unexpected. Yet you assume that I have no experience, have never cleaned up messes after others, and generally have no clue what I'm talking about. At no point did I state that I see no value in expecting the unexpected or that I disagree with defensive programming. What I did state is that I prefer clearing up any unclear areas and remove assumptions - if I end up spending most of my time doing defensive programming because I haven't cleared up the specifications with the client, then I have done a very poor job. Anyway, I doubt there's much point in continuing the conversation - you seem to have a set worldview and it appears that my role in it is the same regardless of what I state from here on out. So: best of luck to you. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 5:33 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 18:26, Stuart Dallas stu...@3ft9.com wrote: *snip* http://en.wikipedia.org/wiki/Defensive_programming You do things your way and I'll do things my way. Best of luck to you. Thank you for your condescending tone. Best of luck to you too. It is regrettable if you took offence, but I stand by my tone. I've cleaned up too many messes over the years that were caused by careless (and in some cases incompetent) assumptions that I have little time for anyone who doesn't see the value in expecting the unexpected. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On May 21, 2011, at 9:11 AM, tedd wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Hi, everyone. I've been following this thread, and as I am not that familiar with XSS attacks, I went searching for information about them. I did find this: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet which may help others like me begin to understand the issue. That said, I really don't understand how using something like $self=basename($_SERVER['SCRIPT_NAME']); becomes vulnerable to an XSS attack. Can someone explain to me how this works? Then I might be able to understand how to prevent it. Thanks. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 6:00 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 18:42, Stuart Dallas stu...@3ft9.com wrote: On Sat, May 21, 2011 at 5:33 PM, Peter Lind peter.e.l...@gmail.com wrote: On 21 May 2011 18:26, Stuart Dallas stu...@3ft9.com wrote: *snip* http://en.wikipedia.org/wiki/Defensive_programming You do things your way and I'll do things my way. Best of luck to you. Thank you for your condescending tone. Best of luck to you too. It is regrettable if you took offence, but I stand by my tone. I've cleaned up too many messes over the years that were caused by careless (and in some cases incompetent) assumptions that I have little time for anyone who doesn't see the value in expecting the unexpected. Yet you assume that I have no experience, have never cleaned up messes after others, and generally have no clue what I'm talking about. At no point did I state that I see no value in expecting the unexpected or that I disagree with defensive programming. What I did state is that I prefer clearing up any unclear areas and remove assumptions - if I end up spending most of my time doing defensive programming because I haven't cleared up the specifications with the client, then I have done a very poor job. Any assumptions I made regarding your level of experience came from this comment.. [I would personally go with let's either find out or make a decision instead of wasting time on coding for situations that will crop up.] Aside from the presumably erroneous use of will instead of may, this suggests to me that you are the type of developer who writes code in the quickest way possible without any concern for its quality or its use beyond your involvement. Maybe I'm wrong, but I can only go by the evidence that's presented. My primary point was that you have not removed assumptions. You may think you have by putting restrictions on the environment in which your code runs, but as I said earlier, the larger a project becomes the less likely it will be that those conditions are going to remain in place. So, those restrictions are essentially assumptions. No piece of software would ever get finished without assumptions being made or various restrictions being in place, but it's always a compromise between cost of mitigation now against the cost of dealing with changes in the future (the 10%/90% I mentioned earlier). On that basis I see huge value in normalising and centralising the generation of URLs for any project that consists of more than a few simple PHP pages. Anyway, I doubt there's much point in continuing the conversation - you seem to have a set worldview and it appears that my role in it is the same regardless of what I state from here on out. Your role in my world is simply that if your responses in this thread reflect how you approach your software development, unless you say or do something that changes my view of that approach I would probably avoid ever working with you, or on any software with which you've been involved. This was fun... we should do it again sometime! ;) -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Script ID?
On Sat, May 21, 2011 at 10:11 AM, tedd t...@sperling.com wrote: Hi gang: Okay, so,what's the best (i.e., most secure) way for your script to identify itself *IF* you plan on using that information later, such as the value in an action attribute in a form? For example, I was using: $self = basename($_SERVER['SCRIPT_NAME']); form name=my_form action=?php echo($self); ? method=post However, that was susceptible to XSS. http://www.mc2design.com/blog/php_self-safe-alternatives says a simple action=# would work. But is there a better way? What would do you do solve this? Cheers, tedd Tedd, I'm sorry for the confusion. When I referenced that article, I was speaking to Alex as to why it wouldn't be prudent for you to use PHP_SELF (as he had suggested to avoid an additional function call) as opposed to what you were currently using, basename($_SERVER['SCRIPT_FILENAME']). My point, and the point of the article, was that PHP_SELF requires special precautions. However, script_filename is not susceptible to this type of attack, as it does not include data from the user: http://php.about.com/od/learnphp/qt/_SERVER_PHP.htm In fact, basename($_SERVER['SCRIPT_FILENAME']), and basename(__FILE__) were two of the mitigation methods mentioned in the closing of the article. http://php.about.com/od/learnphp/qt/_SERVER_PHP.htmTry it out on your server: h1PHP_SELF (dangerous)/h1 p?php echo $_SERVER['PHP_SELF']; ?/p h1$_SERVER['SCRIPT_FILENAME']/h1 p?php echo $_SERVER['SCRIPT_FILENAME']; ?/p h1$_SERVER['REQUEST_URI'] (dangerous)/h1 p?php echo $_SERVER['REQUEST_URI']; ?/p h1__FILE__/h1 p?php echo __FILE__; ?/p h1basename(__FILE__)/h1 p?php echo basename(__FILE__); ?/p h1basename($_SERVER['SCRIPT_NAME'])/h1 p?php echo basename($_SERVER['SCRIPT_NAME']); ?/p Try to enter the attack vector and you'll see PHP_SELF could be terrible, but the basename option for script_filename and __FILE__ are immune. Again, sorry for the confusion. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] Script ID?
At 6:29 PM +0100 5/21/11, Stuart Dallas wrote: On Sat, May 21, 2011 at 6:00 PM, Peter Lind mailto:peter.e.l...@gmail.competer.e.l...@gmail.com wrote: -snip- This was fun... we should do it again sometime! ;) No, this wasn't fun. As I said before, is email is a bad way to communicate. But I think we are better than the medium. What say you guys? xxxoooxxx Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
