Ben Forta

In response to my article on the Flash Data Connection Kit (at http://www.macromedia.com/devnet/mx/coldfusion/articles/data_conn.html) many of you have written to me asking about comments I made as to how to use (or not use) the Firefly components in production environments. Some of the specific questions pertain to my recommending that the SQL Connector not be used, that a generic XML delta packet processor not be implemented, and that table names or other database specific information not be embedded directly in the Flash application.
The truth of the matter is that the validity of my concerns really depends on where the application is being used, and whether or not it is being used in a trusted environment (by trusted users). There is nothing inherently wrong or bad in doing any of those things that I advised against, but doing so does require making some core assumptions that worry me.
The underlying concern here is this: I have a fundamental problem with anything running on the client side of an HTTP connection being able to directly affect SQL statements being executed against a database. Put it this way, would you ever display the SQL that your application page were to execute in an editable box? Of course you wouldn’t. You’d also (I hope) never pass URL parameters directly to SQL without carefully checking them first. And you’d never embed table names or SQL in generated HTML. Ever.<br /> Flash may be a bit different in that it is a little harder to browse and change what is in Flash than it is an HTML page, but it is not impossible. Furthermore, Flash Remoting runs over HTTP and it is not impossible for a client other than Flash to pretend to be something that it is not. The fact of the matter is, embedding SQL in Flash essentially requires that ColdFusion (or Java or .NET) on the server pass that SQL to a back-end DBMS for processing. That requires faith that the client has not been tampered with in any way, and I’d suggest that such faith is inherently risky. Even writing a generic XML delta packet parser (one that will handle inserts and updates and deletes for tables and columns specified in the XML delta packet itself) is dangerous. It would not be difficult to submit SQL to get back all primary keys (or simply browse Web pages to look for primary keys, as these are often used as URL parameters in data drill-down interfaces), and then submit a malicious delta packet that would execute DELETE statements for all of those keys.<br /> Flash SWF files may be compiled into a binary form that is not human readable or writable, but don’t let that create a false sense of security. It is possible to decompile SWF files, it is possible to fake being Flash talking to Flash Remoting, and it is possible to send fake XML delta packets. This is not a limitation of Flash, rather, it is part of the very nature of HTTP. Flash, like a Web browser, is bound by the behavior of HTTP. Flash can be useful and valuable as the client side of an HTTP based client-server application, but it is best to treat Flash as you would any HTTP client, and not make dangerous or naive assumptions.<br /> And thus my comments in that article. Of course, every rule is made to be broken, and in known trusted environments it may indeed be acceptable to embed SQL statements in Flash or arbitrarily process XML generated SQL in ColdFusion. But my gut feel is that this should be considered the exception, not the norm.