php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77074 XSS through error messages
Submitted: 2018-10-27 19:08 UTC Modified: 2018-10-27 21:47 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: david at grudl dot com Assigned:
Status: Open Package: Output Control
PHP Version: 7.1 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2018-10-27 19:08 UTC] david at grudl dot com
Description:
------------
Displaying error messages is vulnerable to XSS, although the 'html_errors' is enabled.

Solution is to convert especial charactes < & in error message (ie to use  htmlspecialchars)

Test script:
---------------
<?php

echo ${'<script>alert(123);</script>'};

Expected result:
----------------
In web browser it should not pop up the alert window, but it should report:

"Notice: Undefined variable: <script>alert(123);</script> in test.php on line 3


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-10-27 19:15 UTC] requinix@php.net
-Summary: david@grudl.com +Summary: XSS through error messages
 [2018-10-27 19:20 UTC] nikic@php.net
We're definitely applying htmlspecialchars to errors in html_errors mode. Can you please double check that it is really enabled (e.g. by printing the html_errors ini setting in the same script you are testing the error message)?
 [2018-10-27 19:30 UTC] requinix@php.net
The escaping only happens for E_ERROR and E_PARSE.
https://github.com/php/php-src/blob/php-7.3.0RC4/main/main.c#L1336
 [2018-10-27 19:31 UTC] david at grudl dot com
-Summary: XSS through error messages +Summary: david@grudl.com -PHP Version: 7.3.0RC4 +PHP Version: 5.6.5
 [2018-10-27 19:31 UTC] david at grudl dot com
Yes, html_errors is enabled.

(Sorry for wrong description, autofilling in browser surprised me ;-)
 [2018-10-27 19:35 UTC] requinix@php.net
-Summary: david@grudl.com +Summary: XSS through error messages -PHP Version: 5.6.5 +PHP Version: 7.1
 [2018-10-27 19:56 UTC] spam2 at rhsoft dot net
> The escaping only happens for E_ERROR and E_PARSE

why?

also in cli-mode escape sequences should be filtered, we implemented a lot of sanitze stuff because we don't trust PHP in that context but different behavior depending on the error type is a no-go and explains some headache from the past
 [2018-10-27 20:02 UTC] requinix@php.net
> why?
I don't know. I'm not giving an explanation, just stating the current behavior.

The change to give E_ERROR (E_PARSE was added later) special treatment dates back to 5.1.2.
https://github.com/php/php-src/commit/2796160d15463a04acd7088fea379593d2c9caa0
 [2018-10-27 20:12 UTC] nikic@php.net
@requinix: The code I was looking at is https://github.com/php/php-src/blob/php-7.3.0RC4/main/main.c#L945, which always escapes -- but now I realize that php_verror is only going to be used for docref type errors, not for "raw" errors.

Possibly this is also why it special cases ERROR and PARSE, to avoid double escaping.
 [2018-10-27 21:21 UTC] spam2 at rhsoft dot net
> Possibly this is also why it special cases ERROR and PARSE, to avoid double escaping

wouldn't it be smarter to act like http://php.net/manual/de/function.htmlentities.php  and have bool $double_encode=TRUE in that case using FALSE instead special handeling for the sake of consistency?
 [2018-10-27 21:43 UTC] requinix@php.net
It should always encode because then that will always show the original value. If OP's already bizarre situation was even worse, like
  echo ${'&lt;script&gt;alert(123);&lt;/script&gt;'};
then I should see those "lt"s and "gt"s in the error message ("&amp;lt/gt;" in the output) because that's what the variable was actually named.
 [2018-10-27 21:47 UTC] nikic@php.net
An additional issue here is that docref also inserts markup for the documentation links, and we of course wouldn't want to escape that part.
 [2018-10-27 22:21 UTC] spam2 at rhsoft dot net
> An additional issue here is that docref also 
> inserts markup for the documentation links,
> and we of course wouldn't want to escape that part.

is a cry for refactoring - do you tell me you can't distinct between that and escaping happens at the of everything independent from where it came and what it was?
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Tue Dec 11 22:01:26 2018 UTC