Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33760
Return-Path: <pollita@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 35876 invoked by uid 1010); 5 Dec 2007 18:57:27 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 35861 invoked from network); 5 Dec 2007 18:57:26 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 5 Dec 2007 18:57:26 -0000
Authentication-Results: pb1.pair.com header.from=pollita@php.net; sender-id=pass; domainkeys=good
Authentication-Results: pb1.pair.com smtp.mail=pollita@php.net; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain php.net designates 140.211.166.39 as permitted sender)
DomainKey-Status: good
X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01
X-PHP-List-Original-Sender: pollita@php.net
X-Host-Fingerprint: 140.211.166.39 osu1.php.net Linux 2.4/2.6
Received: from [140.211.166.39] ([140.211.166.39:52717] helo=osu1.php.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 07/4F-20707-694F6574 for <internals@lists.php.net>; Wed, 05 Dec 2007 13:57:26 -0500
DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;
	s=mx; d=php.net;
	h=From:Subject:To:Date;
	b=RgB7EMJecRbu9dOPJefW7txUtlXOfXYvtGrxf94h3Y6XFR+WwlXUkPrg35FksgOp
	lj3IAOqbNOG2S3VYvrEaOSzh7KAmzJ/xPj+oIIHidbR02U3AIXT6vxnowiPtE/UV
Authentication-Results: osu1.php.net smtp.mail=pollita@php.net; spf=neutral; sender-id=neutral
Authentication-Results: osu1.php.net header.from=pollita@php.net; sender-id=neutral
Authentication-Results:  osu1.php.net smtp.user=pollita; auth=pass (LOGIN)
Received: from [216.145.49.15] ([216.145.49.15:63762] helo=[10.72.77.10])
	by osu1.php.net (envelope-from <pollita@php.net>)
	(ecelerity 2.2.1.23 r(20596)) with ESMTPSA (cipher=none) 
	id F4/70-19809-DA4F6574; Wed, 05 Dec 2007 10:57:50 -0800
Message-ID: <4756F48B.2070609@php.net>
Date: Wed, 05 Dec 2007 10:57:15 -0800
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, Keryx Web <webmaster@keryx.se>, 
	PHP Developers Mailing List <internals@lists.php.net>
References: <474F0EE7.8020201@php.net> <474F5F75.3030808@zend.com>	 <475081DD.90404@php.net> <4750B3CA.20405@zend.com>	 <475101FF.5080103@lerdorf.com> <475482AF.3050800@zend.com>	 <47548638.9020709@lerdorf.com> <475487D0.7050207@zend.com>	 <47549512.1000505@akbkhome.com> <4754DEA0.10105@php.net> <cd5680a20712040116o931d03exdb818ea49d2fd95c@mail.gmail.com> <47569091.3020704@keryx.se> <475692A5.7020600@lerdorf.com> <4756EC08.8040806@zend.com>
In-Reply-To: <4756EC08.8040806@zend.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposed feature for json_encode()
From: pollita@php.net (Sara Golemon)

>> payload to innerHTML, you are hosed.  Using the \u syntax, even if you
>> mess up and that blob of data finds its way to an innerHTML, nothing
>> nasty can happen.  Basically this is a more robust context-protected way
> 
> I'm not sure this is correct - if you just write something like:
> 
> <script>
> var = <?php json_encode($_GET['pleasehackme']) ?>;
> myDomElement.innerHTML = var.content;
> </script>
> 
> you are still in trouble, \u or not. Am I wrong?

You are correct.  But there are two traps here.  One is the example 
above.  Just a bad programmer not taking basic steps to secure data 
being dropped into a full HTML context.  Nothing PHP can do can protect 
the application developer from that.

The second is the one I'm trying to address, wherein data that belongs 
in a JS parsing context may (coincidentally) contain HTML parsable data. 
  For *whatever* reason, this data may accidently be echoed outside of a 
JS context, or a parsing/rendering error may lead to the browser 
switching unexpectedly to an HTML context.  By outputting \u00XX instead 
of <>&', the data remains valid (and syntacticly unmodified) for JS 
parsing, but becomes impotent against exploitability in an HTML context.

It's a good potential win, with the only loss being an increase in 
payload for those otherwise benign characters.  Personally, I'd like to 
make this the default behavior, but given the payload increase I'm 
offering a compromise of using an option to enable this behavior only 
when the user asks for it, thus preserving BC.

-Sara