Re: Script ID?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux