Stanislav Malyshev wrote: >> 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'm not talking about attack vectors and full security analysis. For me, > it is a primary concern having some security oriented feature to know > *what exactly* it does and when you should and should not use it. We > were burned repeatedly by implementing various cool features that were > misused for doing things that they weren't meant to do and then we were > blamed for it - so I think we need to have clear understanding of when > and why this feature is useful and explicitly document it. Otherwise > what would happen is that people would use this option, pass JS data > through it, stick it into DOM, get XSS and start blogging about "huge > XSS in supposedly secure json_encode() function in PHP". > Or, not seeing how it can help them, won't use it at all.
This is just a different way of encoding Javascript which depending on the context of use will enable Javascript to be embedded securely. Not providing an alternate encoding is a bit like arguing that we shouldn't have base64_encode() because if used incorrectly it could be insecure. We don't have an explanation of when base64_encode() is useful in the docs, although I suppose we could come up with some scenarios for when you want to squeeze arbitrary data into the set of characters base64_encode() uses. Same thing for this json_encode() feature. We can come up with a set of scenarios where we would like to avoid having characters that are meaningful in XML and HTML show up in our json strings. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
