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

go to bug id or search bugs for

Bug #18727 XSS in I/O Function Output
Submitted: 2002-08-03 15:40 UTC Modified: 2002-08-03 16:30 UTC
From: mattmurphy at kc dot rr dot com Assigned:
Status: Not a bug Package: Output Control
PHP Version: 4.2.2 OS: Win32
Private report: No CVE-ID: None
View Developer Edit
 [2002-08-03 15:40 UTC] mattmurphy at kc dot rr dot com 
This applies to any PHP script that opens files based on some kind of user-input inserted into the file name.  If the file open fails, PHP returns a warning.  In that warning is the file name that was input.  If the user-input were to contain a specially crafted piece of data, arbitrary code could be executed:

<?php
$handle = fopen("C:\\INETPUB\\WWWROOT\\" . $_GET["resource"], "rb");
?>

http://localhost/fopen.php?resource={SCRIPT}alert('xss'){/SCRIPT}

Replace "{" with "<" and "}" with ">" and you are ready to go.  When you hit the enter key, the browser urlencodes the malicious string, and PHP attempts to open the file, resulting in the vulnerability.  

Solution
fopen() should *not* return the file name in raw form to the browser.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-03 16:00 UTC] sander@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
 [2002-08-03 16:11 UTC] mattmurphy at kc dot rr dot com 
Once again, I'm astounded by the overwhelmingly negative message that the PHP Group sends users of PHP sites -- thanks to us, somebody can steal your personal information!  Oh, and, thanks for your business.

That is at least counter-productive, yes?
 [2002-08-03 16:17 UTC] cynic@php.net 
it's the programmer's responsibility to prevent such attacks.
i for one surely wouldn't want php muck with the error output while
writing some quick scripts. in larger applications, you need custom error
handler and/or display_errors = off anyway.

so what's the deal?
 [2002-08-03 16:22 UTC] mattmurphy at kc dot rr dot com 
Now, you tell me how a programmer could prevent this attack.  If he HTML-encoded his file name before using it, it would screw up his script's function.  The problem is *not* in the script, but in PHP's fopen() function.

A simple HTML encode (e.g, instead of "<SCRIPT>", "&lt;SCRIPT&gt;") would do the job of avoiding the bug, AND would not change the appearence of the output.  The current situation is at best unsafe.
 [2002-08-03 16:23 UTC] mattmurphy at kc dot rr dot com 
Didn't change the status... :-)
 [2002-08-03 16:27 UTC] msopacua at idg dot nl 
So, this 'security issue' occurs when:
1) Errors are spit to the browser instead of a log, like it is, before you put it in production, right?
2) fopen is called, on a non-existing file (see: file_exists), directly accepting user input - ahum.


Additionally - the 'vulnerability' has got nothing to do with PHP, but everything with browsers and JavaScript.
 [2002-08-03 16:28 UTC] eru@php.net 
You could prevent this attack by verifying the input with file_exists or something similar. You should always parse userinput through some sanity-check, before you process it, and this is within the responsibility of the programmer, not of PHP.
 [2002-08-03 16:29 UTC] cynic@php.net 
i said "custom error handler and/or display_errors = off"

please, leave this pr in the bogus state.
 [2002-08-03 16:30 UTC] cynic@php.net 
yup. the fact that php doesn't hold programmers by the hand doesn't necessarily mean it's broken.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 05:01:30 2024 UTC