#18727 [Opn->Bgs]: XSS in I/O Function Output
| From: | eru@php.net | Date: | Sat, 03 Aug 2002 20:28:56 +0000 |
| Subject: | #18727 [Opn->Bgs]: XSS in I/O Function Output | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-15940@lists.php.net to get a copy of this message | ||
ID: 18727
Updated by: eru@php.net
Reported By: mattmurphy@kc.rr.com
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Win32
PHP Version: 4.2.2
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2002-08-03 16:27:27] msopacua@idg.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:23:31] mattmurphy@kc.rr.com
Didn't change the status... :-)
------------------------------------------------------------------------
[2002-08-03 16:22:36] mattmurphy@kc.rr.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>",
"<SCRIPT>")
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:17:19] 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:11:01] mattmurphy@kc.rr.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?
------------------------------------------------------------------------
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
http://bugs.php.net/18727
--
Edit this bug report at http://bugs.php.net/?id=18727&edit=1