Ajax Security

Document Sample
Ajax Security
Shared by: Serendipity1
Stats
views:
2436
posted:
5/7/2008
language:
English
pages:
70
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/

alert("XSS");







File not found:

alert("XSS");







• The script runs with the authority of your site.

A Simple Attack

http://yourdomain.com/

alert("XSS");







File not found:

<script>alert("XSS");</script>







• 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/

Warning!

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



1. Safe JavaScript subsets.

2. Small browser improvements.

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

A state and

behavior.

has-a



A





B

Object A has a

reference to An object can have

Object B. references to other

objects.

Object A can

communicate

with Object B...

A





B

...because it has

a reference to

Object B.

Object B

provides an

interface that

constrains access

A

to its own state

and references.

B









Every object is a micro vat.

Object A does not have a reference to

Object C, so Object A cannot

communicate with Object C.



A





B

In an Object Capability

System, an object can

only communicate with

objects that it has

C

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.



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



A





C B

3. By Introduction



A calls B, passing a reference to C.





A





C B

3. By Introduction



B is now able to communicate with C.



A





C B







It has the capability.

Weaknesses to avoid include

1. Arrogation.

2. Corruption.

3. Confusion.

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


Share This Document


Related docs
Other docs by Serendipity1
Social Bookmarking: A New Type of Search
Views: 705  |  Downloads: 40
Creative Stairs
Views: 4040  |  Downloads: 18
Faster Web Sites
Views: 713  |  Downloads: 37
Scary Lightnings
Views: 596  |  Downloads: 12
Tips for writing a paper
Views: 495  |  Downloads: 46
Internet History and Growth
Views: 629  |  Downloads: 21
Oldtimers Planes
Views: 8725  |  Downloads: 12
Scary Clowns
Views: 16509  |  Downloads: 19
Life in a Wood Ball
Views: 1199  |  Downloads: 3
Pope Benedict
Views: 137  |  Downloads: 0
by registering with docstoc.com you agree to our
privacy policy

You are almost ready to download!

You are almost ready to download!