Tips for Instructional Designers related to AntiSamy (what code to avoid)?

[Regan, Alan]

All,

 

Some of the instructional designers at our university are pulling their hair out.  The frustration comes from the pop-up message: "Notice: Your HTML contains tags or attributes that are not permitted and have been removed from your content."  It seems that the AntiSamy solution to secure the service can sometimes block tags or code that doesn't seem like a security issue.  For example, it seems that some colors may be blocked, and I saw in a JIRA that one of the three possible strikethrough tags was being blocked (the S tag that the CKEditor uses).  So even some tags the CKEditor may use by default could conflict with AntiSamy rules.

 

 

QUESTIONS:

·         Has anyone compiled some standard AntiSamy exceptions that would help an institution allow select items that are common to good design without impacting security?  (Suggestions or specific code for system administrators to consider.)

·         On the other side, has anyone compiled code or options that are being correctly blocked for good reason, and instructional designers should steer clear of?  (A guide for instructional designers, professors, and content creators to avoid the pop-up warning and having code stripped out of their post.)

 

Any guidance appreciated so my team can communicate with our school content creators and help them avoid problems.

 

Sincerely,

 

Alan Regan

Director, Client Services

Information Technology

Pepperdine University

(310) 506-6756

http://community.pepperdine.edu/it

http://community.pepperdine.edu/techlearn

 

[David Eveland]

I resonate with this – especially the concept of having a guide for what ‘can’ be used and what ‘can’t’ be used.

 —

Dave E. | Johnson University
--- End of reply/forward ---

 

--
You received this message because you are subscribed to the Google Groups "Sakai Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-user+...@apereo.org.
To post to this group, send email to sakai...@apereo.org.
Visit this group at http://groups.google.com/a/apereo.org/group/sakai-user/.

[Neal Caidin]

Keep in mind that AntiSamy is configurable. 

# Whether or not to append a target=_blank if there is no target attribute on anchor tags

# DEFAULT: true

# content.cleaner.add.blank.target=false

# Force the user of a lower security profile for content processing and scanning,

# if this is not overridden then high security settings are used.

# The standard high and low files are located in "kernel/sakai-kernel-impl/src/main/resources/antisamy/"

# Override the standard files by placing your own files in:

#       ${sakai.home}/antisamy/high-security-policy.xml

#       ${sakai.home}/antisamy/low-security-policy.xml

# DEFAULT: false (use high security - no unsafe embeds or objects)

#content.cleaner.default.low.security=true

HTH

[Matthew Jones]

Sakai has always operated on a best practice whitelist model [1], everything that is not specifically allowed is denied. This means that sometimes new or custom attributes get dropped when filtering.

It's configurable even beyond what Neal mentioned, I believe most of the issue are with the popup, right? This behavior changed in 10 from 2.9 from "return" (see below) which would display the full error in the tool to just "notify" which just notifies the user that "something" was removed. 

You can optionally turn off the popup completely. But this could mean that the something could be filtered from the content, and if the user doesn't notice they might lose the source of what they entered (usually through a copy/paste) before they notice it was removed. You can also display the specific errors to the user with more detail in the popup.

I'm not sure what the best solution combination is. Really what we want is to know what things are blocked so we can add them to the whitelist so there will be less problems in the future. These updates happen pretty often.

- Is the problem because the box is bright and red? Perhaps if the box was yellow or blue as more of a notice than a warning? This is configurable and may be a good idea (http://sciactive.github.io/pnotify/#demos-simple) 

- Is it because having more details would often help the user identify what to fix? 

- Is it because the user really doesn't care at all their content was altered and the potential for data loss really is not so big of an issue in reality?

Generally the only things that should be stripped are javascript attributes, but new non-standard attributes are being added all the time (often by Microsoft), and deprecated attributes still need to be supported.

# KNL-1075: allow Sakai to behave more like other LMSes and silently clean the user-entered HTML,

# valid options are listed below:

# - none - errors are completely ignored and not even stored at all 

# - logged - errors are output in the logs only 

# - return - errors are returned to the tool (legacy behavior) 

# - notify - user notified about errors using a non-blocking JS popup 

# - display - errors are displayed to the user using the new and fancy JS popup 

# Default: notify

#content.cleaner.errors.handling=return

# Force the logging of errors despite the handling setting 

# (useful for debugging but can get very noisy)

# Default: false (still it could be logged if content.cleaner.errors.handling=logged above) 

#content.cleaner.errors.logged=true

[1] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#A_Positive_XSS_Prevention_Model

[Adam Marshall]

You can configure anti samy to let certain tags and sites through the filter.

By default it really should let the standard ck edit tags through.

Adam

-- sent from my phone

[Matthew Jones]

Yeah, for sure all of the ckeditor tags/attributes and all tags that we know of are allowed. Typically the only time you'd see this is if there is an actual security related tag removed or if it's a new tag that it doesn't know about (like something copied/pasted into the editor).

[Regan, Alan]

Thanks, Matthew.

 

Related to the pop-up message and Matthew's question about the problem --

 

·         Audience.  Who should see the warning?  Should people who can't do anything about the issue see a warning?  In theory, whatever code isn't acceptable was stripped out, so the warning shouldn't persist after the initial save, correct?  From my point of view, students (or site viewers) shouldn't see a scary warning; the warning says "Your HTML" which can be confusing as to who the "you" is.  That said, someone that creates the content absolutely needs to know if they've made a mistake or something is being blocked.

·         Actionable.  The people who can do something about the problem need guidance on what the problem really is.  It's fine and very helpful to have an "Oops!" message, but there also has to be a way to guide the content editor toward a fix for the "oops."  A verbose pop-up might not be the most help (e.g. the "display" option that was mentioned in the settings).  However, the next step is likely for the person to edit the content again.  Just as there's an audit log in some tools, shouldn't there be a log in the editing screen to show the last set of content errors from the given tool in the given site?  That seems like a logical place to provide either the verbose error display or a link to pull it up.  Instructors also don't have access to system logs, so providing some level of information that could assist them fix a content problem on the editing screen seems logical to me.

·         Frequency.  How often should the warning be presented?  I believe this may have been addressed on our Sakai instance by applying a patch so the notice doesn't persist each and every visit to the site/tool.  This is especially frustrating for a site viewer, since they can't do anything and it makes it seem like the system is flawed, etc.

·         Emphasis.  Good question about the warning notice color scheme.  Red does make it seem rather scary and important.  The yellow style in the examples Matthew provided might be a good alternative format, simply to reduce the intensity factor.  My original email was unrelated to the style of the warning, but it's an interesting point to consider.  Thanks for sharing this, Matthew.

  vs.

 

Related to guidelines for instructional designers and content editors --

 

·         What's allowed?  From a security standpoint, I can see the motivation for "everything that is not specifically allowed is denied."  I guess the question then is, what is allowed in the "low" and the "high" modes by default in Sakai 10+?  Pointing me or an instructor to the OWASP site will not fly (no pun intended… okay, maybe a little bit) or very long XML files aren't ideal, either.  Professors, instructional designers, and content creators need guidance in human terms as much as possible.  Would be lovely to have a simple, alphabetized list of "allowed tags" and "allowed attributes." 

o   Would it be hard for someone to code a tool to parse an AntiSamy security policy XML file and spit out a nice text file with headings and bulleted list?  Basically, translating some of the code into human-friendly items?  For example, translate the element " [a-zA-Z0-9\-_]+" into something that professors could understand like "Letters (uppercase and lowercase), Numbers, and select special characters ("\", "-", and"_")."  (I may have missed something, but that's my best guess on the fly…

o   If AntiSamy regulates color names, do the color names match the colors in the CKEditor?

§  Example AntiSamy code: <regexp name="colorName" value="(aqua|black|blue|fuchsia|gray|grey|green|lime|maroon|navy|olive|purple|red|silver|teal|white|yellow)"/>

§  If color names are limited to the list above, if a professor selects the "Brown" color in the CKEditor interface, will the pop-up warning happen and the color choice stripped?

 

Anyway… again, my goal is to help professors and content editors understand what is allowable by default, and then an institution can make decisions about additional items to whitelist given the nature of their community.

 

Thanks, all, for helping think this item though.

 

Sincerely,

 

Alan Regan

Director, Client Services

Information Technology

Pepperdine University

(310) 506-6756

http://community.pepperdine.edu/it

http://community.pepperdine.edu/techlearn

 

[Matthew Jones]

Just a quick response:

On Wed, Sep 16, 2015 at 12:33 PM, Regan, Alan <Alan....@pepperdine.edu> wrote:

Thanks, Matthew.

 

Related to the pop-up message and Matthew's question about the problem --

 

·         Audience.  Who should see the warning?  Should people who can't do anything about the issue see a warning?  In theory, whatever code isn't acceptable was stripped out, so the warning shouldn't persist after the initial save, correct?  From my point of view, students (or site viewers) shouldn't see a scary warning; the warning says "Your HTML" which can be confusing as to who the "you" is.  That said, someone that creates the content absolutely needs to know if they've made a mistake or something is being blocked.

I think sometimes they can do something about it, but really only if the option is turned on to include details. Otherwise it seems more of a notice to the user check to see that the content is displaying correctly since it was altered.

·         Actionable.  The people who can do something about the problem need guidance on what the problem really is.  It's fine and very helpful to have an "Oops!" message, but there also has to be a way to guide the content editor toward a fix for the "oops."  A verbose pop-up might not be the most help (e.g. the "display" option that was mentioned in the settings).  However, the next step is likely for the person to edit the content again.  Just as there's an audit log in some tools, shouldn't there be a log in the editing screen to show the last set of content errors from the given tool in the given site?  That seems like a logical place to provide either the verbose error display or a link to pull it up.  Instructors also don't have access to system logs, so providing some level of information that could assist them fix a content problem on the editing screen seems logical to me.

Perhaps like the first part, the message content of the warning should be clearer. I agree the default warning of 

"Your HTML contains tags or attributes that are not permitted and have been removed from your content." 

is pretty techie and doesn't really provide anything actionable. Do you have better suggestions? 

Perhaps (a little wordy, needs to be condensed)

"Notice: The text you entered contained some content that was not permitted and has been removed. You should verify that the content is still displayed as expected. If you continue to experience this issue please send the full text of the original content to your support desk."

·         Frequency.  How often should the warning be presented?  I believe this may have been addressed on our Sakai instance by applying a patch so the notice doesn't persist each and every visit to the site/tool.  This is especially frustrating for a site viewer, since they can't do anything and it makes it seem like the system is flawed, etc.

Yes https://jira.sakaiproject.org/browse/SAK-29770 should have resolved this. What happened was prior to the popup, each tool was responsible for having some area on the top where the warning message would be displayed. This tool was only filtering on display, not on save. Filtering only on display a commonly recommended "best practice" to preserve the full original content of the author, but difficult to achieve in a legacy system.

This tool didn't have any place to display the warning previously so it wasn't a problem. The new popup is indepdenent of the tool and displays everywhere so in 10 it caused a new regression. So because of this we had to change a lot of tools to filter and modify the text on save as well as on display and just missed this one.

·         Emphasis.  Good question about the warning notice color scheme.  Red does make it seem rather scary and important.  The yellow style in the examples Matthew provided might be a good alternative format, simply to reduce the intensity factor.  My original email was unrelated to the style of the warning, but it's an interesting point to consider.  Thanks for sharing this, Matthew.

  vs.

 

Related to guidelines for instructional designers and content editors --

 

I think changing this to the notice would be a good idea. I created this issue to capture work for some of these changes if you wanted to comment/watch/vote there.

https://jira.sakaiproject.org/browse/SAK-29901

 

·         What's allowed?  From a security standpoint, I can see the motivation for "everything that is not specifically allowed is denied."  I guess the question then is, what is allowed in the "low" and the "high" modes by default in Sakai 10+?  Pointing me or an instructor to the OWASP site will not fly (no pun intended… okay, maybe a little bit) or very long XML files aren't ideal, either.  Professors, instructional designers, and content creators need guidance in human terms as much as possible.  Would be lovely to have a simple, alphabetized list of "allowed tags" and "allowed attributes." 

I think it would be difficult to keep this list up-to-date and also have it accurate without doing something automated (like the idea below)

 

o   Would it be hard for someone to code a tool to parse an AntiSamy security policy XML file and spit out a nice text file with headings and bulleted list?  Basically, translating some of the code into human-friendly items?  For example, translate the element " [a-zA-Z0-9\-_]+" into something that professors could understand like "Letters (uppercase and lowercase), Numbers, and select special characters ("\", "-", and"_")."  (I may have missed something, but that's my best guess on the fly…

I'd say this would be a little bit of work, at least a few hours. The issue is that antisamy has tags, but it also has rules for the tags (such as what to allow). Some of these are simple literals, other times they are regular expressions. Anyway, I've never seen anyone that wrote up something like this but it could be done.

o   If AntiSamy regulates color names, do the color names match the colors in the CKEditor?

§  Example AntiSamy code: <regexp name="colorName" value="(aqua|black|blue|fuchsia|gray|grey|green|lime|maroon|navy|olive|purple|red|silver|teal|white|yellow)"/>

Looking at the low security file https://github.com/sakaiproject/sakai/blob/master/kernel/kernel-impl/src/main/resources/antisamy/low-security-policy.xml

The colors are defined by both the list of the names you supplied as well as another regular expression with the color code. For example a 3-6 digit hex. As far as color it looks like CKEditor is using the hex so it would be allowed. HTML 4.01 defines 16 named colors, those are all of the ones in this list. https://en.wikipedia.org/wiki/Web_colors#HTML_color_names

<attribute name="bgcolor">
<regexp-list>
<regexp name="colorName"/>
<regexp name="colorCode"/>
</regexp-list>

 

§  If color names are limited to the list above, if a professor selects the "Brown" color in the CKEditor interface, will the pop-up warning happen and the color choice stripped?

No, you shouldn't see a popup for any colors picked since all of the CKEditor colors use a code. If you do this is a bug.

[Daniel Merino]

I've been out of work so sorry for the late response.

Related to this conversation I filed a JIRA about the content which is lost when HTML is sanitized, that is the most annoying issue that AntiSamy has raised among our teachers:

https://jira.sakaiproject.org/browse/SAM-2578

Earle suggested an ideal solution for this in the comments, a JS library that sents the content to AntiSamy so feedback can be given before saving the text, though I suspect that is not an easy fix.

Hope it helps.
Best regards.

El 18/09/15 a las 19:50, Matthew Jones escribió:

--

You received this message because you are subscribed to the Google Groups "Sakai Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-user+...@apereo.org.
To post to this group, send email to sakai...@apereo.org.
Visit this group at http://groups.google.com/a/apereo.org/group/sakai-user/.

--
Daniel Merino Echeverría
daniel...@unavarra.es
Gestor de E-learning - Centro Superior de Innovación Educativa.
Tfno: 948-168489 - Universidad Pública de Navarra.