Ajax Security Douglas Crockford Yahoo! javascript.crockford.com/security.ppt
Ajax Security Douglas Crockford Yahoo! javascript.crockford.com/security.ppt.
Mar 26, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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
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
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.
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
Related Documents
