Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sanitizing hangs on embedded SVG data in CSS style attribute #90

Closed
matthewtidd opened this issue Jun 29, 2015 · 16 comments
Closed

Sanitizing hangs on embedded SVG data in CSS style attribute #90

matthewtidd opened this issue Jun 29, 2015 · 16 comments

Comments

@matthewtidd
Copy link

<span style="background: url('data:image/svg&#43;xml;charset=utf-8,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20width%3D%2232%22%20height%3D%2232%22%20viewBox%3D%220%200%2032%2032%22%3E%3Cpath%20fill%3D%22%23D4C8AE%22%20d%3D%22M0%200h32v32h-32z%22%2F%3E%3Cpath%20fill%3D%22%2383604B%22%20d%3D%22M0%200h31.99v11.75h-31.99z%22%2F%3E%3Cpath%20fill%3D%22%233D2319%22%20d%3D%22M0%2011.5h32v.5h-32z%22%2F%3E%3Cpath%20fill%3D%22%23F83651%22%20d%3D%22M5%200h1v10.5h-1z%22%2F%3E%3Cpath%20fill%3D%22%23FCD050%22%20d%3D%22M6%200h1v10.5h-1z%22%2F%3E%3Cpath%20fill%3D%22%2371C797%22%20d%3D%22M7%200h1v10.5h-1z%22%2F%3E%3Cpath%20fill%3D%22%23509CF9%22%20d%3D%22M8%200h1v10.5h-1z%22%2F%3E%3ClinearGradient%20id%3D%22a%22%20gradientUnits%3D%22userSpaceOnUse%22%20x1%3D%2224.996%22%20y1%3D%2210.5%22%20x2%3D%2224.996%22%20y2%3D%224.5%22%3E%3Cstop%20offset%3D%220%22%20stop-color%3D%22%23796055%22%2F%3E%3Cstop%20offset%3D%22.434%22%20stop-color%3D%22%23614C43%22%2F%3E%3Cstop%20offset%3D%221%22%20stop-color%3D%22%233D2D28%22%2F%3E%3C%2FlinearGradient%3E%3Cpath%20fill%3D%22url(%23a)%22%20d%3D%22M28%208.5c0%201.1-.9%202-2%202h-2c-1.1%200-2-.9-2-2v-2c0-1.1.9-2%202-2h2c1.1%200%202%20.9%202%202v2z%22%2F%3E%3Cpath%20fill%3D%22%235F402E%22%20d%3D%22M28%208c0%201.1-.9%202-2%202h-2c-1.1%200-2-.9-2-2v-2c0-1.1.9-2%202-2h2c1.1%200%202%20.9%202%202v2z%22%2F%3E%3C');"></span>

That block of html causes the scrub!(:strip) function to hang. The offending line of code is:

lib/loofah/html5/scrub.rb:70

The regex itself runs fine on that style tag, but running that regex after the gsub call on line 67 causes it to hang. I would try to fix it myself, but I'm not fluent enough with regex to be able to do that. This appears to be a bug with html5lib as well (where this code was copied) so I can post an issue on their bug tracker if that is preferable.

I'm going to work on a custom scrubber to remove all url attributes completely for now but some advice would be much appreciated.

@mfazekas
Copy link

mfazekas commented Aug 5, 2015

I have the same hang with different attributes:

require 'loofah'

str = "cursor: pointer !important; display: block !important; white-space: nowrap !important; float: left !important; margin-left: 1px !important; vertical-align: top !important; overflow: hidden !important; height: 18px !important; padding: 0px 4px 0px 23px !important; border-width: 1px 1px 1px 0px !important; border-top-style: solid !important; border-right-style: solid !important; border-bottom-style: solid !important; border-top-color: rgb(226, 226, 226) !important; border-right-color: rgb(191, 191, 191) !important; border-bottom-color: rgb(185, 185, 185) !important; text-shadow: rgb(255, 255, 255) -1px 1px 0px !important; line-height: 20px !important; border-top-left-radius: 0px !important; border-bottom-left-radius: 0px !important; border-top-right-radius: 2px !important; border-bottom-right-radius: 2px !important; background-color: rgb(236, 236, 236) !important; background-image: -webkit-linear-gradient(top, rgb(254, 254, 254) 0%, rgb(236, 236, 236) 100%) !important;"

Loofah::HTML5::Scrub.scrub_css str

ruby 2.2.0
i've got here from rails 4.2.3 sanitize. Probably not infinite loop just an exponentiental regex.

@zzak
Copy link

zzak commented Aug 8, 2015

I found the offending commit: 37e5011

When I remove the dash and try @mfazekas's example above, the script will execute.

@mfazekas
Copy link

Using a css parser like https://github.com/rgrove/crass vs regex could also help avoiding such issues. See also html5lib/html5lib-python#152

@zzak
Copy link

zzak commented Aug 10, 2015

@mfazekas Apart from the actual implementation, there are some trade-offs when switching to crass:
https://github.com/rgrove/crass#problems

That said, if we can come up with a patch to update scrub_css to use crass, it might be worth testing!

@flavorjones
Copy link
Owner

Looking.

@flavorjones
Copy link
Owner

@mfazekas I cannot reproduce with your string, using nokogiri 1.6.6.2 and ruby 2.2.2p95.

@matthewtidd I can reproduce with your string, same config, where there's a delay of ~3s on my laptop.

@flavorjones
Copy link
Owner

I agree with @mfazekas and html5lib/html5lib-python#152 that we shouldn't be using regexes to parse CSS. It's stupid, and it's only here because Loofah's heritage is from html5lib.

I'm not sure what to do here. I'd rather break CSS parsing than allow for a DOS vector, which makes me want to revert 37e5011 and related commits.

Thoughts?

@flavorjones
Copy link
Owner

Adding @claudiob and @kaspth in case they have opinions.

@rafaelfranca
Copy link

I think that reverting is the safer patch. Later we can think in changing strategy to use a CSS parser.

@claudiob
Copy link

I don't have any specific opinion on this 🎀

@kaspth
Copy link
Contributor

kaspth commented Aug 17, 2015

I'm with @rafaelfranca on this 👍

@flavorjones
Copy link
Owner

OK, proposing this release schedule:

  • release 2.0.3, which will revert this change (and related changes)
  • release 2.1.0, which will replace the current implementation of Loofah::HTML5::Scrub.scrub_css with a real CSS parser

presuming I can get a CSS parser to work. I'll start with crass. Objections?

flavorjones added a commit that referenced this issue Aug 17, 2015
flavorjones added a commit that referenced this issue Aug 17, 2015
at the cost of breaking support for negative CSS values.

Related to #90.
@flavorjones
Copy link
Owner

Loofah 2.0.3 was just released, which reverts the functionality from #64 and related #85, and addresses this particular slow/recursive regex.

I've opened #91 for follow-on work to replace the regexes entirely.

@kaspth
Copy link
Contributor

kaspth commented Aug 17, 2015

Sounds good to me, thanks Mike 👍

Den 17/08/2015 kl. 20.34 skrev Mike Dalessio [email protected]:

Closed #90 #90.


Reply to this email directly or view it on GitHub #90 (comment).

Kasper

flavorjones added a commit that referenced this issue Aug 17, 2015
@flavorjones
Copy link
Owner

Just a note that v2.1.0.rc1 has been released which re-implements this logic on top of Crass. Please follow or comment on #91. Thanks, all!

@zzak
Copy link

zzak commented Aug 18, 2015

Thank you @flavorjones!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants