php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Sec Bug #55139 Cross-site scripting via user input in PHP notices
Submitted: 2011-07-05 15:28 UTC Modified: 2011-08-18 18:33 UTC
From: nbpoole@php.net Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 5.2.17 OS: All
Private report: No CVE-ID: None
View Developer Edit
 [2011-07-05 15:28 UTC] nbpoole@php.net 
Description:
------------
The "undefined index" notice generated by PHP does not properly sanitize the name 
of the index when it is displayed to the user. As a result, it is possible to 
mount a cross-site scripting attack using the notice under a limited set of 
circumstances. Specifically:

1. error_reporting includes E_NOTICE
2. display_errors is enabled
3. The user has some control over the name of the index.

I have confirmed this issue on 5.2.17 and 5.4SVN-2011-07-05 (snap).

Test script:
---------------
This script generates an "undefined index" notice where the index is derived from user input. I put a copy at http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254.php:

<?php
error_reporting(E_ALL);
$array = array();
echo $array[$_GET['index']];

This script generates a "Call to undefined function" error where the function name is derived from user input. I put a copy at http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254-2.php:

<?php
error_reporting(E_ALL);
echo $_GET['funct']();

Expected result:
----------------
http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254.php?
index=%3Cscript%3Ealert(1)%3C/script%3E

should return

Notice: Undefined index: <script>alert(1)</script> in 
/home/smartys/nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254.php on line 4

---

http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254-2.php?
funct=%3Cscript%3Ealert%281%29%3C/script%3E

should return

Fatal error: Call to undefined function <script>alert(1)</script>() in 
/home/smartys/nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254-2.php on line 4


Actual result:
--------------
http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254.php?
index=%3Cscript%3Ealert(1)%3C/script%3E does not escape the index name, allowing 
for XSS. 

http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254-2.php?
funct=%3Cscript%3Ealert%281%29%3C/script%3E properly escapes the function name.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-07-05 15:33 UTC] stas@php.net 
2. display_errors is enabled

which means you renounce any claims of running secure server.
 [2011-07-05 16:19 UTC] nbpoole@php.net 
Found a couple more examples:

---

http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254-3.php?
var=%3Cscript%3Ealert(1)%3C/script%3E

Code is

<?php
error_reporting(E_ALL);
echo $$_GET['var'];

---

http://nealpoole.com/poc/147b9119e818c92f7f74bad71cc12254-4.php?
cons=%3Cscript%3Ealert(1)%3C/script%3E

Code is:

<?php
error_reporting(E_ALL);
define($_GET['cons'], 'a');
define($_GET['cons'], 'a');
 [2011-07-05 16:20 UTC] nbpoole@php.net
-Summary: Cross-site scripting via "Undefined index" notice +Summary: Cross-site scripting via user input in PHP notices
 [2011-07-05 16:20 UTC] nbpoole@php.net 
Updating the summary to better reflect the issue at hand.
 [2011-07-19 11:20 UTC] nbpoole@php.net 
This coding pattern is present in the latest version of Wordpress. Assuming 
error_reporting includes E_NOTICE and display_errors is enabled, the following URL 
results in a reflected XSS vulnerability:

http://example.com/wordpress/wp-admin/upload.php?
message=1%3Cscript%3Ealert(1)%3C/script%3E

I will be contacting the Wordpress developers regarding this issue.
 [2011-08-17 19:20 UTC] nbpoole@php.net 
I'm planning to write about this issue publicly at the end of next week (August 
26th). Please let me know if there are any objections to that.
 [2011-08-17 19:43 UTC] pajoye@php.net
-Status: Open +Status: Bogus
 [2011-08-17 19:43 UTC] pajoye@php.net 
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

How is it remotely related to php.net?

Please report these issues to both wordpress and the webmaster of the respective 
sites.
 [2011-08-18 18:21 UTC] dtajchreber@php.net 
Disregarding the whole argument whether this is really a security issue or bad 
configuration... with html_errors set to on, shouldn't PHP convert special symbols 
that aren't part of the intended formatting into entities? It seems like this is 
at least a bug...

http://codepad.viper-7.com/AV0b0B.php53?index=%3Ch1%3Ehi%3C/h1%3E
 [2013-04-06 01:16 UTC] ajf at ajf dot me 
Indeed, echoing dtajchreber@php.net, this is clearly a real bug. It means that 
index values will not always be displayed properly in debug output. It is likely 
people might have index values which have characters like < and > in them, which 
would not display properly as a consequence.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 12:01:29 2024 UTC