Bug #46439 [Opn]: file upload implementation is flawed
Edit report at https://bugs.php.net/bug.php?id=46439&edit=1
ID: 46439
Updated by: stas@php.net
Reported by: tom at punkave dot com
Summary: file upload implementation is flawed
Status: Open
Type: Bug
Package: cURL related
Operating System: *
PHP Version: 5.*, 6CVS (2009-01-21)
Block user comment: N
Private report: N
New Comment:
See https://wiki.php.net/rfc/curl-file-upload for
fix proposal & implementation.
Previous Comments:
------------------------------------------------------------------------
[2012-08-11 10:13:44] kristo at waher dot net
What if you are not actually trying to send a file and it's instead a POST value
that starts with an @? What if you take user values from a website form and
submit these values with post to another service and user writes '@config.php'
to one of the form values? Problem here is that cURL in PHP treats the POST
array the exact same way, any value could be a link to a file, which creates a
huge loophole or a lot of extra work for you to filter through all POST values
to make sure they are not pointers to files when used with cURL.
In fact, it is not possible to even make a POST request at the moment with cURL
if one of the POST values starts with an @. There's no regular expression check,
no formatting you'd have to follow, just a single (very common) character. What
if you want to send Twitter handle and user writes @kristovaher?
In fact, it is so bad that you cannot even escape the character with \@, cURL
will submit it without unescaping it. And if you don't have any control about
the API on the other side (that would unescape it themselves), cannot make that
POST request! You cannot make a POST API request to Twitter that is a reply to
another user, for example.
I just wish PHP developers had the foresight to implement something like
CURLOPT_FILEFIELDS in cURL, it's insane amount of double-validation I have to do
in my API - that doesn't upload any files - at the moment just because of this
potential security loophole. I love PHP, but these implementations are sometimes
such a headache.
------------------------------------------------------------------------
[2012-01-17 21:40:50] gmblar+php at gmail dot com
There is no function to escape the "@" in the CURLOPT_POSTFIELDS array and in this example
its not possible to remove or replace the "@".
$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL => 'http://www.example.com/',
CURLOPT_RETURNTRANSFER => true,
CURLOPT_POSTFIELDS => array(
'username' => 'foobar',
// Users may have strange passwords. Should be transfered as text.
'password' => '@/etc/hosts',
// Upload image.
'picture' => '@/var/www/avatars/foobar.jpg'
)
));
curl_exec($curl);
curl_close($curl);
My suggestion is to escape the password in this escape with \@ and then thread as text.
------------------------------------------------------------------------
[2009-05-03 21:04:44] pajoye@php.net
tbd
------------------------------------------------------------------------
[2009-01-21 20:08:07] tom at punkave dot com
htmlencode() won't escape @. Neither will htmlentities(). it's a security bug that no
amount of reasonable prudence on the part of programmers who haven't read this particular bug
report will address. And there is no reason why programmers would expect that filtering input would
be necessary when they are passing individual fields to a function that ought to be ready to escape
them (and in fact does, apart from the leading @ thing).
The documentation needs to be fixed at a minimum. It would be a much better idea to get rid of the
broken behavior. The @ prefix is a bad idea (what if I want to pass @?) and with the current lack of
documentation it's a security hole.
This needs to be patched or at least documented.
------------------------------------------------------------------------
[2009-01-21 19:56:56] jani@php.net
It's security hole only if you don't filter the input..
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=46439
--
Edit this bug report at https://bugs.php.net/bug.php?id=46439&edit=1
Thread (8 messages)