On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote: > > On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan > <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > > > 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.lind@xxxxxxxxx> wrote: > > > > > On 21 May 2011 17:18, Stuart Dallas <stuart@xxxxxxxx> 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/
