JavaScript: The Good Parts Part Seven: Security

1
JavaScript The Good PartsPart Seven Security

• Douglas Crockford
• douglas_at_crockford.com

2
The SAMY Saga

• MySpace (2005)

3
In a week Samy learned

• How to hide JavaScript in a URL in CSS.
• How to generate MySpace crumbs.
• How to submit a message to MySpace to update the
  friends list.
• How to submit a message that contains a script
  that sends a message containing a script.

4
But most of all, Samy is my hero

• Within 20 hours, his script was in one million
  accounts.
• He immediately stepped forward because he
  intended no harm.
• He was charged with a felony.
• Three years probation.
• 90 days community service.
• Banned from the internet.

5
Security

• The number 1 biggest problem with the whole World
  Wide Web.

6
The browser is not a safe programming environment.

• It is inherently insecure.

7
Security is a big issue.

• The web is an exploit waiting to happen.

8
Same Origin Policy

• Intended to defend sites from each other.
• Inconsistently applied.
• Script tags are exempt.
• The Origin of the Same Origin Policy Netscape 2
  included frames and JavaScript.
• Oops.

9
Prevent useful things.Allow dangerous things.

• Same Origin Policy

10
The Web Is Underspecified

• Much of the browser's functionality is not
  defined by any standard.
• The standards require unsafe constructions.
• The standards are interpreted very differently by
  the many implementations, often with diverging
  security vulnerabilities.

11
Insecure Network

• Millionaire computers and ARPA contracts.

12
WWW had no security model

• Unless you think that passwords embedded in URLs
  and sent in the clear is a security model

13
They had the wrong threat model

• "Nobody would ever do that."

14
Security architecture in the web was reactive

• After an exploit was detected, a patch was added

15
Marginal Security

• Security is sometimes obtained, but surprises can
  occur.

16
Cookies

• Cookies were not designed to be an authentication
  mechanism.
• Cookies are used as an authentication mechanism.

17
JavaScript

• Not a secure programming language.
• (Virtually all programming languages are not
  secure programming languages.)
• All scripts on a page run with exactly the same
  privileges, regardless of source.
• Dependence on global variables.

18
Document Object Model

• All nodes are linked to all other nodes and to
  the network

19
Never trust the browser.

• Use a rigorous validator on all input reject
  dangerous text.
• Everything it submits must be validated.
• Only whitebox filtering works.

20
User Generated Content

• Blogs, groups, reviews, email...
• Malicious JavaScript can be hidden.
• Only whitelist filters are effective at rejecting
  it.

21
Hygienic Construction

• Don't just concatenate strings together to form
  HTML or JSON payloads.
• Use encoding methods that ensure that everything
  is properly quoted.

22
Excellent Code Quality

• If code is clean and readable, it is less likely
  to contain insecurities.

23
There is no security in obscurity

• Tricks and puzzles are not effective.
• Speed bumps are not effective.

24
False security increases the danger.

• Ineffective measures make things worse.

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

27
An attacker can read the document.

• The attacker can see everything the user sees.

28
An attacker can make requests of your server.

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

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

30
An attacker can send information to servers
anywhere in the world.
31
The browser does not prevent any of these.

• Web standards require these weaknesses.

32
The consequences of a successful attack are
horrible.

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

33
This is not a Web 2.0 problem.

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

34
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

35
Competition to displace the web.

• Silverlight. AIR.
• JavaFX. Curl. Rebol.

36
That wouldn't be the end of the world.

• It would just be the end of the WWW.

37
Mashups

• The most interesting innovation in software
  development in 20 years.

38
Mashups are insecure.

• Mashups must not have access to any confidential
  information.

39
Advertising is a mashup.
40
If there is script from two or more sources, the
application is not secure.

• Period.

41
HTML Is Not Secure

• Browser implementations use standards as a point
  of departure.
• In the current environment, a browser that only
  supports standards would be worthless.
• Browsers allow JavaScript to be hidden.

42
Many nested languages with different quoting,
escapement, and commenting conventions

• Unintended mashups.

43
The Turducken Problem

• Many Languages
• HTTP, HTML, URL, CSS, JavaScript, XML, JSON,
  plaintext, PHP, SQL...
• Each language has different quoting and
  commenting conventions.
• The languages can be nested inside each other.

44
A text that is benign in one context might be
dangerous in another.

• Sloppy encoding allows injection of evil scripts

45
A Simple Attack

• http//yoursite.com/ltscriptgt...lt/scriptgt
• lthtmlgtltbodygt
• ltpgt404 File not found ltscriptgt...lt/scriptgt
• lt/pgtlt/bodygtlt/htmlgt
• The script runs with the authority of your site.

46
Never stuff raw text into a page.

• Every insertion must be properly encoded for its
  role.

47
Coding hygiene is critical for avoiding turducken
attacks.

• Use good encoders.
• Do not use simple concatenation or text
  insertion.
• Never trust the browser.
• Validate all input.

48
Turducken
49
PC Operating Systems confused the interests of
the user and the program.
50
The Source of Perpetual Woe

• The browser is able to handle two interests The
  Site and the User. Sort of.
• It is unable to go safely beyond two interests.
• The browser's model does not allow for the
  protection of multiple interests.
• Mashups require support for multiple interests.
• Interactive advertising requires support for
  multiple interests.

51
XSS

• XSS Attacks are a direct consequence of the
  browser's inability to manage multiple interests.
• Any script that can trick its way onto the page
  receives that same rights a privileges as the
  site's own scripts.
• An interactive ad or a mashup is an intentional,
  self-inflicted XSS attack.

52
JavaScript's Security Model Is Intolerable

• The global object-based design subjects all
  applications to XSS attacks.
• Third party scripts get first party privileges.
• New mashup-based application patterns call for
  intentional injection of third party scripts.
• This is dangerous.

53
JavaScript Is the Problem

• We need to replace JavaScript with a similar
  language that has the same expressive power, but
  that provides cooperation under mutual suspicion
  at the language level.
• The new language must break compatibility with
  ES3.
• The ES4 proposal is attempting to solve a
  different problem.

54
A Three Prong Strategy to Fix the Web

• Safe JavaScript subsets.
• Small browser improvements.
• Massive browser improvements.
• This could take a while, so we should proceed on
  all three immediately.

55
1. Safe JavaScript Subsets.

• The easiest way to improve JavaScript is to make
  it smaller.
• Caja. Cajita. ADsafe.

56
2. Add Simple Features to the Browsers.

• Even simple improvements can take a long time to
  distribute.

57
JSONRequest for safe data interchange.

• Or fix XMLHttpRequest

58
Vats
Communicating computational containment vessels
59
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.
• Iframes are not safe enough.

60
Vats

• Adapting Google's Gears or Adobe's AIR to provide
  communicating containment vessels is a partial
  solution.
• Provides cooperation under mutual suspicion.
• Heavyweight.
• Deployment is difficult.
• Still subject to XSS attacks.

61
3. We need to replace JavaScript and the DOM.

• As long as we are using insecure languages, we
  will be subject to XSS attacks.

62
Ultimately

• We need to replace JavaScript with a secure
  language.
• We need to replace HTML and the DOM with a secure
  application delivery system.

63
Most security architecture adds a lot of
inconvenience and little real safety.

• The TSA model isn't working.

64
Object Capability Model

• Better living through object oriented security

65
A is an Object. Object A has state and behavior.
66
has-a
Object A has a reference to Object B.
An object can have references to other objects.
67
Object A can communicate with Object B...
...because it has a reference to Object B.
68
Object B provides an interface that constrains
access to its own state and references.
Object A does not get access to Object B's
innards.
69
Object A does not have a reference to Object C,
so Object A cannot communicate with Object C.
In an Object Capability System, an object can
only communicate with objects that it has
references to.
70
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.

71
There are exactly three ways to obtain a
reference.

• By Creation.
• By Construction.
• By Introduction.

72
1. By Creation

• If a function creates an object, it gets a
  reference to that object.

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

74
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.
75
3. By Introduction
A calls B, passing a reference to C.
Miller Diagram
76
3. By Introduction
B is now able to communicate with C.
It has the capability.
77
If references can only be obtained by Creation,
Construction, or Introduction, then you may have
a safe system.
78
If references can be obtained in any other way,
you do not have a safe system.
79
Potential weaknesses include

• Arrogation.
• Corruption.
• Confusion.
• Collusion.

80
1. Arrogation

• To take or claim for oneself without right.
• Global variables.
• public static variables.
• Standard libraries that grant powerful
  capabilities like access to the file system or
  the network or the operating system to all
  programs or objects.
• Address generation.

81
2. Corruption

• It should not be possible to tamper with or
  circumvent the system or other objects.

82
3. Confusion

• It should be possible to create objects that are
  not subject to confusion. A confused object can
  be tricked into misusing its capabilities.

83
4. Collusion

• It must not be possible for two objects to
  communicate until they are introduced.
• If two independent objects can collude, they
  might be able to pool their capabilities to cause
  harm.
• For example, I can give gasoline to one object,
  and matches to another. I need to be confident
  that they cannot collude.

84
Stepping down the power

• Some objects are too powerful to give to guest
  code.
• We can give those capabilities to intermediate
  objects that will constrain the capability.
• For example, an intermediate object for a file
  system might limit access to a particular device
  or directory, or limit the size of files, or the
  number of files, or the longevity of files, or
  the types of files.

85
Ultimately, every object should be given exactly
the capabilities it needs to do its work.

• Capabilities should be granted on a need-to-do
  basis.
• Information Hiding - Capability Hiding.

86
Intermediate objects, or facets, can be very
light weight.

• Class-free languages can be especially effective.

87
The Facet object limits the Guest object's access
to the Dangerous object.
The Guest object cannot tamper with the Facet to
get a direct reference to the Dangerous object.
88
References are not revocable.

• Once you introduce an object, you can't ask it to
  forget it.
• You can ask, but you should not depend on your
  request being honored.

89
The Guest object has a reference to an Agency
object. The Guest asks for an introduction to the
Dangerous object.
90
The Agency object makes a Facet, and gives it to
the Guest.
The Facet might be a simple pass through.
91
When the Agency wants to revoke the capability,
it tells the Facet to forget its capability.
The Facet is now useless to the Guest.
92
A Facet can mark requests so that the Dangerous
object can know where the request came from.
93
Facets

• Very expressive.
• Easy to construct.
• Lightweight.
• Rights Attenuation.
• Revocation.
• Notification.
• Delegation.
• Accountability.
• The best OO patterns are also capability patterns

94
Good Object Capability Design is Good Object
Oriented Design
95
The web needs a secure programming language.

• JavaScript is not that language.

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

97
Be Rigorous

• Sloppiness aids the Enemy.
• Neatness counts.
• Use good encoders.
• Avoid concatenation.
• Be paranoid.