Flex Pasta

The benefits of using flex for a high traffic login site are enormous!  Even if the rest of the site is not in Flex, the login process should be.  Here are a few reasons why:

• Security:  Sites where security is important and the login page is open to the public: health care, internet banking, online stores, etc.  Flex is a flash movie, where images, content, forms, are embedded into one file, make it nearly impossible to duplicate for phishing purposes.  HTML websites are open to anyone to steal their code.  Within minutes, a newbie hacker can take a site’s html and have a full functioning phishing website that looks just like the original.  With Flex, stealing a flash file would take highly advanced skills and much more time to come up with the same scheme.
• Performance: Take an internet banking site for example.  Many of them these days have a multi-step login process.   Step 1) Enter user name, Step 2) Answer a secret question, Step 3) Enter a password if the image shown is the one you picked out.  Internet banking and many other sites heavily rely on the login process.   Many users are just logging in for a quick check of something and then logging off.  Think of the number of transactions an html application makes in this example for the login process alone: 1) Serve the login page. 2) Serve the secret question page. 3) Serve the Password page. 4) Serve the user’s image.  5) Try and Log user in with password entered.  Now with Flex, the SWF file can be placed on the web servers, and once the user has it, they won’t have to download it a second time unless it’s updated.  There is much less but more efficient back in forth with the SWF and the Server:  1) User enters user name.  Request made.  Secret question, secret answer, user’s image is returned.  If the user enters the right answer, we show them their picture, without making a second or third call against the application server.  2) Try and Log user in with password entered.  With Flex, 2 calls are made to the application server vs the 5 with an html app!!  Not to mention the size of the request/response with the Flex app is much smaller.
• User Experience: Flex has the ability to place cool effects and transitions from step to step on a login process.  When my web app is at peak usage, those transitions make the app seem to move faster than with an html app.  The user won’t feel like they’re using dial up while waiting for the server to respond.  The user will feel more confident with this login process and phishing will be virtually eliminated.

Even if a site is not written in Flex, it can still utilize a Flex login process for the added benefits described above.  Existing sites don’t have to look at Flex and consider a complete rewrite to gain the benefits.  Start with the login process and see what Flex can do to eliminate phishing, improve performance, and add to the user experience!

Like many Flex/Java applications, they are started from scratch and use java 1.5 or greater. I was surprised that there were no annotations for BlazeDS to make it easier to mark up remote objects and services. Being that BlazeDS is open source, I thought it would be valuable to use annotated classes for remote objects. I created a custom BeanProxy(a class that defines what properties go from Java to actionscript, and vice versa). Note: I have submitted the code to Adobe for acceptance into the BlazeDS code base. I plan on expanding the code further, and I hope others will contribute as well. The link to the enhancement request can be found here: Please vote for the issue! Inclusion into the BlazeDS code base will help make it maintainable in the long run.

Now for a step by step guide about the annotations, and how to use them. First, I will point out that somethings I have done in the code are not ideal but are necessary to be compatible will BlazeDS which is primarily a java 1.4 app.

1. Download the Jar and source: BlazeDS Annotations Jar and Source Files
2. Take one of your domain classes/remote objects and implement IAnnotatedProxy and mark the class with the @FlexClass Annotation. The IAnnotatedProxy is a marker interface and its existence is simply to tell BlazeDS it has annotatations and should use the AnnotatedBeanProxy instead of the normal BeanProxy.
3. Add this one liner to the servlet init of your webapp: PropertyProxyRegistry.getRegistry().register(IAnnotatedProxy.class, new AnnotatedBeanProxy());
4. Begin adding @FlexField annotations to your “getter” methods on your remote objects. As I will explain in more detail, I have broken up what the @FlexField annotation does into two parts:
   1. Annotations that manipulate whether a field is included in BlazeDS AMF serialization.
      1. @FlexField( fieldType = FlexFieldType.ReadWrite) - Default option. Acts just like domain objects do today with BlazeDS, it reads a field if and only if both a matching getter and setter exist.
      2. @FlexField( fieldType = FlexFieldType.Exclude) - Does not include this field in AMF serialization even though a matching getter and setter may exist. Benefits are 1) Performance, 2) Security, and 3) Unnecessary Clutter. Keep in mind though, if you have a field populated with data going from Java to Flex, when it comes back from Flex to Java, the fields you excluded will be null.
      3. @FlexField( fieldType = FlexFieldType.Transient) - Include this field in serialization from Java to Flex if it has a “getter” method, but it does not require a matching “setter” method. The primary benefit here is I may have a field such as a calculation that doesn’t have a “setter” because it is a calculation. Yet I want the field to be translated over to the flex front end because I will use it for display only purposes to the end user.
   2. Annotations that manipulate data during serialization primarily for security purposes. Note, for use of the following annotations, remote objects on both the flex and Java side MUST extend mx.rpc.remoting.JavaObject. Before using the following annotations, make sure to fully understand what they are doing.
      1. @FlexField( fieldType = FlexFieldType.ReadOnly) - This field is included in serialization to and from Java and Flex. However, when data is coming from Flex into Java, encoded data in the JavaObject’s key determines the value of the field. Example: An account number field with the value of 999 is passed from Java to Flex. The account number is encoded in the JavaObject’s “key” field. Now the user goes to save their account settings, so data is sent back from Flex to Java. If the account number is anything other than “999″, a (runtime) ReadOnlyException is thrown. The primary benefit here is security. I want the user to be able and see, but not edit the account number on the Flex side. There may be other fields in the domain class they can edit, but this field is off limits.
      2. @FlexField( fieldType = FlexFieldType.CreateOnly) - This field is included in serialization to and from Java and Flex, and is almost identical to the ReadOnly Annotation. The difference here is that, if the field has no value(is null) when it goes from Java to Flex, the field can be created on the flex side and sent back. An example here is a foreign fey field. I have a customer creating an order. The order contains a customer id field. I want to let the customer create an order with their customer id for the first time, but after that, want to make sure that data is not tampered with later.

Web 2.0 and Security

With Web 2.0, application security is a big concern. Data is much more exposed to the curious eyes of an end user (especially primary and foreign keys) than in a traditional web app. My post on BlazeDS and Security goes into more detail. One of the driving forces for these annotations is for object security.

Annotations: To be Continued….

The annotations here create a starting point for use in BlazeDS. I hope the community will build on these annotations. The next goal is to tackle securing remote service methods using annotations. Feel free to post ways you would like to see annotations used with BlazeDS in the future.

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.