Bug #77074 [Opn]: XSS through error messages

From: Date: Sat, 27 Oct 2018 21:47:07 +0000
Subject: Bug #77074 [Opn]: XSS through error messages
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-217726@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77074&edit=1 ID: 77074 Updated by: nikic@php.net Reported by: david at grudl dot com Summary: XSS through error messages Status: Open Type: Bug Package: Output Control PHP Version: 7.1 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2018-10-27 21:43:41] 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 ${'<script>alert(123);</script>'}; then I should see those "lt"s and "gt"s in the error message ("&lt/gt;" in the output) because that's what the variable was actually named. ------------------------------------------------------------------------ [2018-10-27 21:21:49] 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 20:12:15] 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 20:02:29] 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 19:56:14] 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 ------------------------------------------------------------------------ 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=77074 -- Edit this bug report at https://bugs.php.net/bug.php?id=77074&edit=1

« previous php.bugs (#217726) next »