Ajax Security - Douglas Crockford's Javascript
Download
Report
Transcript Ajax Security - Douglas Crockford's Javascript
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/
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 wouldn't 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 constructor eval
new prototype this 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.
A
Object A has
state and
behavior.
has-a
A
B
Object A has a
reference to
Object B.
An object can have
references to other
objects.
Object A can
communicate
with Object B...
A
...because it has
a reference to
Object B.
B
A
Object B
provides an
interface that
constrains access
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
In an Object Capability
System, an object can
only communicate with
objects that it has
references to.
B
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 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 to
be delivered.
• Don't take ineffective measures.
Be Rigorous
• Sloppiness aids the Enemy.
• Neatness counts.
• Use good encoders.
• Avoid concatenation.
• Be paranoid.
Turducken