freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Van Gundy <>
Subject Auto-Sanitization for FreeMarker
Date Tue, 15 Mar 2016 15:03:57 GMT
Hi dev@freemarker,

Cross-Site Scripting (XSS) vulnerabilities are embarrassingly common in
web applications.  A few of us in the Cisco Advanced Security
Initiatives Group have extended FreeMarker to support context-sensitive
auto-sanitization in order to automatically detect and prevent
Cross-Site Scripting vulnerabilities.  We would like to contribute our
improvements back to the open-source community.  As part of that
process, we'd like to solicit your feedback about whether and under what
conditions FreeMarker might be willing to integrate our changes or if it
would be better to maintain a fork that attempts to retain compatibility
and feature parity with FreeMarker.

Our modified FreeMarker:

* Precisely tracks the flow of untrusted data through the FreeMarker

* Tracks the current parsing context of an HTML5-compliant browser

* Automatically sanitizes untrusted data correctly for the enclosing
  HTML/JavaScript/CSS context where the data is to be embedded

* Detects manually-sanitized data and avoids over-sanitization as long
  as the manually-applied sanitization is safe for the enclosing web
  page context

For example, given the template:

Hello ${email}!
<button onclick="signin('${email}')">

When rendered with email = "<script>pwn()</script>" the result will be:

Hello &lt;script&rt;pwn()&lt;/script&rt;!
<button onclick="signin('&lt;script&rt;pwn()&lt;/script&rt;')">

When rendered with email = "'+ pwn() +'" the result will be:

Hello '+ pwn() +'!
<button onclick="signin('\'+ pwn() +\'')">

In both cases, whenever untrusted data is embedded into a web page, it
is sanitized safely and correctly for the enclosing context.  Our
approach was inspired by Closure Templates [1] and Samuel, Saxena, and
Song's CCS 2011 paper on Context-Sensitive Auto-Sanitization [2] with
the caveat that our system does not perform static analysis, it is
runtime only.

As a runtime-only approach, there is a performance impact.  In our
current benchmarks, data flow tracking alone incurs a 1.6x slowdown
while full context-sensitive auto-sanitization (including data flow
tracking) incurs a 2x slowdown.

Precise data flow tracking requires all string operations in the
FreeMarker engine to be instrumented.  It is not possible to allow data
flow tracking to be enabled/disabled on demand without extensive
refactoring.  As a result, the 1.6x slowdown due to data flow tracking
is always present in the current implementation.  To mitigate this for
applications that cannot incur a 1.6x slowdown in template rendering, we
provide an API-compatible replacement for freemarker.jar which can be
used during testing.  In this use case, our system provides a
verification that manual sanitization has been applied correctly for all
test cases seen during the normal dev-test cycle.

We would like your opinions on whether and under what constraints,
FreeMarker would be interested in adopting these changes.  Would
FreeMarker be interested in offering a context-sensitive auto-sanitizing
branch which maintains feature parity with the main release but provides
additional safety for a performance cost?  If extensive refactoring
could allow data flow tracking and auto-sanitization could be
selectively enabled, would FreeMarker be willing to integrate those
changes?  Or, would releasing a separate project be the preferred route?

Thank you for all of your hard work creating an excellent tool.  We
appreciate any feedback you may have.



Matthew Van Gundy, Technical Leader
Advanced Security Initiatives Group
Cisco Systems, Inc.

View raw message