Ajax Security

Document Sample
Ajax Security Powered By Docstoc
					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:
  &lt;script>alert("XSS");&lt;/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 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

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:2518
posted:5/7/2008
language:English
pages:70