Monday, August 1, 2016

XSS Protection in AEM6

XSS (Cross Site Scripting) protection in AEM to  prevent attackers to inject code into web pages viewed by other users, is based on AntiSamy Java library provided by OWASP (Open Web Application Security Project). Due to this sometime you may get following kind of errors:
org.apache.sling.xss.impl.HtmlToHtmlContentContext AntiSamy warning: The iframe tag contained an attribute that we could not process. The src attribute had a value of "some-non-xss-standard-iframe-url". This value could not be accepted for security reasons. We have chosen to remove this attribute from the tag and leave everything else in place so that we could process the input.

Most basic configurations for XSS protection is configured out of the box. In case you need to happen to change this, you can override these configurations but do it carefully because these configurations apply globally. The default AntiSamy configuration can be found at following location in AEM- /libs/cq/xssprotection/config.xml. For reference, XSS rules are defined like this:
<!-- START: Additions for oembed inserts -->
<regexp name="iframesrc" value="^(http:|https:)?\/\/(www\.)?(((youtube|youtube-nocookie|vimeo|player\.vimeo|dailymotion|instagram|tumblr|twitter|wordpress|facebook|wikipedia|stackoverflow)(\.com))|(flickr\.com|flic\.kr))\/([A-Za-z0-9]).*"/>
<!-- END: Additions for oembed inserts -->

This article categorizes the protection mechanism into two parts-

1. Code Level Protection

A. Use the features/ methods provided by XSS API in you AEM application JSP, Servlets, Services etc. while processing user inputs, page selectors etc. XSS API provides two type of features- encoding and validation. In general, validators are safer than encoders. Encoding only ensures that content within the encoded context cannot break out of said context. It requires that there be a context (for instance, a string context in Javascript), and that damage cannot be done from within the context (for instance, a javascript: URL within a href attribute.

In Java code-
import com.adobe.granite.xss.XSSAPI;
import org.apache.sling.api.resource.ResourceResolver;

public class UserInput {
  public String getFilteredURL(ResourceResolver resolver, String userInputText) {
    XSSAPI xssAPI = resolver.adaptTo(XSSAPI.Class);
    return xssAPI.getValidHref(userInputText);
  }
}

In JSP Code-
<%@ include file="/libs/foundation/global.jsp" %><%
%><%
    String siteTitle = request.getParameter("siteTitle");
    String websiteLink = request.getParameter("websiteLink");
%>
<html>
    <head>
        <title>
            <%= xssAPI.encodeForHTML(siteTitle); %>
        </title>
    </head>
    <body>
        <a href="<%= xssAPI.getValidHref(websiteLink); %>">Website Link</a>
    </body>
</html>

B.
Sightly takes care of XSS prevention itself by virtue of it's framework architecture. This means that all HTML values and attributes are subject to XSS check before they are rendered by server. If you have to explicitly bypass this restriction then you need to use context="unsafe". But be very careful when you decide to do that beacause it disables escaping and XSS protection completely for the applied element which can cause security issues.

2. Server Level Protection

A web application firewall, such as mod_security for Apache should be used/ configured on dispatcher to make it more reliable.

Following rules may come handy to you in security.conf at your dispatcher-

# Disable cross site scripting

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(<|%3C).*script.*(>|%3E).*
RewriteRule .* /errors/404.html
RewriteRule .* - [F]

# Disable SQL Injection

RewriteCond %{QUERY_STRING} ^.*(localhost|loopback|127\.0\.0\.1).*    [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\*|;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|).*(/\*|
union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC]
RewriteRule ^(.*)$ - [F,L]

# Disable Clickjacking

Header always append X-Frame-Options SAMEORIGIN

# Disable unwanted HTTP Methods

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE [NC]
RewriteRule .* - [F]
RewriteCond %{REQUEST_METHOD} ^TRACK [NC]
RewriteRule .* - [F]
RewriteCond %{REQUEST_METHOD} ^DELETE [NC]
RewriteRule .* - [F]
RewriteCond %{REQUEST_METHOD} ^OPTIONS [NC]
RewriteRule .* - [F]
RewriteCond %{REQUEST_METHOD} ^PUT [NC]
RewriteRule .* - [F]
Sources:
1. https://docs.adobe.com/docs/en/aem/6-0/administer/security/security-checklist.html
2. http://tostring.me/270/how-to-prevent-cross-site-scripting-xss-attack-on-your-adobe-cq-based-web-application/

1 comment:

  1. Nice article on the cross frame scripting protection, the coding, the screen shots and images given are very well and easy to understand.

    ReplyDelete

CDN | Clearing Cloudflare cache

In order to clear Cloudflare cache automatically via code, follow below steps: 1. Develop Custom TransportHandler Develop a custom Trans...