Web security challenges with the new HTML5

The code which runs most, if not all, web sites, HTML, is getting a much needed update.  New code brings new problems. Want a job that will last your lifetime? Get a degree in Internet security.

According to an article on Mashable:

Cross-Origin Resource Sharing.

An HTML5 feature with possibly the most potential for mistakes is the Cross-Origin Resource Sharing (CORS) that relaxes the fundamental security mechanism of a browser, the Same Origin Rule. CORS isn’t an arbitrary change; it’s a step towards standardizing what developers are already trying to do in order to build higher-performance sites.

The following headers show how simple this is to implement from a server’s perspective. (Obviously, we’re just showing the HTTP headers and skipping the server-side code to generate and verify these.)

Access-Control-Allow-Origin: http://domain
Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: PUT, DELETE

The first one, Allow-Origin, is where the worst mistakes will happen. We’ll see who the first sites are to use * in this field — thereby allowing sharing with any domain. There’s already precedent for this in Flash crossdomain.xml file vulnerabilities.

Web Storage.

The push for richer browser-based functionality also brings the desire to store more data in the browser than normally handled by cookies. Cookies have been the historically clumsy method of saving stateful data. The HTML5 Web Storage specification provides a more flexible way for sites to store data in the browser using essentially a key-value database.

What happens in one domain is supposed to stay in that domain. The browser assumes that content coming from a domain name is always legitimate, but that isn’t always the case if DNS isn’t secure.

Now we may see sites that store sensitive, personal information via web storage APIs. If the site has a cross-site scripting (XSS), then an attacker would be able to trivially extract this information. (Note by Ted: Think ‘cloud computing’ and all your personal information suddenly becoming public.)

The past rears its ugly head.

The worst problems will come from developers who rush into new technologies without remembering sins of the past. It’s far too easy to fall into the trap of trusting data from the browser just because some hefty JavaScript routines have been assumed to perform all sorts of security validation on the data.

Once data leaves the browser, an attacker can modify it in any way before it reaches the server. Trusting the client to always serve well-formed, valid data is the sure path to SQL injection, XSS, and worse vulnerabilities.

Read the full article on Mashable here.