On Sat, May 21, 2011 at 5:02 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > On Sat, 2011-05-21 at 16:53 +0100, Stuart Dallas wrote: > > 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 > > > > 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/
