bluemonday
bluemonday copied to clipboard
Add ability to specify inline style policies
Following on from #43 / #44, I've implemented a policy type and builder for style policies, following the same pattern as attribute policies. That means that you can whitelist individual CSS properties either globally (on any element that's had the style
attribute whitelisted) or on specific elements. In addition, a MatchingEnum
method allows for a list of allowed values to be specified (useful for properties which have a set of predefined values, so that you don't need to build a regular expression to do this).
Note that this PR does not touch the predefined policies, though it does open the door to doing so in the future (either updating existing ones or adding new policies which include style policies).
It's currently implemented using simple string processing, rather than adding an external dependency; if that's deemed to be too naive or weak, the sanitizeStyles
func in sanitize.go
can be enhanced to use an actual parser (either an external dependency like douceur - as per #43 / #44 - or a custom minimal implementation to avoid external dependencies).
Closes #43.
Any work going on this I have started to use this in one of the projects at my company. Works like a charm. Also is there any list of styles I can allow without worrying about XSS injection as if you have to create a policy that handles each style individually will get really painful to write and a nightmare to maintain.
Any idea if this PR will be merged soon ? Should I fork to get it ?
You should fork it.
It is not safe to use from a security perspective.
I totally get the convenience, and if you are in control of your HTML input then this is good enough to be used as you control the inputs. But CSS can be harmful as it can be used for anything from keylogging to inserting SVG and scripting content into the HTML.
Until such a time that either I find time to write a safe version, or a PR is made that is whitelist-based and tests the values within the style attribute and style blocks... I won't merge code that introduces security risks into a security package.
OK, thanks for replying. I understand your point.