douglas crockford - ajax security

Web

Forward!

Douglas Crockford

Yahoo!

Gordon E. Moore

The complexity for minimum component costs has increased at a rate of roughly a factor of

two per year ... Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not

remain nearly constant for at least 10 years.

1965

Moore's prediction became a self-fulfilling

prophesy.It cannot hold forever,

but it is still holding now.

Processors, memory, disk storage, network

bandwidth.Everything except software.

Software is not subject to Moore's Law.

Software is subject to Murphy's Law.

Software productivity improves at a much

slower rate.Doubling in 10-20 years,

rather than 2 years.

Great Leaps of Software

• Plug boards.

• Machine codes.

• Symbolic assembly language.

• High level languages.

• Structured programming.

• Object oriented programming.

The next leap is overdue.

Object oriented milestones:

1967 Simula 1980 Smalltalk 80 1995 Java

The next great leap might realize the dream of

assembling software like Lego.

• Applications can be built by putting together components, each produced at an independent foundry.

• Components communicate, cooperate with each other.

Mashups!JavaScript is the mashup

language!

It is better suited to dynamic mashing than the conventional OO

languages.

Unfortunately...

The Web Is Under

Attack!

Browser Security

• The biggest problem with the browser is its security model.

• The browser security model is inadequate to deal with the current generation of Ajax applications.

• The browser was not designed to do the things we are asking of it.

• Its weaknesses are blocking innovation.

The browser is not a safe programming environment.

It is inherently insecure.

What can an attacker do when 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.

The vulnerabilities are required by Web

Standards.The consequences of

standard behavior, not bugs.

“and God gave us the Web Standards, and deviation from the Web Standards is the source of All Evil!”

There is no truth in that statement.

The web was once a driver of innovation.

The web is now the obstacle of innovation.

Web development requires mastery of the workaround.

You can't work around security.

If there is script from two or more sources, the application

is not secure.

A mashup is a self-inflicted XSS attack.

Confusion of Interest

Computer

System Mode

Confusion of Interest

System

System Mode

User

Confusion of Interest

System

System Mode

User User User

Confusion of Interest

CP/M MS-DOS MacOS Windows

System Mode

Confusion of Interest

System ModeThe System cannot distinguish the

interest of the user from the interest of any program. This enables floppy-

borne viruses.

Confusion of Interest

System Mode

When networking is introduced, network-borne viruses are enabled.

User

Confusion of Interest

Browser

System Mode

Site Site Site

The browser is a significant improvement, able to distinguish the interests of users and sites (in some

cases).

But within a page, interests are confused.

An ad or a widget or an Ajax library gets the same rights

as the site's own scripts.

JavaScript got close to getting it right.

Except for the Global Object. And some other bad parts.

It can be repaired, becoming an object capability language.

An Introduction toObject Capabilities

A is an Object.

Object A has state and behavior.

A

Object A has a reference to

Object B.

A

B

An object can have references to other

objects.

has-a

...because it has a

reference to Object B.

Object A can communicate with Object

B...A

B

Object B provides an

interface that constrains

access to its own state and

references.

A

B

Object A does not get access to Object B's

innards.

Object A does not have a reference to Object C, so Object A cannot communicate with Object

C.

A

BIn an Object

Capability System, an object can only

communicate with objects that it has

references to.

C

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.

1. By Creation.

2. By Construction.

3. 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

BC

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

BC

A calls B, passing a reference to C.

3. By Introduction

A

BC

B is now able to communicate with C.

It has the capability.

If references can only be obtained by Creation,

Construction, or Introduction, then you may have a safe

system.

If references can be obtained in any other way, you do

not have a safe system.

Good Object Capability Design

is

Good Object Oriented Design

Short term fixes

• Safe JavaScript subsets can offer some safety now.

Caja, Cajita, ADsafe.

• Progress is also being made in Vat architecture.

A vat is a leak-proof computing vessel.

Capabilities can be used to allow communication between vats.

Browser plugins, Google Gears.

Three Possible Solutions

• Safe JavaScript subsets.

Timeframe: Immediate

• Communicating Vats.

Timeframe: Intermediate

• Secure Programming Language.

Timeframe: Distant

• All of the Above.

How Do We Move the Web Forward?

Browser

War!Never again.

The Web Depends on Standards

• Openness is hugely attractive.

• The standards are bad.

• In order to change the web, we must change its standards.

A revision to a standard is an act of violence.

Surgery.

Pain. Injury. Inconvenience.

Users of web standards cannot opt out.

Not only are the web's standards broken, the

web's standards process is broken.

Design by Committee.

Porkbarrel standards making.

Minimalism should be highly valued in

standards.Committees are not good

at minimalism.

The standards process is entertaining too much speculative technology.

ECMAScript's Close Call

ECMAScript

• The ES4 Proposal contained a lot of pork.

• It lacked a credible value proposition.

• The design progress went years over schedule.

• ES4 was ultimately abandoned.

• Instead, the modest ES3.1 Proposal brings the standard more inline with reality.

• It adds a small set of necessary features.

A standards process must be risk averse.

Once an error gets into a standard, it can be virtually

impossible to get it out.

The Dilemma:

Good Standards happen slowly and our need is urgent.

The web standards are currently frustrating progress and

endangering everyone who uses the web.

Web Time used to mean

really fast.

ECMAScript 3: 1999.

HTML 4.01: 1999.

Browser

War!We need a Browser War!

The only thing worse than where we were

is where we are.

Bring It On

• It turns out that Browser War is a good thing.

• It introduces chaos into the marketplace.

• Most of the cost of that chaos is borne by web developers and users.

• The market is generally better than self-selected committees in determining the value of things.

The marketplace must be more effective this time in

punishing bad behavior.

Yahoo!’s Graded Browser Support Program

This Site Requires Netscape 3

Innovation should happen in research laboratories,

startups, and forward-looking companies.

Not in Standards bodies.

Standards should have a conservative process that

documents the best of what has been proven useful.

The drafting of standards is difficult, important

business.

Standards should not be inventions.

Standards should be agreements.

Standards should work.

We should also be looking past the Web.

The web was a disruptive technology.

The Web needs to be disrupted.

I’ll see you in the

trenches!