docs/enduser-overview.txt

   1
   2 HTML Purifier
   3   by Edward Z. Yang
   4
   5 There are a number of ad hoc HTML filtering solutions out there on the web
   6 (some examples including HTML_Safe, kses and SafeHtmlChecker.class.php) that
   7 claim to filter HTML properly, preventing malicious JavaScript and layout
   8 breaking HTML from getting through the parser.  None of them, however,
   9 demonstrates a thorough knowledge of neither the DTD that defines the HTML
  10 nor the caveats of HTML that cannot be expressed by a DTD.  Configurable
  11 filters (such as kses or PHP's built-in striptags() function) have trouble
  12 validating the contents of attributes and can be subject to security attacks
  13 due to poor configuration.  Other filters take the naive approach of
  14 blacklisting known threats and tags, failing to account for the introduction
  15 of new technologies, new tags, new attributes or quirky browser behavior.
  16
  17 However, HTML Purifier takes a different approach, one that doesn't use
  18 specification-ignorant regexes or narrow blacklists.  HTML Purifier will
  19 decompose the whole document into tokens, and rigorously process the tokens by:
  20 removing non-whitelisted elements, transforming bad practice tags like <font>
  21 into <span>, properly checking the nesting of tags and their children and
  22 validating all attributes according to their RFCs.
  23
  24 To my knowledge, there is nothing like this on the web yet.  Not even MediaWiki,
  25 which allows an amazingly diverse mix of HTML and wikitext in its documents,
  26 gets all the nesting quirks right.  Existing solutions hope that no JavaScript
  27 will slip through, but either do not attempt to ensure that the resulting
  28 output is valid XHTML or send the HTML through a draconic XML parser (and yet
  29 still get the nesting wrong: SafeHtmlChecker.class.php does not prevent <a>
  30 tags from being nested within each other).
  31
  32 This document no longer is a detailed description of how HTMLPurifier works,
  33 as those descriptions have been moved to the appropriate code.  The first
  34 draft was drawn up after two rough code sketches and the implementation of a
  35 forgiving lexer.  You may also be interested in the unit tests located in the
  36 tests/ folder, which provide a living document on how exactly the filter deals
  37 with malformed input.
  38
  39 In summary (see corresponding classes for more details):
  40
  41 1. Parse document into an array of tag and text tokens (Lexer)
  42 2. Remove all elements not on whitelist and transform certain other elements
  43    into acceptable forms (i.e. <font>)
  44 3. Make document well formed while helpfully taking into account certain quirks,
  45    such as the fact that <p> tags traditionally are closed by other block-level
  46    elements.
  47 4. Run through all nodes and check children for proper order (especially
  48    important for tables).
  49 5. Validate attributes according to more restrictive definitions based on the
  50    RFCs.
  51 6. Translate back into a string. (Generator)
  52
  53 HTML Purifier is best suited for documents that require a rich array of
  54 HTML tags.  Things like blog comments are, in all likelihood, most appropriately
  55 written in an extremely restrictive set of markup that doesn't require
  56 all this functionality (or not written in HTML at all), although this may
  57 be changing in the future with the addition of levels of filtering.
  58
  59     vim: et sw=4 sts=4