Building Secure Applications with HTML 5: What is Happening and Where?

I recently spoke with Sue Marquette Poremba recently about potential security risks associated with building HTML 5 applications.

One of the big things that will lead to security issues with HTML 5 applications is the relaxation of previous limitations with regard to where data is stored and where code is run.  Inevitably this leads to people making mistakes.

Let’s look at a little history:

Web 1.0: Most data and processing is done on the server side, but developers put state data into hidden HTML FORM elements and cookies without realizing (or admitting) that malicious users can easily modify them.  They also rely on client-side input validation via JavaScript for security which attackers can easily bypass.

Web 2.0: Data and processing are split between the client and the server.  More state data gets pushed to the client via JSON and other techniques.  Much more processing is done in client-side JavaScript.  Developers still fail to appreciate the security implications of client-side data manipulation and fail to verify security-relevant calculations on the server side.

HTML 5: More data gets sent to the client side, and now it gets persisted on users’ workstations across sessions.  Offline web applications run even when the user is not connected.  Relaxation of cross-domain restrictions allows processing to be done not only on the client side, but also on 3rd party servers.  Hilarity, I suspect, will ensue.

We have found a couple of simple techniques that can help get the right questions asked earlier in the development process:

·         Build Threat Models with data flow diagrams: This gets application architects and developers to explicitly define assets, processes and the trust boundaries that exist in an application.  This can be very helpful in highlighting where sensitive data is being stored in an untrusted (ie client-side) environment.

·         Build UML Sequence Diagrams for critical functionality: This forces the developers to be explcit about what components are making what calls.  As with the data flow diagrams this exposes situations where security controls aren’t located where they need to be as well as situations where security-critical decisions are being made where they shouldn’t.  And if you can’t easily figure out where a particular operation is running then perhaps you need to take a good look at your architecture and the technologies you’ve chosen to use for implementation.

Based on this newfound understanding of your application:

·         Design and build your application with the assumption that data on the client side might be changed and might also fall into the hands of someone who breaks into the user’s workstation.

·         Design and build your application with the assumption that any calculation done on the client side – or anywhere not under your control – may be compromised.  Re-verify any security critical decisions in your code.

HTML 5 has a lot of great capabiltiies and it should make it possible to build applications that weren’t previously possible.  A little bit of thought early on when building these applications can head off a lot of pain and suffering later.

Contact us for more informaiton about using new technologies securely.

–Dan

dan _at_ denimgroup.com

@danielcornell

Posted via email from Denim Group’s Posterous

About Dan Cornell

A globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application vulnerability management platform.
More Posts by Dan Cornell

Categories: Uncategorized

Leave a Reply

Your email address will not be published. Required fields are marked *