Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33612
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <47548638.9020709@lerdorf.com>
Date: Mon, 03 Dec 2007 14:42:00 -0800
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Sara Golemon <pollita@php.net>, PHP Internals <internals@lists.php.net>
References: <474F0EE7.8020201@php.net> <474F4E47.8050506@zend.com> <474F5E12.1050404@php.net> <474F5F75.3030808@zend.com> <475081DD.90404@php.net> <4750B3CA.20405@zend.com> <475101FF.5080103@lerdorf.com> <475482AF.3050800@zend.com>
In-Reply-To: <475482AF.3050800@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposed feature for json_encode()
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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