Stackoverflow sanitizing HTML with large inline background-image about java-html-sanitizer HOT 9 CLOSED

Is the image copyrighted?

Thanks for the note on the regexs.  I have a rewrite of the CSS lexer mostly 
ready to go which gets rid of regular expressions (and the associated unbounded 
recursion and backtracking) entirely.

Great!

Copyright - I don't know.

It looks like someone sent this page:
http://www.thesouthafrican.com/entertainment/south-african-couple-launches-engli
sh-bubbly-to-rival-champagne.htm

and that the image is the red "+share" icon at the top. Attaching as both 
base64 (from the html) and decoded to gif.

Attached, Untitled.zip that includes Untitled.html, Untitled.b64, and 
Untitled.gif that I made using gimp. It triggers the same error.

I hereby release this to the public domain without any warranty explicit or 
implied.

Great.  Thanks.

https://code.google.com/p/owasp-java-html-sanitizer/source/detail?r=180 
replaces the CSS lexer with one that passes your test, and doesn't backtrack 
but I'm not going to close this bug until that's production ready since the new 
code has not been thoroughly vetted on malformed inputs.  

My plan thus far is

1. Rewrite the CSS filter with a token-level filter based on Caja white-lists ( 
https://code.google.com/p/google-caja/wiki/CajaWhitelists ) that conservatively 
identifies all URLs, and normalizes tokens.  This should fix all the border 
problems by being more permissive and put us in a place to allow data URLs.
2. Test the new lexer with fuzzers and white-box tests until I'm confident that 
there's no inf. loops.
3. Push a release with the more liberal CSS sanitizer.
4. Look into data: URLs and plan from there.

I should be able to get 1-3 done this week or next, but feel free to play 
around with trunk in the meantime but please don't roll out to production yet.

Re data: attributes, I'm unsure what to do there.

https://www.owasp.org/images/0/03/Mario_Heiderich_OWASP_Sweden_The_image_that_ca
lled_me.pdf suggests that allowing images is not ok, and I don't know whether 
browsers agree on the origin of an image from a data URL.

I could whitelist

    data:image/gif;base64,...
    data:image/png;base64,...
    data:image/jpeg;base64,...

where the first 4 characters of ... are the b64 encoding of the first 3 
characters of the magic number for that image type.

That doesn't eliminate the risk of polyglots like 
http://www.thinkfu.com/blog/gifjavascript-polyglots but combined with the 
explicit mime-type should suffice.

Tested with trunk/r198 and can confirm that the stack overflow no longer 
happens. For my application, I don't miss the image. We want to show email 
reasonably faithfully, but removing attack vectors in much more important that 
look and this type of inline image data is rare (it was one document in about 
150,000).

Stackoverflow is fixed at r198.

Punting on support for data URLs until there is a client who really needs image 
embedding via CSS.

Thanks, Mike!! OK in testing. Will use in prod as soon as it shows up on maven 
central.