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.
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 inherently 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.
Basic security tips
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
It is also advised to remove any unnecessary files and plugins. For example the Back Office should be used locally as it is useful for development purposes but should if you don’t need it there don’t put it on a production server as it allows people to test your services and would allow them to gain information about your server configuration, services, etc. To do so simply delete the Back Office folder.
The 2 Amfphp plugins used by the Back Office specifically are AmfphpMonitor and AmfphpDiscovery. These can be deleted in the Amfphp/Plugins folder or disabled in the configuration.
Use the Authentication plugin mechanism to log in or log out users, and protect them for accessing certain resources.
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.
– If you do not want other sites to load your services (leeching) and you are using Apache, you can set up a .htaccess file to redirect undesirable calls to a dead-end. Read about using mod_rewrite to stop leeching.
– The config class has the line
$this->sharedConfig[self::CONFIG_RETURN_ERROR_DETAILS] = true;
Set it to false, as otherwise an exception sends back information about your server.