php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #52860 htmlspecialchars/htmlentities stripping invalid characters
Submitted: 2010-09-16 13:57 UTC Modified: 2010-10-24 17:22 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:0 of 0 (0.0%)
From: cataphract@php.net Assigned: cataphract (profile)
Status: Closed Package: *General Issues
PHP Version: trunk-SVN-2010-09-16 (SVN) OS: Irrelevant
Private report: No CVE-ID: None
 [2010-09-16 13:57 UTC] cataphract@php.net
Description:
------------
htmlspecialchars() and htmlentities() are commonly used to convert user-supplied text into text that's safe to output in an HTML or XML document.

Actually, they are insufficient for this purpose, because characters that are invalid in XML or XHTML are not stripped out.

In HTML, this results in an invalid document.

In XML, the result is worse because one will end-up with malformed XML. Therefore, sanitation with htmlspecialchars can result in corrupted data.

Additionaly, when passed $double_encode == true, invalid character entities (i.e. those which refer to invalid characters) should also be stripped out.

See
* http://www.w3.org/TR/REC-xml/#NT-Char
* http://www.w3.org/TR/REC-xml/#NT-CharRef

Test script:
---------------
<?php
$mode = @$_GET["mode"];
if ($mode == "xhtml") {
header("Content-type: application/xhtml+xml; charset=utf-8");
$templ = <<<XML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Test</title>
<meta http-equiv="Content-type" content="application/xhtml+xml; charset=utf-8" />
</head>
<body>
%s
</body>
</html>
XML;
}
elseif ($mode == "html") {
header("Content-type: text/html; charset=utf-8");
$templ = <<<HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Test</title>
</head>
<body>
%s
</body>
</html>
HTML;
}
else die("bad mode");

$data = "My data: <\x1F";

echo sprintf($templ, htmlentities($data, ENT_NOQUOTES, "UTF-8"));

Expected result:
----------------
At minimum, this should be documented in the manual pages for htmlspecialchars and htmlentities.

A better solution would be to change those two functions to strip characters outside the allowed range:

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

Another alternative, which wouldn't break BC, would be to add another function or another flag to htmlentities/htmlspecialchars (in addition to ENT_NOQUOTES/ENT_QUOTES/ENT_COMPAT) that would strip out these characters, possible plus those that authors are "encouraged to avoid":

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],
[#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF],
[#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF],
[#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF],
[#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF],
[#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF],
[#x10FFFE-#x10FFFF].



Actual result:
--------------
The W3C validator gives an error:

You have used an illegal character in your text. HTML uses the standard UNICODE Consortium character repertoire, and it leaves undefined (among others) 65 character codes (0 to 31 inclusive and 127 to 159 inclusive) that are sometimes used for typographical quote marks and similar in proprietary character sets. The validator has found one of these undefined characters in your document. The character may appear on your browser as a curly quote, or a trademark symbol, or some other fancy glyph; on a different computer, however, it will likely appear as a completely different character, or nothing at all.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-16 16:45 UTC] cataphract@php.net
Where it says "invalid in XML or XHTML are not stripped out" it should read "invalid in XML or HTML are not stripped out". The characters are also invalid in HTML.
 [2010-09-18 16:54 UTC] cataphract@php.net
HTML5 follows the same direction:

8.1.4 Character references
[...]
The numeric character reference forms described above are allowed to reference any Unicode code point other than U+0000, U+000D, permanently undefined Unicode characters (noncharacters), and control characters other than space characters.

8.2.2.3 Preprocessing the input stream
[...]
All U+0000 NULL characters and code points in the range U+D800 to U+DFFF in the input must be replaced by U+FFFD REPLACEMENT CHARACTERs. Any occurrences of such characters and code points are parse errors.

Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters).
 [2010-09-30 14:23 UTC] cataphract@php.net
The SGML declaration for HTML 4.01 allows a bigger charset than that of HTML 4:

http://www.w3.org/TR/1999/PR-html40-19990824/sgml/sgmldecl.html
 [2010-10-24 17:01 UTC] cataphract@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304705
Log: - Completed rewrite of html.c. Except for determine_charset, almost nothing
  remains.
- Fixed bug on determine_charset that was preventing correct detection in
  combination with internal mbstring encoding &quot;none&quot;, &quot;pass&quot; or &quot;auto&quot;.
- Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0
  and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and
  ENT_HTML5.
- htmlentities()/htmlspecialchars(), when told not to double encode, verify
  the correctness of the existenting entities more thoroughly.
  It is checked whether the numerical entity represents a valid unicode code
  point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED,
  it is also checked whether that numerical entity is valid in selected
  document. In HTML 4.01, all the numerical entities that represent a Unicode
  code point (&lt; U+10FFFFFF) are valid, but that's not the case with other
  document types. If the entity is not valid, &amp; is encoded to &amp;amp;.
  For named entities, the check is also more thorough. While before the only
  check would be to determine if the entity was constituted by alphanumeric
  characters, now it is checked whether that entity is necessarily defined for
  the target document type. Otherwise, &amp; is encoded to &amp;amp;.
- For html_entity_decode(), only valid numerical and named entities (as defined
  above for htmlentities()/htmlspecialchars() + !double_encode) are decoded.
  But there is in this case one additional check. Entities that represent
  non-SGML or otherwise invalid characters are not decoded. Note that, in
  HTML5, U+000D is a valid literal character, but the entity &amp;#x0D is not
  valid and is therefore not decoded.
- The hash tables lazily created for decoding in html_entity_decode() that were
  added recently were substituted by static hash tables. Instead of 1 hash
  table per encoding, there's only one hash table per document type defined in
  terms of unicode code points. This means that for charsets other than UTF-8
  and ISO-8859-1, a conversion to unicode code points is necessary before
  decoding.
- On the encoding side, the ad hoc ranges of entities of the translation
  tables, which mapped (in general) non-unicode code points to HTML entities
  were replaced by three-stage tables for HTML 4 and HTML 5. This mapping
  tables are defined only in terms of unicode code points, so a conversion
  is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the
  multi-stage table is much faster than the previous method, by a factor
  of 5; the conversion to unicode is a small penalty because it's just a
  simple table lookup.
  XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage
  table.
- Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars()
  replace the invalid multibyte sequences with U+FFFD (UTF-8) or &amp;#FFFD;
  (other encodings).
- Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot
  appear literally are replaced by U+FFFD (UTF-8) or &amp;#FFFD; (otherwise).
  An alternative implementation would be to encode those characters into
  numerical entities, but that would only work in HTML 4.01 due to limitations
  on the values of numerical entities in other document types. See also the
  effects on htmlentities()/htmlspecialchars() with !double_encode above.
 [2010-10-24 17:22 UTC] cataphract@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cataphract
 [2010-10-24 17:22 UTC] cataphract@php.net
Implemented not exactly stripping, but conversion to U+FFFD for trunk with ENT_DISALLOWED.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 09:01:29 2024 UTC