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. 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/
