how to edit the antisamy.xml to support the css-style "-webkit-border-radius" or "-moz-border-radius"

[wangyun2018]

when i call the ESAPI.validator().getValidSafeHTML with inputing "-webkit-border-radius" or "-moz-border-radius" ,the style will be Filtered。
does antisamy supports the style or not?
if support ,how can i config the antisamy.xml？

[kwwall]

A few things here:

1. This probably should have been an ESAPI GitHub issue rather than an AntiSamy issue, but since I track AntiSamy too, might as well leave it here as some q's are best answered by the AntiSamy crew.
2. The latest official ESAPI release only supports AntiSamy 1.6.3, but you can use it with 1.6.4 with some Maven exclusion magic in your pom.xml and overriding it to use we 1.6.4. I am waiting for 1.6.5 to be released to do a final ESAPI release that will support Java 7 as the minimal baseline. After that release, we will only be supporting Java 8 or later.
3. ESAPI make or may not support "-webkit-border-radius" or "-moz-border-radius" CSS styles. That depends on 2 things: one is the version of AntiSamy used and whether or not it supports it and the second is whether there is a policy in ESAPI's antisamy.xml. You would likely need to add it to the policy file. ESAPI's antisamy.xml does not track AntiSamy's (maybe it should, but @nahsra decided a long time ago that it shouldn't and since he's the one who created the AntiSamy project, I've followed that approach).

@davewichers or @spassarop - Can one of you speak to what needs to be done in terms of adding a policy for these two CSS styles and answer the question as to which is the earliest version of AntiSamy that would support it? Thanks.

[spassarop]

Hi everyone, in this comment I explain how to add an example policy definition fragment to support the mso-line-height-rule property. For -webkit-border-radius or -moz-border-radius SHOULD BE exactly the same with another name, more on this later.

That example only allows the literal value exactly, it could have several literal values or a regular expression. Instead of, or in addition to, <literal-list> there would be a <regexp-list> tag with at least one <regexp> tag inside. The <regexp> tag can reference an existing regular expression already defined in <common-regexps> section or can define a regular expression for that specific CSS property right there. Here is an example on how to do both:

<regexp-list>
    <!-- This  allows values like "25px" -->
    <regexp name="positiveLength"/> 
    <!-- This  allows values like "25px 10px 5px 10px" -->
    <regexp value="\d+px( \d+px){0,3}"/> 
</regexp-list>

The first is a reference, you can see the defined regexp value in the current antisamy.xml file we have in this repository. The second is really simple, just to show a basic example on how to define a custom regexp.

All of the above works. However, it would not work with -webkit-border-radius nor -moz-border-radius... So I debugged and it seems Batik CSS is letting us down again. Using - to start a property name is not valid for the library so it decides to stop parsing. We've got a stack of issues now, all of them related to the Batik CSS parser but different in nature.

About the versions, I've tried with AntiSamy 1.5.4 and still works with that old version (defining style policy as I explained).

[spassarop]

Looking into Batik issues on JIRA I've found this: https://issues.apache.org/jira/browse/BATIK-1112

Which is that particular case. It's open since 2015 but there is a suggested workaround that might work for us. I'm downloading the Batik repo to see if the workaround can be copied or needs any modification, after that I'll check if it can be actually done on AntiSamy.

[spassarop]

@davewichers you can check my PR with the workaround. I didn't add the suggested XMLResourceDescriptor.setCSSParserClassName(MyParser.class.getName()); line because it worked without it, I don't know what is it for.

[davewichers]

Closing this issue as these changes went out with the 1.6.5 release I just pushed.

[spassarop]

Related to #293