Web vulnerabilities in an HTML 5 application

For the past few days, I have been messing with some of the features of HTML 5:

  • local storage
  • Offline web applications

These features enable the development of real applications, running in the browser. It has a lot of advantages: easily updating the application, reduce the workload on the server, etc.

But it changes the way you write your code. You have to adapt the usual protection mechanisms to these changes.

Here are some thoughts about the common web application vulnerabilities.

Warning: I consider here a web application with practically no server-side code: everything executes in the browser. And I’ll use the point of view of someone attacking the application running in the browser. And I’ll be optimist enough to trust the browser…

SQL injections

SQL injections in servers let you access the user’s data, and access the server itself (file uploads, starting external programs, etc). With local storage and WebSQL, you won’t be able to access the host, only the data (unless there’s a browser vulnerability about that). And you can use some sort of prepared statement syntax to prevent injection. There may be a risk with key/value stores if you let the user input control the key.

Cross site scripting

This is in my opinion the biggest risk. If all the logic of your application is on the client’s side, unwanted code executing in the browser has access to everything. This one can be mitigated by filtering what will be displayed on your webpage.

Cross site request forgery

This one is not critical, unless you use locally URL parameters (don’t laugh, it has often been done and exploited in Flash applications). Be aware that an attackant could get data in local storage that way.

Persistency

It really worries me that so much data can stay a long time in the user’s browser. With a database hosted on your server, if unwanted data(persistent XSS, malwares…) is stored, you can erase it, patch your website’s code, and your users will be safe.

With HTML 5, you’ll have to clean every user’s data. You can’t be sure that you have  protected all your users (someone could wait 6 months before coming back to your website). And because you can’t be sure, your code has to check for each known bad data. It needs a lot of code, time and tests.

Trust issues

It has been said a lot of times already: don’t trust the data coming from your client. And in our case, don’t trust it, even if it’s data that your website put in local storage. It applies to data that will come back to your server, but also to data that will be displayed with a bit of Javascript/DOM code. Yes, XSS attacks could come from local storage. So, you need to escape everything that wil go into the webpage.

Are we screwed?

These were only quick thoughts about the vulnerabilities you could encounter with client side web applications. It is not really hard to protect the application, but you have to be very careful about what data you will trust. The good thing is, these vulnerabilities are not new: you can see them in lots of Flash applications. So, the mitigation mechanisms are well known, and easy to apply.

Advertisements

4 thoughts on “Web vulnerabilities in an HTML 5 application

  1. We aren’t screwed. It will just take good programming practices and all of us working together to help mature the standards around HTML5.

    • Sure, but it is hard to make people follow the good programming practices. And sometimes, they don’t even exist: the only text I saw about escaping text with Javascript had false and insecure code.

  2. I have problems with passing data from one page to another when offline. It seems to be that the files in the manifest (e.g. http://foo.com) are not recognized when you add a keyvalue pair to your url (e.g. http://foo.com?key=value).

    At this moment I AM THINKING OF THREE SOLUTIONS:
    1. use the local db as an intermediar (not really what a db is for!!)
    2. using session variables (hard to track / dirty solution)
    3. single page solution using javascript injection.

    The third option looks like the best one for now, but I still can not imagine that this is the best way to do it.

    It would be greatly appreciated if you could comment on this.

    • If you want something like parameters in the URL, you can use anchors: http://foo.com#param=value will not generate a new request to the server. You can then get the parameters with window.location.href, and parse them. I use that in an application of mine, and it works great! But be careful: there is a risk of cross site request forgery with this method.

      If you only want to open a new tab from your application, I would recommend using session storage. A DB is meant to store data, so I’m pretty ok with using it for this :p

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s