Closing as resolved for H4.  XSS filtering is now handled by the 
libxml parser, so it is largely out of our hands.  And the current 
code passes all the XSS tests present in the unit tests.  Further 
issues should be handled on a case by case basis.

http://blog.liip.ch/archive/2008/09/10/missed-case-in-externalinput-php-resulting-in-viable-xss-attacks.html

http://www.thespanner.co.uk/2008/06/30/javascript-protocol-fuzz-results/

Since we pass the XSS cheat sheet now, I'm going to stall this pending 
Horde 4.

This would be an interesting approach and possibly a very interesting 
library to port to PHP:



http://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

http://htmlpurifier.org/

Added most of the tidy parameters used in the sanitizer to IMP.  Also, 
made sure charset information in IMP was correct, and made sure we are 
using tidy version 2.0.

This is from a proposed PEAR package; it requires PHP 5.2+ and Tidy, 
so the requirements are steep, but by the time we're doing the next 
major version we'll probably be requiring the 5.2 part anyway. Also 
note that I haven't had a chance to check the current tidy code in 
detail; it might be easy enough to add this in, or it might be largely 
duplicative, or ...

Experimental support for filtering with 'tidy' has been added to IMP HEAD.

On this note, maybe we should also use the tidy PECL extension if available:

http://pecl.php.net/package/tidy

... and my head is fuzzy today; php markdown may not be at all 
relevant for filtering existing html, as opposed to as another 
alternative for letting users enter marked-up content instead of raw 
html.

Further notes - SafeHTML is also available through PEAR:

http://pear.php.net/package/HTML_Safe



And there's also PHP Markdown:

http://www.michelf.com/projects/php-markdown/

SafeHTML: http://pixel-apes.com/safehtml/

A few more resources:



1. Use the php5 tidy extension if available to clean up invalid html 
and to make the html more predictable in general.



2. http://sourceforge.net/projects/kses



3. XSS cheatsheet: http://ha.ckers.org/xss.html



4. bitflux XSS prevention wiki page: 
http://blog.bitflux.ch/wiki/XSS_Prevention

Also interesting. We might want to catch \0 additionally to \s inside

malicious tags.



----- Weitergeleitete Nachricht von s.esser@e-matters.de -----

     Datum: Wed, 14 Jul 2004 00:55:25 +0200

     Von: Stefan Esser <s.esser@e-matters.de>

Antwort an: Stefan Esser <s.esser@e-matters.de>

  Betreff: Advisory 12/2004: PHP strip_tags() bypass vulnerability

       An: vulnwatch@vulnwatch.org, full-disclosure@lists.netsys.com,

bugtraq@securityfocus.com





                            e-matters GmbH

                           www.e-matters.de



                       -= Security  Advisory =-







      Advisory: PHP strip_tags() bypass vulnerability

  Release Date: 2004/07/14

Last Modified: 2004/07/14

        Author: Stefan Esser [s.esser@e-matters.de]



   Application: PHP <= 4.3.7

                PHP5 <= 5.0.0RC3

      Severity: A binary safety problem within PHP's strip_tags()

                function may allow injection of arbitrary tags

                in Internet Explorer and Safari browsers

          Risk: Moderate

Vendor Status: Vendor has released a bugfixed version.

     Reference: http://security.e-matters.de/advisories/122004.html





Overview:



    PHP is a widely-used general-purpose scripting language that is

    especially suited for Web development and can be embedded into HTML.



    According to Security Space PHP is the most popular Apache module

    and is installed on about 50% of all Apaches worldwide. This figure

    includes of course only those servers that are not configured with

    expose_php=Off.



    During an audit of the PHP source code a binary safety problem in

    the handling of allowed tags within PHP's strip_tags() function

    was discovered. This problem may allow injection of f.e. Javascript

    in Internet Explorer and Safari browsers.





Details:



    Many sites stop XSS attacks by striping unsafe HTML tags from the

    user's input. PHP scripts usually implement this functionality

    with the strip_tags() function. This function takes a optional

    second parameter to specify tags that should not get stripped

    from the input.



    $example = strip_tags($_REQUEST['user_input'], "<b><i><s>");



    Due to a binary safety problem within the allowed tags handling

    attacker supplied tags like: <\0script> or <s\0cript> will pass

    the check and wont get stripped. (magic_quotes_gpc must be Off)



    In a perfect world this would be no dangerous problem because

    such tags are either in the allowed taglist or should get

    ignored by the browser because they have no meaning in HTML.



    In the real world however MS Internet Explorer and Safari filter

    '\0' characters from the tag and accept them as valid. Quite

    obvious that this can not only lead to a number of XSS issues

    on sites that filter dangerous tags with PHP's strip_tags() but

    also on every other site that filters them with pattern matching

    and is not necessary running PHP.



    According to tests:



     - Opera

     - Konqueror

     - Mozilla

     - Mozilla Firefox

     - Epiphany



     are NOT affected by this.





Proof of Concept:



    e-matters is not going to release an exploit for this vulnerability

    to the public.





Disclosure Timeline:



    26. June 2004 - Problem found and fixed in CVS

    14. July 2004 - Public Disclosure





CVE Information:



    The Common Vulnerabilities and Exposures project (cve.mitre.org) has

    assigned the name CAN-2004-0595 to this issue.





Recommendation:



    Because Internet Explorer is out of all reason still the most used

    browser fixing this problem within your PHP version is strongly

    recommended.





GPG-Key:



    http://security.e-matters.de/gpg_key.asc



    pub  1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam

    Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA  A71A 6F7D 572D 3004 C4BC





Copyright 2004 Stefan Esser. All rights reserved.

I haven't read this in depth yet, but might be worth another HTML MIME

viewer review.



----- Weitergeleitete Nachricht von james.slora@phra.com -----

     Datum: Tue, 13 Jul 2004 15:30:08 -0400

     Von: "James C. Slora, Jr." <james.slora@phra.com>

Antwort an: "James C. Slora, Jr." <james.slora@phra.com>

  Betreff: Find the tag continued

       An: bugtraq@securityfocus.com, Windows NTBugtraq Mailing List

<NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>



Takeoff from http-equiv's notes about closing >



By design, unprocessable HTML tags and tag parameters are ignored during

parsing. An amazing amount of worthless obfuscating stuff can be

inserted before the closing > of a valid tag, and the parameters for the

tag can be tough to find.



Mail filtering and human review of unwanted stuff like object and iframe

tags might get fooled.



Here is a funnier example of tag obfuscation, plus an odd interactive

rendering of the message. It uses http-equiv's Paul.html for its object

data source. Paste the stuff below into a text file named message.eml

and open it in Outlook Express. Forward it to Outlook for more of the

same fun. Add alternate text for non-html readers, and it could be even

more funny. Mix in some auto-execute silliness to taste. It will already

execute if forwarding while using Word as the email editor.



---> Copy everything below this line <---

Content-Type: text/html;



As part of ongoing security efforts, Big Internet Software Company is

conducting a gullibility test. Forward this to all your friends to see

if they click the link. You will receive twenty dollars from them for

every friend you can fool.<br> <br>This message will now check for your

software's compatibility with this

test.<hemo><poisoning><spamsux><hidden><bury> <object << <img << <html

<<< </body </html



Enlarge your nostrils - she will thank you for it. This is a dull

message designed to distract you from the tag completion down below if

you are a mail administrator who is looking at the source of a spam

message to see if there is anything fishy in it, or if you are a mail

screening program that wants to look for the closing of the object tag

but is only willing to look so far to avoid munching all the CPU time

that is available searching for closing tags.





You can ramble on and on and on yet still remain within the object tag

until you finally come to an &gt; closing element. I wonder what the

limit might be?



Object just goes and goes and goes. You could probably put an

encyclopedia in here.



******************************

Such ridiculous lengths made me wonder if eventually you must overflow a

buffer. But 48MB worth of garbage did not cause any problems - it just

took longer to display.

******************************



Insert additional garbage here ad nauseum.







If you do not wish to receive similar messages in the future, please

send a blank message to

mailto:nostrilenlargement@stickyourfingerinit.com, or use this

unsubscribe link: data=3D"http://www.malware.com/paul.html"

<a HREF="www.widowsupdate.comm">



<br><br>

*********SORRY***********

<br><br>



Your mail client does not support the ActiveX control required to

participate in this test. You may still collect twenty dollars for each

of your friends that clicks.<br><br>



If you do not wish to participate in future tests, <br>please send a

blank message to <br>mailto:nostrilenlargement@stickyourfingerinit.comm,

<br>or use this unsubscribe link:

"http://www.pickledherring.orgg/page.php"



----- Ende der weitergeleiteten Nachricht -----

I'm going to add a few emails from Jan to this ticket to keep track of 
things we may want to do to improve our HTML mime viewer's filtering 
capabilities.