On Client-Side Model Data Validation

Reversing an online Flash application is sometimes not needed if you can access the data inside the model directly.

When you're developing an online application that's running client-side with data server-side, you're faced with the localization of data. For clarity, let's assume you're developing it in a MVC design pattern. Basically, you'd want to put most of data on the server and only give the client a controller on it. The problem starts when you need high transfer rates and reactivity: you just can't go to the server and back for every tiny piece of data. That's when you need to have the model split between the server and the client. Either split or duplicated.

What I'm going to say may come as an obviousness for people used to security, but it may as well come as a shock for casual application developers: if some part of your data model is located on the client, you need not only do user input validation on the inputs from the controller but also on the inputs from the client-side model.

You can't trust the client's terminal to keep data stored in the model safe. So you need to protect it either through integrity or through server-side re-validation.

I just hacked into putting whatever score I wish for myself onto an online gaming platform, which inspired me to write this article. The same could be applicable for more critical applications.

Draft: Stuffing Security into MVC

A long time ago, when I was young and crazy, if I ever was, I used to code components in Java, with the help of the MVC design pattern.

It's a very useful tool and I've recently had the occasion to recommend it to a little company. They used it very efficiently to solve the messy  graphical interface of their featured soft. Nowadays, I'm mostly concerned about security and I do suffer, as those of my kind, from the underlying insecurity of software. It's not just insecure on the surface, it's insecure from the bottom up.


A complex system that works is invariably found to have evolved from a simple system that worked. (he said)
A complex system that is secure is invariably found to have evolved from a simple system that was secure. (let me add).

So I got to ask myself if it was possible to put some security directly into design patterns.

Say you'd like to stuff some of the following principles into the above diagram:  identification, authentication, authorization, audit, capacity planning, soft/hard redundancy, load balancing, cyphering, shoulder spying, data integrity, backup. Where would you start?

For each of them, I'd start by putting appropriate data/meta-data into the Model or near it. Then I'd make the View able to display what's necessary. Then I'd update the Controller with adequate intelligence. Simple, no?


Identification: Identification is based on data that's common with many other pieces of software. Let's say we'll dedicate a new model for it. Then say that neither the view, the model nor the controller will act before the user has been identified.
Authentication: Authentication requires pieces of data, or tokens, that can be verified by interacting with Identification data. But it requires no model of its own. Authentication is -nowadays- a period of time during which the system assumes the user really is whoever is was identified to be. Say that Authentication is a method of the identification component that returns a binary (authenticated or not). Then say that neither the view, the model nor the controller will act if the user is not authenticated.
Authorization: Authorization is a b/w mask (allowed/denied). It's a function of Identification data and the data in our model. So we want to add the "authorization mask" into our model. (That's a huge part of the security job. You can simplify it by using roles, such as in ORBAC.)
Audit: Audit is keeping track of what happens. It can be seen as a two-bit mask of the data in our model, indicating what's going to be logged. 00 means nothing, 01 means read operations, 10 means write operations, 11 means read and write operations. So we want to add the "audit mask" into our model. Then the controller will just write logs of whatever is to be audited.
Capacity planning: Capacity planning is measuring the volume of activity inside the component, as well as the size of the model itself. The numbers of read access and write access to model data and the number of routine execution of controller methods should be counted. These counts can be put into the model and updated by the controller.
Redundancy and Load Balancing: There's not much data in it but the choice of a pattern. Say active/active, active/passive, multiple instances, etc. The choice of this redundancy pattern can be put inside the model. The controller will have to instantiate components and "control" them. This may require an external Timer, or Sequencer, or Scheduler, whatever you call it, in order to trigger events on a defined schedule. (One huge advantage of component programming is that you can play at instantiating them in no time. This part really can be fun)
Cyphering: Cyphering between components is no big matter if you know the basics about PKI. You just need to make sure that you know which flows of data you want to cypher. This can be seen as a one-bit mask (cyphered/cleartext) of component-to-component flows. This "internal cyphering mask" can be put inside the model. Disclaimer: you DON'T WANT to create a unique instance of an object that handles cyphering for every component!
Shoulder spying: Shoulder spying should be let up to the view itself. However, the choice of what data has to be protected from neighbours should be stored in the model. It can be seen as a "hiding mask" (one bit or more). Then the view chooses how to implement it.
Data integrity: Whenever in the history of IT, integrity has meant the addition of control data to check validity and completeness. This data can be put in the model. The controller will have to take on the job of updating it whenever data changes. This means the model will have to enable atomicity of transactions.
Backup : Backup definitely requires an external scheduler because of its high cost. You just don't want to replicate data every time it changes. Plus you may want to rewind time later. Backup can be seen as just a serialization of the model. It means the model will have to support serialization.

More next time...