Re: Proposed feature for json_encode()

Is such filtering specific to JSON? Does it have some use out of JSON-context? Maybe it would be better to provide a set of functions for encoding characters into '\u'-entities? (similiar to htmlentities, htmlspecialchars) because if we speak of 'theoretical' problem, we might end reimplementing this for some other function later On 12/1/07, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > Stanislav Malyshev wrote: > >> I can't because I don't know of any successful vectors *currently*. I > >> also would have sworn that echoing htmlentified data was safe....until > >> I came across a browser where it wasn't. > > > > So that's what I wanted to understand, because if we add this feature, > > we should give some explanation on when to use it and what it does, and > > I don't think I understand that, so I guess it would help to have such > > explanation. > > Stuff like this often isn't completely deterministic. The attack > vectors will move around and new ones will be discovered but since the > syntax Sara is proposing is completely valid JSON it gives people > another tool. Documenting specific attack vectors is useful too, of > course, but a secondary concern in my mind. > > I don't think we have ever documented some of the vectors against > htmlentities(), for example. Even with the latest character encoding > fixes, there are still contextual attack vectors where doing > htmlentities() on user data doesn't help you at all. For the curious, > try this: > > <?php $foo = htmlspecialchars($_GET['foo'], ENT_QUOTES);?> > <a href="" onmouseover="a='<?php echo $foo?>';">Mouse > Over Me</a> > > Then try hitting the page and set ?foo=';alert(0);// > > This doesn't mean there is anything wrong with htmlentities(), of > course, it simply means it was used in the wrong context and another > mechanism is needed here. > > I don't think it is hard to imagine that there are times when it would > be nice to be able to move JSON data around in a context in which html > tags and quotes might be inconvenient. Instead of applying a filter on > top of it, having a version of json that doesn't have these is quite useful. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/