Flex Pasta

Flex using BlazeDS with Java. Do you care about security?

You’ve just set up your flex-java project using BlazeDS AMF.  You’ve got some classes in java which have matching actionscript classes that have the magic “RemoteClass” tag to tell the bean proxy where to find your class.  Everything is working well and then you have a thought, how in the world can I make this flex app secure?  With remote classes in actionscript, your application is more wide open then any jsp application.  Someone with the right knowledge can decompile your swf and see the classes, giving out a blue print to your application’s architecture. 

BlazeDS and Security

BlazeDS uses the PropertyDescriptor class when going from java to actionscript.  Basically, this means for each getter and setter you have in java, BlazeDS is going to pick this up via reflection and serialize the data to AMF output to the client.  If you have a getter, but no setter in java, it won’t be read by BlazeDS.  Keep in mind that regardless of what is in your actionscript class, all data returned from your java service will be sent back over the wire to the client flex app.  

Where do I start?

Let’s assume you have a java class called Customer.  Customer.java has 3 getters and setters for id(the primary key), username, and password.  You have a simple flex app that allows you to change your password.  When the customer changes their password, you send off a remote call to your java service updateCustomer().  Without getting into whether you are using hibernate or some other database access method, we’ll assume that in the end your updateCustomer() method executes this following query: update customer set username=’admin’, password=’password1′ where id=1.  Excellent right?  Everything works.  You have to assume however, that any flex app, can send any request it wants, regardless of what safeguards you have in place in actionscript.  Pretend now that hacker Joe comes along and starts snooping your remote classes.  He notices your actionscript class “Customer” being sent over the wire calling the updatePassword() method.  Joe then modifies the customer.id to 2 and the username and password of his choice.  The update query runs and now hacker Joe is able to login to another user’s account using his own username and password! UH OH!!!!!  In a JSP/HTML app you might already have the customer stored in a session, so you would never be passing the customer.id over the wire and would not have to worry about this type of tampering.  With actionscript and remote objects, it is all there in the open.  How do you tackle securing the flex app?

1. Secure the primary keys
- Store at least the primary key in Session on the way out from java to flex.  When you get the request from flex to java, check to make sure the user has access to the primary key they are trying to change.

2.  Secure the foreign keys
-Other classes will probably have your customer.id as a foreign key in their class.  Make sure these are secure from tampering as well.

3. Secure your remote methods that flex will be calling
-Use remoting-config.xml to exclude methods that the user should not have access to.  One way to this:

<destination id=”customerService”>
        <properties>
            <source>customerService</source>
        </properties>
  <exclude-methods>
  <method name=”updateCustomer” security-constraint=”admin-users”/>
  </exclude-methods>
</destination>

You can read more about this in the BlazeDS dev guide.

4. Secure any other fields that are sensistive and should not be able to be changed by the end user.

Conclusion

BlazeDS does contain some features to help secure your flex app.  It still lacks a strong security model for securing bean classes.  Most of the work for security will need to be done by an app by app basis.  Think about security during your design in the beginning.  Flex is more open than many realize and it only takes one bad hacker Joe to poke a hole in your app.  Have someone dedicated to specifically laying out a security design and have checkpoints to ensure standards are met.