amfphp and security

Securing an amfphp project is not any different from securing any other php installation. Contrarily to what most people believe, amfphp projects are neither more or less secure than any other php projects.

Debunking two myths

The first myth is that Flash Remoting is inherently more secure than standard HTML apps since Remoting data is sent as a binary stream, and therefore it's harder to 'hack' into an amfphp installation. Creating arbitrary amf packets is not any harder or easier than sending custom POST data, and in fact it can be done with exactly the same tools (cURL for example). Dozens of open source projects can read and write AMF.

The .swf format itself is not encrypted and a all decompilers will let you extract ActionScript, which means a password stored in ActionScript is neither more or less secure than a password stored in a hidden field in HTML.

If you deactivate the NetConnection debugger, a variety of widely available packet sniffers supporting AMF can still see and interpret the AMF data sent through the wire.

The second myth is the converse, that Flash Remoting is inherintly less secure than traditional HTML applications. HTML applications are basically built on a Remote Procedure Call model like Remoting, with the caveat that the whole page is replaced instead of a small data being sent and interpreted. There is a small complication in Flash coming from the fact that the client is stateful, so you may think that this enables you to trust the client's input; of course you should never trust any client input.

Security for dummies

These security tips are not specific to amfphp, but should always be followed whenever developing a php or other client-server app:

  • Don't attempt homebrew auth systems with cookies, use sessions
  • Don't store anything sensitive on the client-side or send useless sensitive data
  • Protect yourself against SQL injection
  • Validate all user input
  • Don't execute arbitrary code sent by the client
  • Salt your passwords before md5'ing them and storing them in the db

Amfphp specific tips

Use the built-in authentication mechanism to log in or log out users, and protect them for accessing certain resources.

Be careful with return mysql_query(SELECT *) statements on tables with sensitive data. For example, if you need to retrieve info about some users, don't select all columns on the users table, as it may contain the password as plain text or as an easily attackable unsalted md5.

Be weary that amfphp acts as though magic_quotes_gpc was set to off (the recommended setting). Always escape incoming strings using mysql_real_escape_string before putting them in the database. Try putting double quotes and single quotes in your input data to see if you escaped all data correctly.

Be careful about including files based on strings sent by the user. At a strict minimum, do a str_replace('../', '', $inputString); to make sure the user isn't attempting to include an arbitrary file ouside of the directory you had intended.

Take the browser and the debuggateway.php files off of live servers, and enable the PRODUCTION_SERVER flag in gateway.php. Learn more about deploying here.


© amfphp.org | Disclaimer | Conditions of use