Closed GoogleCodeExporter closed 9 years ago
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.
Original comment by mikesamuel@gmail.com
on 16 Jul 2013 at 4:22
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.
Original comment by fred.lin...@gmail.com
on 16 Jul 2013 at 9:56
Attachments:
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.
Original comment by fred.lin...@gmail.com
on 16 Jul 2013 at 10:01
Attachments:
Great. Thanks.
Original comment by mikesamuel@gmail.com
on 16 Jul 2013 at 10:38
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.
Original comment by mikesamuel@gmail.com
on 17 Jul 2013 at 12:24
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.
Original comment by mikesamuel@gmail.com
on 17 Jul 2013 at 10:20
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).
Original comment by fred.lin...@gmail.com
on 18 Jul 2013 at 7:50
Stackoverflow is fixed at r198.
Punting on support for data URLs until there is a client who really needs image
embedding via CSS.
Original comment by mikesamuel@gmail.com
on 24 Jul 2013 at 3:47
Thanks, Mike!! OK in testing. Will use in prod as soon as it shows up on maven
central.
Original comment by fred.lin...@gmail.com
on 24 Jul 2013 at 4:20
Original issue reported on code.google.com by
fred.lin...@gmail.com
on 16 Jul 2013 at 2:51Attachments: