<p>Security design is an important, but often neglected, component of system design. In this session, Douglas Crockford, creator of Javascript Object Notation, will outline the security issues that must be considered in the architecture of Ajax applications.</p> <p>The design of the browser did not anticipate the needs of multiparty applications. The browser’s security model frustrates useful activities and allows some very dangerous activities. This talk will look at the small set of options before us that will determine the future of the Web.<br /> During this session, attendees will:</p> <ul> <li>Learn why effective security is an inherent feature of good design;</li> <li>Experience a real-time demo of a Ajax client/server system based on sound security principles</li> <li>See how to apply secure design to rich web applications.</li> </ul>

1. Web Forward! Douglas Crockford Yahoo!

2. Gordon E. Moore

3. The complexity for minimum component costs has increased at a rate of roughly a factor of two per year ... Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years . 1965

5. Moore's prediction became a self-fulfilling prophesy. It cannot hold forever, but it is still holding now.

6. Processors, memory, disk storage, network bandwidth. Everything except software.

7. Software is not subject to Moore's Law. Software is subject to Murphy's Law.

8. Software productivity improves at a much slower rate. Doubling in 10-20 years, rather than 2 years.

12. Mashups! JavaScript is the mashup language! It is better suited to dynamic mashing than the conventional OO languages.

13. Unfortunately ...

14. The Web Is Under Attack!

16. The browser is not a safe programming environment. It is inherently insecure.

17. What can an attacker do when he gets some script into your page?

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

19. An attacker can make requests of your server. Your server cannot detect that the request did not originate with your application.

20. An attacker can read the document. The attacker can see everything the user sees.

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

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

23. The browser does not prevent any of these. That's why they happen.

24. The consequences of a successful attack are horrible. Harm to customers. Loss of trust. Legal liabilities. Possible criminal penalties.

25. The vulnerabilities are required by Web Standards. The consequences of standard behavior, not bugs.

26. “ and God gave us the Web Standards, and deviation from the Web Standards is the source of All Evil!” There is no truth in that statement.

27. The web was once a driver of innovation. The web is now the obstacle of innovation. Web development requires mastery of the workaround. You can't work around security.

28. If there is script from two or more sources, the application is not secure. A mashup is a self- inflicted XSS attack.

29. Confusion of Interest Computer System Mode

30. Confusion of Interest System System Mode User

31. Confusion of Interest System System Mode User User User

32. Confusion of Interest CP/M MS-DOS MacOS Windows System Mode

33. Confusion of Interest System Mode The System cannot distinguish the interest of the user from the interest of any program. This enables floppy-borne viruses.

34. Confusion of Interest System Mode When networking is introduced, network-borne viruses are enabled.

35. Confusion of Interest User Browser System Mode Site Site Site The browser is a significant improvement, able to distinguish the interests of users and sites (in some cases).

36. But within a page, interests are confused. An ad or a widget or an Ajax library gets the same rights as the site's own scripts.

37. JavaScript got close to getting it right. Except for the Global Object. And some other bad parts. It can be repaired, becoming an object capability language.

38. An Introduction to Object Capabilities

39. A is an Object. Object A has state and behavior.

40. has-a Object A has a reference to Object B. An object can have references to other objects.

41. ...because it has a reference to Object B. Object A can communicate with Object B...

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

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

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

46. 1. By Creation If a function creates an object, it gets a reference to that object.

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

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

49. 3. By Introduction A calls B, passing a reference to C.

50. 3. By Introduction B is now able to communicate with C. It has the capability .

51. If references can only be obtained by Creation, Construction, or Introduction, then you may have a safe system.

52. If references can be obtained in any other way, you do not have a safe system.

53. Good Object Capability Design is Good Object Oriented Design

56. How Do We Move the Web Forward?

57. Browser War! Never again.

59. A revision to a standard is an act of violence. Surgery. Pain. Injury. Inconvenience. Users of web standards cannot opt out.

60. Not only are the web's standards broken, the web's standards process is broken.

61. Design by Committee. Porkbarrel standards making.

62. Minimalism should be highly valued in standards. Committees are not good at minimalism.

63. The standards process is entertaining too much speculative technology. ECMAScript's Close Call

65. A standards process must be risk averse. Once an error gets into a standard, it can be virtually impossible to get it out.

66. The Dilemma: Good Standards happen slowly and our need is urgent. The web standards are currently frustrating progress and endangering everyone who uses the web.

67. Web Time used to mean really fast . ECMAScript 3: 1999. HTML 4.01: 1999.

68. Browser War! We need a Browser War!

69. The only thing worse than where we were is where we are.

71. The marketplace must be more effective this time in punishing bad behavior. Yahoo!’s Graded Browser Support Program

72. This Site Requires Netscape 3

73. Innovation should happen in research laboratories, startups, and forward-looking companies. Not in Standards bodies.

74. Standards should have a conservative process that documents the best of what has been proven useful.

75. The drafting of standards is difficult, important business.

76. Standards should not be inventions. Standards should be agreements. Standards should work.

77. We should also be looking past the Web. The web was a disruptive technology. The Web needs to be disrupted.

78. I’ll see you in the trenches!