Re: url encoding

On 2/5/06, bertrand Gugger <[email protected]> wrote:
> Bonjour,
> As we develop further the Mediawiki parser, I got stuck by some URLs
> built up from wiki pages names. Mediawiki accepts spaces (and certainly
> more other special chars) in pages names.
> But the Xhtml render only htmlspecialchar() them what means will let
> spaces untouched, which is not correct in an URL.
>
> That concerns Interwiki, Wikilink and Phplookup rules.
>
> As a quick workaround, I changed the htmlspecialchar() into urlencode().
> That corrects this bad behavior, however I'm very unsure about this
> change, why I request your check about it:
> * does urlencode() give the same protection against XSS and so ?
>   Should we use some combination of both urlencode and htmspecialchar() ?
> * it is theoretically possible to use (at least) the Interwiki facility
> to link to not only wiki pages but more generally subdirectories + query
> parameters from external pre-configured sites. I wonder if some users do
> it. In this case, the urlencode() would destroy the url.
>   Should I make this behavior optional/configurable ?
>

Yes, this is true. Remember that urlencoding is not for the entire
URL. It's for pieces of data which needs to be passed through a URL
without altering it. An example would be putting '&' in GET data. &
has special meaning in a URL so it has to be escaped (urlencoded).
Page names could have special chars but they should never be allowed
to change the semantics of the URL. If people are using them that way
then they're using XSS to hack around a problem. Data in URLs (URIs)
should always be urlencoded.

> It appears that urlencode() makes '+' from spaces, which is not
> compliant. Is it better to use rawurlencode() instead ? (it makes right
> %20 of them)
> Moreover, these functions will also encode the national characters (non
> ascii), is it always desirable ?

How is + not compliant? IIRC + is normal for spaces in URLs. However,
using rawurlencode is fine too. I have no problem with that.

>
> A propos Xhtml compliance, we eventually also have the question of the &
> in query part, full xml compliance would require them to be &amp;  (w3c
> recommends ';' only, but not all browsers know it) ...
>

Yes, htmlspecialchars or htmlentities always needs to be run on text
before it goes into output. This is always the last transformation,
after such things as urlencode or rawurlencode. So the data in the
URLs needs to be urlencoded (all data, but not the entire URL), then
the entire URL needs to have htmlentities run on it (with quotes also
encoded) before it is put in an attribute in a tag.

> Finally, I believe the Text_Wiki_Render  abstract class should furnish
> some own url encoding method, user configurable and over writable by
> each renderer,
> the same as we need (for text) to generalize the text encoding user
> choice between htmlentities, htmlspecialchar or none in the Xhtml
> renderer. ( http://pear.php.net/bugs/bug.php?id=3D5953 )
> For example, the Docbook renderer will require some cleanup case ISO
> encoding is asked ... which will be different from the Xhtml one, certain=
ly.
> That means having 2 methods urlencode() and textencode() in these render
> classes, what will be used instead of the raw php calls urlencode() and
> htmspecialchar()/htmlentities().
>
> Ah ah, again some "unsorted" romance :)
> =E0+
> --
> toggg
>


--
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php