Ajax Security

On? Is This

Ajax Security Douglas Crockford Yahoo! javascript.crockford.com/security.ppt

Security The number 1 biggest problem with the whole World Wide Web.

The browser is not a safe programming environment. It is inherently insecure.

What can an attacker do if he gets some script into your page?

An attacker can request additional scripts from any server in the world. Once it gets a foothold, it can obtain all of the scripts it needs.

An attacker can make requests of your server. Your server cannot detect that the request did not originate with your application.

An attacker can read the document. The attacker can see everything the user sees.

An attacker has control over the display and can request information from the user. The user cannot detect that the request did not originate with your application.

An attacker can send information to servers anywhere in the world.

The browser does not prevent any of these. That's why they happen.

The consequences of a successful attack are horrible. Harm to customers. Loss of trust. Legal liabilities. Possible criminal penalties.

This is not a Web 2.0 problem. All of these problems came with Netscape 2 in 1995.

The Turducken Problem
Many Languages:
HTTP, HTML, URL, CSS, JavaScript, XML, JSON, plaintext, SQL...
Each language has different quoting and commenting conventions.
The languages can be nested inside each other.

A text that is benign in one context might be dangerous in another. Sloppy encoding allows injection of evil scripts

A Simple Attack
http://yourdomain.com/
<script>alert("XSS");</script>
<html><body>
<p>File not found: <script>alert("XSS");</script>
</p></body></html>
The script runs with the authority of your site.

A Simple Attack
http://yourdomain.com/
<script>alert("XSS");</script>
<html><body>
<p>File not found: < script>alert("XSS"); < /script>
</p></body></html>
Proper escapement provides some safety.

Another Example
Bad text
" + alert("XSS") + "
Bad encoding
{"json": " " + alert("XSS") + " "}
Good encoding
{"json": " " + alert( "XSS ") + " "}

Coding hygiene is critical for avoiding turducken attacks. Use good encoders. json.org/json2.js Do not use simple concatenation. Never trust the browser. Validate all input.

Cross Site Data Access It is extremely useful to obtain data from other sites and mash it up.

Same Origin Policy Prevents useful things. Allows dangerous things.

Script Tag Hack
Scripts (strangely) are exempt from Same Origin Policy.
A dynamic script tag can make a GET request from a server.
receiver( jsontext );
Extremely dangerous. It is impossible to assure that the server did not send an evil script.

JavaScript's Global Object The root cause of XSS attacks. All scripts run with the same authority.

JavaScript is an insecure language. The ES4 Proposal is even worse. It should be abandoned.

Document Object Model All nodes are linked to all other nodes and to the network.

Cookies Ambient authority leads to confusion and impersonation (XSRF)

Remedy: Crumbs An explicit secret should be sent with the ambient cookie. Frustrates XSRF attacks. Not effective against XSS attacks.

Excellent Code Quality If code is clean and readable, it is less likely to contain insecurities.

JSLint
JSLint defines a professional subset of JavaScript.
It imposes a programming discipline that makes me much more confident in a dynamic, loosely-typed environment.
http://www.JSLint.com/

W arning! JSLint will hurt your feelings.

If the web as been totally screwed up from the beginning, why should we worry about it now? 1. Escalating legal penalties 2. Mashups 3. Competition

Mashups The most interesting innovation in software development in 20 years.

Mashups are insecure. Mashups must not have access to any confidential information.

If there is script from two or more sources, the application is not secure. Period.

Advertising is a mashup.

Competition to displace the web. Silverlight. AIR. JavaFX.

That would'nt be the end of the world. It would just be the end of the WWW.

A Three Prong Strategy to Fix the Web
Safe JavaScript subsets.
Small browser improvements.
Massive browser improvements.
This could take a while, so we should proceed on all three immediately.

1. Safe JavaScript Subsets. The easiest way to improve JavaScript is to make it smaller.

ADsafe
A JSLint option.
It defines a safe HTML/JavaScript subset.
Removes from JavaScript all features that are unsafe or suspect.
Allows foreign ads and widgets to safely interact.

ADsafe
No global variables or functions may be defined.
No global variables or functions can be accessed except the ADSAFE object.
The [] subscript operator may not be used.
These words cannot be used: apply call callee caller clone constructor eval new prototype source this toSource toString watch
Words starting with _ cannot be used.

Dangers
There may still be undiscovered weaknesses in ECMAScript and its many implementations.
Browser implementations are changing, introducing new weaknesses.
The DOM wrappers must be flawless.
We are still subject to XSS attacks.

2. Add Simple Features to the Browsers. Even simple improvements can take a long time to distribute.

JSONRequest for safe data interchange.

Vats Communicating computational containment vessels

HTML Provides No Modules
It was conceived to be a document format.
We are using it as an application format.
Applications requires modules.
Modules protect their contents.
Modules communicate by exposing clean interfaces.

Vats
Adapting Google's Gears or Adobe's AIR to provide communicating containment.
Provides cooperation under mutual suspicion.
Heavyweight.
Distribution is difficult.
Still subject to XSS attacks.

3. We need to replace JavaScript and the DOM. As long as we are using insecure languages, we will be subject to XSS attacks.

Start with the ADsafe subset, and then carefully add features to enhance expressiveness.

A is an Object. Object A has state and behavior.

has-a Object A has a reference to Object B. An object can have references to other objects.

...because it has a reference to Object B. Object A can communicate with Object B...

Object B provides an interface that constrains access to its own state and references. Every object is a micro vat.

Object A does not have a reference to Object C, so Object A cannot communicate with Object C. In an Object Capability System, an object can only communicate with objects that it has references to.

An Object Capability System is produced by constraining the ways that references are obtained. A reference cannot be obtained simply by knowing the name of a global variable or a public class.

There are exactly three ways to obtain a reference.
By Creation.
By Construction.
By Introduction.

1. By Creation If a function creates an object, it gets a reference to that object.

2. By Construction An object may be endowed by its constructor with references. This can include references in the constructor's context and inherited references.

3. By Introduction A has a references to B and C. B has no references, so it cannot communicate with A or C. C has no references, so it cannot communicate with A or B.

3. By Introduction A calls B, passing a reference to C.

3. By Introduction B is now able to communicate with C. It has the capability .

Weaknesses to avoid include
Arrogation.
Corruption.
Confusion.
Collusion.

There is no security in obscurity Tricks and puzzles are not effective. Speed bumps are not effective.

False security increases the danger. Ineffective measures make things worse.

The security problems are not new. The problems are getting harder to ignore.

Ultimately
We need to replace JavaScript with a secure language.
The current ES4 proposal is not that language.
We need to replace HTML and the DOM with a secure application delivery system.
The current HTML5 proposal is not that either.

Ultimately
Secure programming language to replace JavaScript.
A modular application framework to replace the DOM and CSS.
A common text representation and protocol to replace HTTP and the Ajax stack.
Otherwise, the web may fall to newer proprietary systems.

Meanwhile
Never trust the browser.
Formally validate everything you receive from the browser.
Properly encode everything you send to the browser or database.
Do not circumvent what little security the browser offers.
Never put data on the wire unless you want it ot be delivered.
Don't take ineffective measures.

Be Rigorous
Sloppiness aids the Enemy.
Neatness counts.
Use good encoders.
Avoid concatenation.
Be paranoid.

Turducken

http://www.webdirections.org	1559
http://www.coderholic.com	272
http://www.slideshare.net	18
http://www.dowling.me.uk	12
http://all-for-women.com	4
http://static.slideshare.net	3
http://localhost	1
http://www.techgig.com	1
file://	1
http://192.168.10.100	1
http://soapbox.gruden.com	1
http://surf.googlemashups.com	1
http://translate.yandex.net	1

Ajax Security

by Douglas Crockford on Feb 06, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

13 Embeds 1,875

Statistics

Ajax Security — Presentation Transcript