JavaScript: The Good Parts Part Ten: ADsafe

1
JavaScript The Good PartsPart Ten ADsafe

• Douglas Crockford
• douglas_at_crockford.com

2
ADsafe

• A system for safe web advertising.
• http//www.ADsafe.org/

3
ADsafe is a safe subset of JavaScript.Static
validation only, no code rewriting.

• No impact on performance.
• JSLint is an ADsafe validator.

4
ADsafe

• ADsafe is a JavaScript subset that adds
  capability discipline by deleting features that
  cause capability leakage.
• No global variables or functions may be defined.
• No global variables or functions can be accessed
  except the ADSAFE object.
• Use of the subscript operator is limited.
• These words cannot be used apply arguments call
  callee caller constructor eval prototype this
  unwatch valueOf watch
• Words starting with _ cannot be used.

5
Impact on the programming model

• Use of for subscripting is extremely limited.
  ADSAFE.get(name) and ADSAFE.set(name, value) may
  be used instead. This can be annoying.
• this cannot be used because it can be made to
  bind to the global object.
• JavaScript is still quite useable without this.

6
Constructor Recipe

• Make an object.
• Object literal
• new
• Object.create
• call another constructor

7
Constructor Recipe

• Make an object.
• Object literal, new, Object.create, call another
  constructor
• Define some variables and functions.
• These become private members and private methods
  of the new object.

8
Constructor Recipe

• Make an object.
• Object literal, new, Object.create, call another
  constructor
• Define some variables and functions.
• These become private members.
• Augment the object with privileged methods.

9
Constructor Recipe

• Make an object.
• Object literal, new, Object.create, call another
  constructor
• Define some variables and functions.
• These become private members.
• Augment the object with privileged methods.
• Return the object.

10
Step One

• function myConstructor(x)
• var that otherMaker(x)

11
Step Two

• function myConstructor(x)
• var that otherMaker(x)
• var secret f(x)

12
Step Three

• function myConstructor(x)
• var that otherMaker(x)
• var secret f(x)
• that.priv function ()
• ... secret x ...
• The methods should use neither this nor that.

13
Step Four

• function myConstructor(x)
• var that otherMaker(x)
• var secret f(x)
• that.priv function ()
• ... secret x ...
• return that

14
Objects made with this pattern do not need
hardening.

• Object tampering does not cause confusion.

15
ADsafe does not allow access to Date or random

• This is to allow human evaluation of ad content
  with confidence that behavior will not change in
  the future. This is for ad quality and
  contractual compliance, not for security.

16
ADsafe DOM Interface

• Light weight.
• Query-based.
• Scope of queries is strictly limited to the
  contents of a the widget's ltdivgt.
• Guest code cannot get direct access to any DOM
  node.

17
Widget Template

• ltdiv id"ADSAFEID_"gt
• HTML content goes here.
• ltscriptgt
• "use strict"
• ADSAFE.id("ADSAFEID_")
• lt/scriptgt
• ltscript src"approvedlibrary.js"gtlt/scriptgt
• ltscriptgt
• "use strict"
• ADSAFE.go("ADSAFEID_", function (dom, lib)
• Application initialization goes here.
• )
• lt/scriptgt
• lt/divgt

18
Library Template

• "use strict"
• ADSAFE.lib("libraryname", function ()
• Create that library object
• return that
• )
• The widget accesses the library object with
  lib.libraryname.

19
ADsafe validation is not destructive, so it can
be performed at any and every point in the ad
delivery pipeline.

• It can even be done after consumer delivery to
  test compliance.

20
Multiple points of validation provide greater
confidence that bad content will be blocked.
21
Dangers

• There may still be undiscovered weaknesses in
  ECMAScript and its many implementations.
• Those implementations are changing, introducing
  new weaknesses.
• The wrappers must be flawless.
• We are still subject to XSS attacks.

22
What can an attacker do if he gets some script
into your page?
23
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.

24
An attacker can read the document.

• The attacker can see everything the user sees.
  And hidden fields, cookies, referrer, scripts, ...

25
An attacker can make requests of your server.

• Your server cannot detect that the request did
  not originate with your application.

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

27
An attacker can send information to servers
anywhere in the world.

• The Same Origin Policy does not limit the
  attacker's ability to transmit stolen information.

28
These are just the vulnerabilities that are
required by web standards.

• In addition to these, there are bugs, ActiveX,
  Flash, Extensions...

29
ltiframegts are not a solution

• ltiframegt also have too much capability.
• An evil ltiframegt can navigate the whole page.
• This can confuse users, exposing them to harm.
• Violation of trust.

30
Purchasing of ads is becoming a more cost
effective phishing attack than spam.
31
The consequences of a successful attack are
horrible.

• Harm to customers.
• Loss of trust.
• Legal liabilities.

32
This is not a Web 2.0 problem.

• All of these problems came with Netscape 2 in
  1995.

33
We must fix or replace the browser.

• This will take a long time.
• Our problems are immediate.
• Our opportunities are immediate.

34

• Deep inside of JavaScript there is a good
  programming language.

35
A secure subset requires no new browser
technology.

• It will work on all current browsers.
• Enable secure applications to run in an insecure
  language in an insecure browser on an insecure
  operating system.

36
Safe JavaScript Subsets

• Security is a not a feature that can be added.
• Instead, we remove insecurity.
• If we remove all of the insecurity from
  JavaScript, we are left with a secure programming
  language.
• Only guest code must conform to the subset.
  Trusted code has access to the entire language.

37
Object Capabilities

• Object Oriented Security

38
Two Approaches

• Verification
• ADsafe
• No modifications.
• Disallows definition of public methods.

• Transformation
• Caja
• Inserting runtime checks.
• Allows definition of public methods

39
Operation

• ADsafe
• Validation can be performed at every step in the
  pipeline.
• Validation can be used to audit the code quality
  of delivered ads.

• Caja
• Transformation must be performed exactly once.
• Once transformed, it is difficult to determine if
  it was transformed correctly.

40
Debugging

• ADsafe is easier to debug because the source is
  not modified.
• Performance of ADsafe programs is more
  predictable.
• The ADsafe transformation does not degrade
  performance because there is no transformation.

41
Prevent Global Access

• A Safe JavaScript Subset prevents direct access
  to the global object and global variables.
• Global variables are evil.
• Access to the DOM must also be restricted.

42
The ADSAFE Object

• The page exposes an ADSAFE object to the guest
  code.
• It provides a safe API.
• Guest code can execute ADSAFE methods.
• Guest code cannot copy from or modify the ADSAFE
  object.
• The page can expose other objects, such as a YUI
  object.

43
Wrapping the DOM

• Guest code must not be allowed direct access to
  DOM elements.
• Access to any element gives access to every
  element and to the network.
• No access to document, especially document.write.
• No dynamic ltscriptgt tags.
• Static ltscriptgt tags must fetch from a source
  that goes ADsafe verification.

44
ADsafe

• A JSLint option. http//JSLint.com/
• It defines a safe HTML/JavaScript subset.
• Removes from JavaScript all features that are
  unsafe or suspect.
• Allows ads and widgets to safely interact.
• Better code quality.

45
An ADsafe verifier can be written in 30K of
JavaScript.

• Ajax ad delivery is possible.

46
ADsafe can also be used to make safe widgets and
mashups.

• Use module pattern and functional inheritance.

47
Limitations

• A safe subset can protect the page from guest
  code, but it cannot protect guest code from the
  page.
• Currently, the browser allows little
  technological defense against a page that
  practices click fraud and other abuses.
• That will require a new browser.

48
Safe JavaScript Subsets are at best an Interim
Solution.

• Meanwhile, we still must fix the browser.

49
The JSLint/ADsafe verifier is available now.