Security Assessment of a Adobe's Flex Web Application

First of all, in my personal opinion Flash/Flex (or ActionScript) = HTML5 + JavaScript + CSS3. Why? Because both are rooted in ECMAScript therefore I view ActionScript as a JavaScript on steroids (with additional libraries). For example, Adobe's ActionSript has a build-in API to draw graphics (i.e. GraphicsPath object) while JavaScript relies on HTML5 canvas element (see http://www.williammalone.com/articles/flash-vs-html5-canvas-drawing/). Moreover, typical Flex application architecture resembles AJAX based web application (i.e. JQuery framework). AJAX engine is capable of making SOAP and RESTful, exactly as Adobe's Flex application, handling data as simple text, XML or in JSON format (see http://www.adobe.com/devnet/flex/articles/flex_java_architecture.html).

Naturally, it has its advantages such as no cross browser implementation issues, and disadvantages such as the requirement to have an Adobe Flash plug-in installed to run the application. In addition, Adobe's Flex has a mature and well developed software development platform while AJAX still relies on GNU Emacs which, when considering enterprise web application, is a "biggie".

But back to the security assessment of a Adobe's Flex applications...

Because Adobe's Flex application is basically a packaged ActionScript which runs on a client side, a lot can be gleaned from the source code itself. A number of SWF decompilers such as SourceTec Software SWF Decompiler (http://www.sothink.com/product/flashdecompiler/) allows an assessor to break down Flash into components such as shapes, images, sounds, video, text, ActionScript, etc. and examine to identify "leaked" intellectual property (IP), copyrighted material, comments in the source code and other security related goodies.

The next step (or in parallel) would be to review the interaction between the Adobe's Flex application and the back-end server(s) using tools such as network sniffers and analyzers (i.e. WireShark), and application proxy (i.e. Paros, Fiddler2 or Burp). Again, the communication could reveal sensitive information such as user ids, passwords and maybe even credit card numbers. Moreover, communication could be intercepted and tampered to attack the back-end web server and the server application. Here a few buzz words come to mind such as XSS, CSRF and SQL Injection.

Finally, the back-end server deserves some attention as well - not for nothing it runs 8 dual core CPUs with 16GB RAM. Here, the rules of the game are similar to a standard web application assessment (if it is can be called "standard"). First, a quick scan to identify the what is running and how secure it is - basic misconfiguration can leave gaping holes. Then automated and manual security assessment to exploit the identified weaknesses which could range from weak authentication of the administration module to bad coding standards such as lack of input validation or exposure of database internal schema.

Imagination and creativity are assessors best weapons!