Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALJZF3iFW95tw7JDk+G_-2FbgY6gTpUTWQvVy87EdtOmA7t0iA@mail.gmail.com>
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
	<CAF+90c--kSrsWAPr_p8J7KV=TsStSL4NL1GCKRDeyycdZxDWyg@mail.gmail.com>
	<CALJZF3iFW95tw7JDk+G_-2FbgY6gTpUTWQvVy87EdtOmA7t0iA@mail.gmail.com>
Date: Wed, 2 Oct 2013 20:40:12 +0200
Message-ID: <CAF+90c98XmsGjPHjGx9=4SNFoFgp98JFfRZTXDUx1bo62dzd_g@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11336ce24c8c9b04e7c66600
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing
 PUT data)
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11336ce24c8c9b04e7c66600
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 2, 2013 at 8:02 PM, Michael Wallner <mike@php.net> wrote:

> >> There are already parsers for application/x-www-form-urlencoded and
> >> multipart/form-data in the core.  One could think of providing an API
> >> to add content type handlers from extensions, ext/json may be an
> >> example, like it is hacked into pecl_http-v2.
> >
> >
> > I would *strongly* recommend against adding additional body parsers that
> are
> > automatically invoked based on the content type. Adding additional
> parsers
> > creates a high security risk. E.g. exposing ext/json as it is now would
> open
> > you to a denial of service attack (if I'm not mistaken). There has been a
> > long history of security vulnerabilities (both DOS and RCE) related to
> > unnecessary or incorrect exposure of request body parsers. A prominent
> > recent example are the RCE vulnerabilities in Rails caused by the
> exposure
> > of YAML and JSON parsers.
>
> Pointers, references, evidences?
>

The Rails RCE (remote code execution) vulnerability I'm referring to is
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ,
which is caused by exposing YAML and XML parsers. There have been several
subsequent vulnerabilities in this area, e.g.
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/1h2DR63ViGo,
which involves exposing a JSON parser that happened to operate on YAML
internally. You'll find that similar vulns turned up in various
webframeworks over time (one other case I remember off the top of my head
is a parameter parsing vulnerability in Apache Struts2 related to OGNL).

The DOS vulnerability that would turn up by directly exposing json_decode
as a body parser is the standard HashDOS vulnerability (which exploits
collisions in the array key hashing functions).

Even without exposing additional parser PHP already had its share of
vulnerabilities in this area (e.g. HashDOS and the subsequent RCE that its
fix caused).

I'm not saying that adding additional parsers is bad *per se*, I'm just
saying that you need to be very careful what you add here. The more
automatic body parsers you have the larger the attack surface becomes.

Nikita

--001a11336ce24c8c9b04e7c66600--