I will term this new area "Object Injection".
So .. code might look something like (simplified by not showing the Asyn Callback()
MyDomainObejct obj = finder.findDOByID(myId);
_ = pkg_BusinessEntity.prototype = new java_lang_Object();
_.java_lang_Object_typeName = package_pkg_ + 'BusinessEntity';
_.java_lang_Object_typeId = 4;
_.pkg_BusinessEntity_abn = null;
_.pkg_BusinessEntity_commencementDate = null;
_.pkg_BusinessEntity_isCurrent = false;
_.pkg_BusinessEntity_isRegisteredForGST = false;
_.pkg_BusinessEntity_name = null;
_.pkg_BusinessEntity_postcode = null;
_.pkg_BusinessEntity_registeredState = null;
So, where is the security concern ?
Well in some cases, such as most of my world, the domain model is fairly significant, with trading / transaction objects and user accounts with passwords, and money and settings etc etc.
So if, in a GWT class, someone were simply to expose the DAO (Data Access Object) service such as
Then, essentially we have, assuming there is no or not sufficient checks, a direct way to store objects into the domain (database) from the browser.
I will call this "Object Injection" in the same vain as "SQL Injection". An Object injection hole is could really be termed as a
Poorly Coded RPC interface which does not check values and who and why of what it is "doing".
Of course, finding an Object Injection hole in a GWT application is going to prove fairly complex to do (but surely not as hard as searching for a buffer over/under run). The types of tasks that a would-be inquisitive person might have to do is as follows.
- Dump out all the "Service" methods and try and tie these to where they are being used in the GUI (Web Application).
- Identify the types of objects which would provide benefit of "changing", such as Bank Accounts, Limits, restrcitions, user account saving (like storing settings etc) and locate how the interface is working with the RPC method calls
If parts of the domain model are exposed, this is a good place to start hacking.
The problem is no different with current non-GWT AJAX development. It is just that GWT does a lot of smoke and mirror compiling for you and if you unwittingly create holes in your Java RPC methods (without sufficient checks), then those holes are exposed for all to see (and play with).
So what techniques can we use to prevent us making such a holes. The following would be my quick and dirty set of rules.
1. Don't expose the domain model to the GWT compiler.
Why ? Well for a few reasons
(b) To expose a Domain Model Object, means you probably want to "change" and store it, which means the DAO service (or similar) will have to take an object and save it to the database. Simply, find that DAO Service and the right object that it requires, and I can then start poking in (Object Injection) other object values to see if I change some stuff at the server.
2. Have Users / Accounts and Password - and Audit them
If you use usernames/passwords and sufficient checks in the right places you will have the ability to log who is doing what. Another way to think of this is, minimise the amount of GWT you use to people who are not authenticated against your application.
A way that I always achieve this these days is to use Acgei Security with Spring and webfilters over the whole application. This way I know which users are hitting which RPC methods and could audit appropriately.
3. Expose ONLY that which needs to be - Use DTO's, simple APIs, push "work" to the server, Separate Projects.
Use DTO's to push and pull your data back and forth. This way you can check the DTO values before storing and also know what is being exposed at the front end.
Use Simple API's - Make you RPC methods simple (ie, don't push too much back and forth). This is probably just a KISS principal and will help in making sure you don't inadvertantly expose that which shouldn't be.
Move as much logic as you can to the server. This ties in with the previous point. A simple API logically means that the complex stuff is on the server. This way, code which does not need to be seen, is not seen. Plus the burden on the browser *our unknown environment* is kept at a minimum (which has an added bonus because we don't want the help desk of our application getting complain calls saying the application slows down their browser thus tarnishing the "company".)
4. Secure all RPC interfaces
Use Aspects or Filters (I use Acegi Security) to secure your GWT RPC methods. You will be able to lock down the method calls to the user and also ensure that the "objects" are allowed to be transported that are.
I hope this little entry helps people see the potential issues and raise awareness in their designs about this potential security "feature".
It is nothing new, of course, but the way in which GWT development is done, can have an impact on the "bad applications" we write if we are not careful.