Flex / PHP Security Basics - Part One

http://active6.com/blog/flex/flex-php-security-basics-part-one/

I've been creating Flash / PHP web sites and applications for years, but I am relatively new to Flex. After browsing the Adobe PHP samples for Flex earlier this week, I couldn't help but notice that some of this code could prove extremely hazardous if used in a public Flex site. This is no criticism, but since these examples will be read by virtually anyone who want to use the PHP / Flex tandem, it's probably not a bad idea to go over the security basics. I just love PHP. It's a great language for rapid development of dynamic site and application backends. Combined with the RIA power of Flex 2, there's no end to what you can do. But - as for every web programming language, security considerations for designing even the simplest web sites with Flex and PHP are crucial and often overlooked. This article makes some assumptions that on first look may linger on paranoia, but you should always remember the following when developing PHP / Flex apps:

• It's dead easy to decompile a Flex or Flash file. The file format is public and many decompilers exist.
• It's equally easy to monitor requests and results from a Flex app to and from the server. This and the above make it a breeze to get the URI's and expected parameters for your PHP scripts.
• Most Flex/PHP tandem applications will expect and return clean, simple XML data. This data can be parsed easily to see if any security holes can be exploited.

Many PHP features can lead to security holes. The PHP.net site as well as independent security initiatives (such as phpsec.org, the PHP Security Consortium) have identified a small dozen of "Top Security Blunders" that keep popping up. We'll go over these from a Flex perspective in this article. Understanding each possible flaw will help you avoid making the same mistakes in your PHP applications.

Unvalidated User Input

This may seem paranoid - but one of the most important rules of thumb for web development is that any data sent by a user should be considered as potentially malicious. Ignoring this leads to most of the exploits we'll review. Let's say we want construct a login panel. I've removed the unessential layout code:

[viewcode] src="flexsecurity/flexapp.xml" link="no" showsyntax="no" geshi="actionscript"[/viewcode]

As you can see, the Flex app will send a userid and password to a PHP script for login verification. All seems pretty standard doesn't it? Well - meet SQL Injection.

SQL Injection

SQL injection is essentially unvalidated user input. It allows exploitation of a database query. For example, you would check our Flex app's a userid/password set received against a user table. In MySQL, this would look something like:

SELECT * FROM users WHERE userid='$userid' AND password='$password';

A malicious user could enter "admin" as the userid and the following as his password:

' OR '1'='1

This results in the following query:

SELECT * FROM users WHERE userid='admin' AND pass='' OR '1'='1';

This bypasses validating the password - the user has gained entry as the administrator!

We need to neutralize malicious entries from the submitted values. In many PHP installations, this is already taken care of by the magic_quotes_gpc setting in the php.ini file. You can check this by using the phpinfo() function. In case magic quotes is set to Off, you must use PHP's addslashes() function:

$userid = addslashes($_REQUEST['userid']);
 
$password = addslashes($_REQUEST['password']);

However, there is one unfortunate side-effect to this setting being enabled: every value passed back to your PHP scripts will have slashes added. I won't go into a discussion on what is the best setting here, because it really depends on the system you're building. (You can check the PHP documentation for details).

As a rule of thumb, always check the status of magic_quotes_gpc and, if it is turned on, pass all input through PHP's stripslashes() function. Then apply addslashes() to values for use in database queries.

if (get_magic_quotes_gpc())
 
{
 
 $_REQUEST = array_map('stripslashes', $_REQUEST);

}

SQL injection also allows malicious users to get to your database records. Always check (case-insensitive!) data that will be used in a query for the characters '",;() and for keywords like "FROM", "LIKE", and "WHERE".

Shell Command Injection

Let's assume that you have secured your user login code as detailed above. Once the user has logged in, the Flex app could for example ask for a list of files that was uploaded by the user through a variable called search. The flex side of things would be similar to the example above, so I won't repeat it. The PHP snippet could look something like this:
[viewcode] src="flexsecurity/phpdir.txt" link="no" showsyntax="no" geshi="php"[/viewcode]This PHP code is not secure. The $_REQUEST variable is assigned without any validation. A malicious user might append something like ";rm -rf *" and delete your web site folder. You must ensure that the user input is valid and nothing more than what is expected. Do not only use Flex-based validation for this: there are many HTTP monitors and SWF decompilers readily available to hackers that permit modifying your Flex file. You need to add PHP code to ensure that the information the user provides is valid, like so:

[viewcode] src="flexsecurity/phpsecdir.txt" link="no" showsyntax="no" geshi="php"[/viewcode]

escapeshellcmd() escapes any characters in a string that might be used to trick a shell command into executing arbitrary commands.

OK, that concludes the first part of this article. In part two, we'll go into some other potential security holes like error reporting and safe mode.