On Sat, May 21, 2011 at 4:07 PM, Peter Lind <peter.e.lind@xxxxxxxxx> wrote: > On 21 May 2011 17:01, Stuart Dallas <stuart@xxxxxxxx> wrote: > > On Sat, May 21, 2011 at 3:35 PM, Peter Lind <peter.e.lind@xxxxxxxxx> > wrote: > >> > >> On 21 May 2011 16:18, Stuart Dallas <stuart@xxxxxxxx> wrote: > >> > On Sat, May 21, 2011 at 3:11 PM, tedd <tedd@xxxxxxxxxxxx> 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/
