| blob | de22c2155d1936bfce1f703d9fdd48c64a42021f |
3 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [
5 ]>
10 <head>
13 <meta name="keywords" content="HTMLPurifier, HTML Purifier, HTML, filter, filtering, HTML_Safe, PEAR, comparison, kses, striptags, SafeHTMLChecker" />
14 </head>
15 <body>
24 <p>
26 the end user has gone from passive consumer to active producer of content
30 </p>
32 <p>
33 Give the user too much control, however, and you set yourself up for <a
36 proven to be both a blessing and a curse, and the software that
37 processes it must strike a fine balance between security and usability.
38 How do we prevent users from injecting JavaScript or inserting malformed
43 come across this problem before, and many have tried (albeit
44 unsuccessfully) to solve this problem. We will analyze existing
45 libraries to demonstrate how they are ineffective and, of course, how
47 standards-compliance.
48 </p>
50 <p>
51 I will take no quarter and pull no punches: as of the time of writing,
53 for richly formatted documents. But, nonetheless, there is a necessary
54 disclaimer:
55 </p>
58 <p>
59 This comparison document was written by the author of HTML Purifier,
61 mean that it is biased: I have made every attempt to be <strong>factual and
62 fair</strong>, and I hope that you will agree, by the time you finish reading
64 filter out there today.
65 </p>
66 </div>
77 <thead>
78 <tr>
90 </tr>
91 </thead>
93 <tbody>
95 <tr>
107 </tr>
109 <tr>
121 </tr>
123 <tr>
135 </tr>
137 <tr>
149 </tr>
151 <tr>
163 </tr>
165 <tr>
177 </tr>
179 <tr>
191 </tr>
193 </tbody>
195 </table>
196 </div>
198 <p>
201 </p>
207 A clever person solves a problem.
208 A wise person avoids it.
209 </div>
211 </blockquote>
213 <p>
214 Before we jump into the weird and not-so-wonderful world of
218 number one method of taking user input and processing it into something
220 define their own markup syntax. <a
225 such markup languages (although it should be noted that Wikitext and
227 those who use it, anyway) are clear: simplicity and security.
228 </p>
231 <thead>
232 <tr>
235 </tr>
236 </thead>
237 <tbody>
238 <tr>
241 </tr>
242 <tr>
245 </tr>
246 <tr>
249 </tr>
250 <tr>
253 </tr>
254 <tr>
256 <td><tt><b>B</b> <i>i</i> <a href="http://www.example.com/">link</a></tt></td>
257 </tr>
258 <tr>
261 </tr>
262 </tbody>
263 </table>
266 <li>
267 Wikitext shown is modeled after <a
269 There are many variants of Wikitext currently extant.
270 </li>
271 <li>
272 Strictly speaking, the Markdown syntax is not equivalent: bold text
275 however, map those two semantic tags to the associated styling, so
276 many users assume that it really is italics (and use it improperly for,
277 say, book titles.)
278 </li>
279 </ol>
283 <p>
285 read. For example, compare:
286 </p>
288 <pre>
289 * Item 1
290 * Item 2
291 </pre>
295 <pre>
300 </pre>
302 <p>
303 Which would you prefer to edit? The answer seems obvious, but be careful
304 not to fall into the fallacy of <a
307 text) editor, which blows earlier choices out of the water in terms of
308 usability.
309 </p>
311 <p>
312 Note that rich text editors and alternate markup syntaxes are not
313 mutually exclusive, but, when push comes to shove, it's easier
315 markup language. And in the cases when it is done, you usually end up with
316 a live preview, not a true rich text editor.
317 </p>
320 <p>
322 editors aren't all that great.</q> There are many good arguments against
323 these editors, and <a
325 people have written essays</a> devoted to criticizing
327 said editors, the web poses another limitation: no JavaScript means no
328 editor, and no editor means... (gasp) manually typing in code.
329 </p>
330 <p>
331 Even the most dogmatic purist, however, should recognize that for all
333 There are steps you can take to mitigate the associated drawbacks of
334 these editors.
335 </p>
336 <p>
339 this is the case with any markup language that allows the smallest
342 eliminate the dialogue boxes that allow users to change colors or fonts
344 scheme, allowing users to select contextually correct formatting styles
345 for segments of text.
346 </p>
347 </blockquote>
349 <p>
350 Simplicity is also a double-edged sword. The moment any remotely
351 complex markup is needed, these lightweight markup languages fail to
352 produce. Sure you can make '''this text bold''' with Wikitext, but that
356 restrictive (besides the fact that their table markup is extraordinarily
357 complex).
358 </p>
362 <p>
365 the angled brackets with square brackets and omitting the occasional parameter
366 name? How much more un-original can you get? Somehow, I don't think BBCode
367 was meant to readable. <a
369 </p>
371 <blockquote>
372 BBCode was devised and put to use in order to provide a safer, easier
373 and more limited way of allowing users to format their messages.
375 which could be used to break/imitate parts of the layout, or run
376 JavaScript. Some implementations of BBCode have suffered problems related
378 security that was intended to be given by BBCode.
379 </blockquote>
383 <blockquote>
384 BBCode came to life when developers where too
386 and decided to invent their own markup language. As with all products of
387 laziness, the result is completely inconsistent, unstandardized, and
388 widely adopted.
389 </blockquote>
391 <p>
392 Well, developers, the whole point of HTML Purifier is that I do the
393 work so you can just execute the ridiculously simple
396 </p>
400 <p>
401 These alternative markup languages have their shiny points, and HTML
402 Purifier is not meant to replace them. However, a major reason for
404 using these languages?
405 </p>
409 <p>
410 Dave Raggett's
414 The premise is simple, the execution effective. Tidy is, in short, a great
416 </p>
418 <p>
419 It is not, however, a filter. I am often surprised when people ask
422 </p>
431 </blockquote>
433 <p>
440 </p>
442 <p>
443 This is not to say that I haven't seen Tidy be used in this sort of
445 output before shuttling it off to the browser. The developers, nevertheless,
446 agree that this is only a band-aid solution, and that the real way
447 to fix it is to fix the parser. Tidy's great, but in terms of security,
448 it's not suitable for untrusted sources.
449 </p>
453 <p>
454 I've ordered my analyses according to how bad a library is. The worst
455 is first, and then we move up the spectrum. I will point out the most
456 flagrant problems with the libraries, but note that I will omit more
459 points through. The ideal solution, however, must do all these things.
460 </p>
462 <p>
463 Note that besides striptags,
465 attacks. None of them (save Safe HTML Checker) fare very well
466 in the standards-compliance department though.
467 </p>
477 </table>
479 <p>
482 the classic solution for attempting to clean up
485 The fact that it doesn't validate attributes at all means that anyone can
487 </p>
489 <p>
490 While this can be bandaided with a series of regular expressions that strip out
492 quirky browser behavior), striptags() is fundamentally flawed and should not be
493 used.
494 </p>
498 <p>
499 Though its title may not imply it,
501 is a souped up version of striptags() with the ability to inspect
502 attributes. (Don't mind the hastily tacked on query escaping function).
503 </p>
516 </table>
518 <p>
519 PHP Input Filter implements an
521 performs very basic checks on whether or not tags and attributes have
522 been defined in the whitelist as well as some
524 the user to define what they'll permit.
525 </p>
527 <p>
528 With absolutely no checking of well-formedness, it is trivially easy
529 to trick the filter into leaving unclosed tags lying around. While to some
531 basic sanity checks like this must be implemented, otherwise a user
532 can mangle a website's layout.
533 </p>
535 <p>
536 More troubles: Woe to
539 layout not to be badly mutilated. To top things off,
540 the filter doesn't even preserve data properly: attributes have all
541 spaces stripped out of them. Stay away, stay away!
542 </p>
546 <p>
549 It should be noted that this is the same library as
551 branding (and a different version number).
552 </p>
565 </table>
567 <p>
568 HTML_Safe's mechanism of action involves parsing
571 validation and filtering as the handlers are called. HTML_Safe does a lot
574 is fundamentally flawed: blacklists.
575 </p>
577 <p>
578 This library maintains arrays of dangerous tags, attributes and
581 intelligently disabled by default in favor of a protocol whitelist.)
582 What this means is that HTML_Safe has no qualms of accepting input
584 the tags in those arrays. Scratch standards-compliance (and that was
585 without even considering proper nesting).
586 </p>
588 <p>
590 In the future, however, one of the infinitely many tags that HTML_Safe lets
591 through might just possibly be given special functionality by browser vendors.
593 solution puts you at a perpetual arms race against crackers who are constantly
594 discovering new and inventive ways to abuse tags and attributes that you
595 didn't blacklist.
596 </p>
600 <p>
605 </p>
618 </table>
620 <p>
621 To be truthful, I didn't do as comprehensive a code survey for kses
622 as I did for some of the other libraries. Out of
623 all the classes I've reviewed so far, kses was definitely the hardest to
624 understand.
625 </p>
627 <p>
628 kses's modus operandi is splitting up html with a monster regexp
630 suffers from the same problems as Input Filter: no well-formedness
631 checks leading to rampant runaway tags (and no standards-compliance).
632 WordPress, the primary user of kses today, had to implement their
633 own custom tag-balancing code to fix this problem: don't use this
634 library without some equivalent!
635 </p>
637 <p>
638 Its whitelist syntax, however, is the most complex of all these libraries,
639 so I'm going to take some time to argue why this particular implementation
640 is bad. The author of this library was thoughtful enough to provide some
641 basic constraint checks on attributes like maxlen and maxval. Now, barring
642 the fact that there simply aren't enough checks, and the fact that they are
643 all lumped together in one function, we now must wonder whether or not
644 the user will go through the trouble of specifying the maximum length
645 of a title attribute.
646 </p>
648 <p>
649 I have my opinions about inherent human laziness, but perhaps WordPress's
650 default filterset is the most telling example:
651 </p>
653 <pre>
654 $allowedposttags = array (
655 /* formatted and trimmed */
656 'hr' => array (
657 'align' => array (),
658 'noshade' => array (),
659 'size' => array (),
660 'width' => array ()
661 )
662 );
663 </pre>
665 <p>
666 Hmm... do I see a blatant lack of attribute constraints? Conclusion:
667 if the user can get away with not doing work, they will! The biggest
669 the whitelist. The whitelist is just as important as the code that uses
671 </p>
675 <p>
676 <a href="http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/index.php">htmLawed</a>
677 is kses on steroids. After looking at HTML Purifier and deciding that it was
678 too slow for him, Santosh Patnaik went ahead and rewrote the kses engine
679 with more features. It is the only other filtering library currently available
680 that is being actively maintained.
681 </p>
694 </table>
696 <p>
699 output. Unfortunately, it is vulnerable to a few of the vectors in
701 cheat-sheet.</a> I have not listed them here to give the vendor a chance
702 to fix these issues.
703 </p>
705 <p>
706 htmLawed improves standards-compliance, but it is not fully standards-compliant;
707 there are a number of cases which the author has explicitly stated he will not
708 fix. There are issues with content
711 </p>
713 <p>
717 to turn on htmLawed's security features! This is
719 design</a>. Sane defaults are important, because for every person who
720 does read the documentation, there is
722 one who doesn't (and is mislead by claims that <q>htmLawed is a single-file PHP
723 software that makes input text secure</q>), and is
724 surprised at some behavior.
726 any security restrictions.
727 </p>
729 <p>
730 I also disagree with some of the choices with regards to what elements are
733 but they are certainly not phishing safe. An attacker can set an iframe
734 to 100% width and height and effectively take over a website; forms can be
737 </p>
739 <p>
740 Users, you may be smarting for some better performance, but avoid this
741 library for now, at the very least until the vulnerabilities are fixed.
742 </p>
746 <p>
748 HTML Checker</a> is (to my knowledge) the first attempt to make a filter
751 search result must have done something right.
752 </p>
765 </table>
767 <p>
768 Indeed, it is quite a well-written piece of code. It demonstrates
769 knowledge of inline versus block elements, thus almost nearly getting
770 nesting correct (the only exception is an unimplemented omitted SGML
772 </p>
774 <p>
775 Unfortunately, part of the reason why it works so well is that it's
776 extremely restrictive. No styling, no tables, very few attributes.
777 Perfectly appropriate for blog comments, but then again, there's always
778 BBCode. This probably means that Safe HTML Checker has a different
779 goal than HTML Purifier.
780 </p>
782 <p>
784 < sign? The parser will complain with the cryptic message:
786 simple as just switching to a more permissive parser: Safe HTML Checker
787 relies on the fact that the parser will have matched up the tags for
788 them.
789 </p>
804 </table>
806 <p>
807 That table should say it all, but I'll add a few more features:
808 </p>
820 </table>
822 <p>
823 This is not to say that HTML Purifier doesn't have problems of its own.
824 It's big (while the others usually fit in one file, this one requires a huge
826 features.</a> But even with these deficiencies,
827 HTML Purifier is far better than the other libraries.
828 </p>
830 <p>
832 </p>
834 </div>
835 </div>
836 </body>
837 </html>