Opa Trustworthiness Attributes

Mathieu Baudet & Henri Binsztok, MLstate

Opa safety, security and privacy properties

The Opa technology provides unique verfication systems that contribute totrustworthiness of Opa-built applications by providing automatically severaltrusthworthiness attributes. Such attributes can be divided in two segments:

• Infrastructure support, which are attributes passed to end-users of Opa-built products;

• Developer-level support, by assisting applications developers in makingbetter products.

The case of one attribute, prevention of XSS attacks, is detailed in a secondsection.

Infrastructure support

• Enforcing of sanitization of user inserts, preventing XSS attacks• Compilation of links between server components• Static anaylisis of database queries• Resistance to SQL injections• Resistance to XQuery/XPath injections• Resistance to SSI injections• Resistance to OS Commanding• Resistance to Path Traversal or Remote File Inclusion• Mitigation of Predictable Resource Location attacks• Control of the Trusted Computing Base• Resistance to Null Byte Injections• Safety with respect to numerous low-level attacks such as Buffer Over-

flows/Underflows, Uncontrolled Format Strings bugs

Developer-level support

• Strong static typing

1

• Proper identification of temporary information (sessions)• Prevention of deadlocks• Ability to properly identify private data• Structural typing with Polymorphic Extensible Records and type-safe

Unions• Prevention of Insufficient Authentification attacks

Roadmap

• DoS and DDoS

The case of XSS

Problem Description

The first step to preventing XSS attacks is knowing when you need to protectyourself. XSS can only be triggered when it is displayed within HTML content,sometimes via a form input or being displayed from database results. Any globalvariable that contains client information can be tainted.

The OWASP Cheat Sheet details the rules to follow to guard web applicationsagainst XSS.

For instance for PHP, developers have to:

• use strip_tags to remove all unwanted HTML tags from a value• use HTML cleaning tool such as HTML Purifier or HTML Tidy• always escape data when inserting into HTML, including script and

stylesheet links, anchors, images, and email (mailto) links.

The problem lies in the fact that these checks over lengthy application can becumbersome and developers will forget some of the checks, leaving an open doorto vulnerabilities.

Opa Approach

Opa is a language with built-in features for web programming. Opa is strongly-typed and compiles the same source code both to javascript and to native servercode. This uniformity allows typing objects consistently between clients andservers.

The typechecker of Opa distinguish string values and HTML values everywherein the application:

2

• String values are considered untrusted by default, in the sense that insertingthem into a HTML (or URI) context will trigger the appropriate escapingfunction by default.

• HTML values are considered trusted, i.e. ready to be inserted into theDOM. Yet, HTML values serialized from browsers to web servers aresubject to restrictions: if needed, dangerous nodes will be removed atruntime.

As a result of this strong policy, we claim that regular Opa applications arenot vulnerable to XSS attacks, unless the programmer explicitly “codes” them:either by using a visibly unsafe primitive, or by constructing dangerous HTMLvalues on purpose.This is done without requiring programmers to distinguish between several typeof value insertions (say, escaped and not escaped).

Example

To illustrate the way Opa applications are programmed and transparently pro-tected against XSS attacks, let us consider the following code example:

function page() {<div><input id="input"></input><button onclick={ function (_) {

value = Dom.get_value(#input);roundtrip_setvalue(value)

}}>Ok</button><p id="display"/></div>

}

server //force server-side evaluationfunction roundtrip_setvalue(string value) {

Log.info("Test", "I’m on the server");#display = <div>{value}</div>;

}

Server.start(Server.http, { page: page, title: "Test" })

Here we have written a simple application where a formular posts a string valueto the server. The string is then inserted in some HTML value and sent backto update the DOM. Although no XSS protection is explicitly involved, thisapplication resists code injection in the input field.Indeed, automatic escaping happens while evaluating in the expression:

3

Figure 1: There is no XSS attack in this very simple, apparently not protected,application

4

<div>{value}</div>

Here, at compile time, the type system has detected the need for inserting astring into a HTML structure in content position. Therefore, the HTML escapingfunction is automatically trigerred at runtime.

Security Challenges

Next, we review 4 web security challenges inspired by the paper “A System-atic Analysis of XSS Sanitization in Web Application Frameworks” from ES-ORICS’2011.

Context Sensitivity

The previous example above shows how to trigger the function for XHTMLescaping. In Opa, other escaping functions might be triggered as well, dependingon the position of the insertion into the XHTML syntax.

For instance, we may write the following code that triggers URI escaping:

<a href="http://myserver.com/{object}">This is a link</a>

The key ingredient that makes it work easily in Opa is that the XHTML sent byOpa servers is constructed by compiling first the corresponding language syntaxinto a typed abstract syntax tree(AST). During the evaluation of such ASTs,the right escaping function is applied to each kind of unsafe node without needfor complex context inference.

Similar techniques were also advocated by Robertson et al. in designing aweb framework for Haskell: “Static Enforcement of Web Application IntegrityThrough Strong Typing”. However, this kind of techniques had been reserved tothe language Haskell so far.

Nested Contexts and Browser Transduction

Although the source code may nest active code and XHTML, the Opa compilerwill never generate multiple or nested contexts: e.g. Javascript expressions areeither included in resources of type “text/javascript”, or rewritten outside theXHTML in CDATA sections.

Consider for example the following template:

5

<html><head/><body><h1 onclick=’window.console.log("while logging..{{$in}}")’>

Click here</h1></body></html>

where {{$in}} is meant to be interpreted by a given web framework with safeXHTML escaping. Assume that the variable $in takes its value from a untrustedclient which chooses the value:

" + alert("You have been hacked ")+ "

After escaping and insertion, this XHTML templated will typically result in thebrowser evaluating the following string:

<h1 onclick=’window.console.log("while logging..&quot; +alert(&quot;You have been hacked &quot;)+ &quot;")’>Click here</h1>

Unfortunately, the substrings &quot; are going to be interpreted back to " bythe browsers, hence resulting in the following well-formed command to be sentto javascript and executed:

window.console.log("while logging.." + alert("You have been hacked ")+ "")

To the contrary, the code below in Opa does not exhibit this unsafe behaviour:

in = "\" + alert(\"You have been hacked \")+ \""function page() {<h1 onclick={ function (_) {Log.info("Test", "while logging..{in}") }}>Click here</h1>}Server.start( Server.http, { page: page, title: "Test" } )

Indeed, the previous code is compiled into the following (with simplifications inJS and XHTML for better readability):

<html><head>

<title>Test</title></head><body id="Body"><h1 id="bghnjixgjpbbvpaltdzftuypivkwtivu">Click here</h1>

6

<script src="/_internal_/18674014a9ac285473752e7a21d08cf6/code/all.js"type="text/javascript"></script>

<script type="text/javascript">//<![CDATA[$(’#bghnjixgjpbbvpaltdzftuypivkwtivu’).opachbind(’click’, (function(event){window.console.log(

"\" + alert(\"You have been hacked\")+ \"")}))//]]></script></body></html>

We can observe that the onclick action is installed afterwards by a side effecton the DOM. Note that no XHTML escaping occurred during the evaluation ofwhile logging..{in} because this insertion concerns strings only. (However,escaped chars \" were correctly restored while printing Opa strings into Javascriptstrings.)

Dynamic Code Evaluation

Opa is strongly typed (a fortiori there’s no eval). Commands to availabledatabase engines (Opa-DB, Mongo, Couch) are dynamically or statically typeddepending on the chosen API. Note that in the case of dynamically typedcommands, the corresponding objects are still structured objects (not strings)whose serialization inserts proper escaping characters.

Character-set Issues

In Opa, strings are all UTF-8 by default. This choice prevents inconsistenciesbetween programmers’ code and HTML headers, that may result in XSS attacks.

Conclusion on XSS Attacks

we claim that the design of Opa solves the problem of XSS in a simple way wheremany web frameworks presently fail:

• Opa XSS protection is transparent (cannot be forgotten)• Calls to the proper escaping functions are added at the insertion point ac-

cording to precise type information (no need for complex context analyses)• XSS protection is added at compile-time in a simple and documented way

(experts can still play with it if they know what their doing).

7