Flex / PHP Security Basics – Part One

Written by Bob de Wit. Posted in Developer Blog, Flex, PHP

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: <?xml version=”1.0″ encoding=”utf-8″?> <mx:Panel xmlns:mx=”http://www.adobe.com/2006/mxml” title=”Login Form”> <mx:Label text=”User ID:” /> <mx:TextInput id=”userid” editable=”true” enabled=”true” /> <mx:Label text=”Password” /> <mx:TextInput id=”password” displayAsPassword=”true” editable=”true” enabled=”true” /> <mx:Button label=”Login” id=”buttonLogin” enabled=”true” click=”buttonLoginClick();” /> <mx:HTTPService id=”userLogin” url=”http://localhost/flex/php/login.php” useProxy=”false” method=”POST” result=”userLoginHandler(event)”> <mx:request xmlns=”"> <userid>{userid.text}</userid><password>{password.text}</password> </mx:request> </mx:HTTPService> <mx:Script> <![CDATA[ import mx.rpc.events.ResultEvent; import mx.controls.Alert; private function userLoginHandler(event:ResultEvent):void { if ( event.result.userLogin.loginresult == 0 ) { Alert.show( "Login Failed" ); } else { Alert.show( "Login Succeeded" ); } } private function buttonLoginClick(): void { userLogin.send(); } ]]> </mx:Script> </mx:Panel> and here’s the corresponding simplified login.php code: <?php $search= $_REQUEST['search']; $dir= dir( $search ); ?> 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: <?php $search= escapeshellcmd($_REQUEST['search']); ?> escapeshellcmd() escapes any characters in a string that might be used to trick a shell command into executing arbitrary commands.

SQL Injection

SQL injection is another type of unvalidated user input. It allows exploitation of a database query. For example, you would check 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 name=’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-effects 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”. 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.

Trackback from your site.

Comments (21)

  • doof

    |

    great little heads up article. thanks. but is part 2 on it’s way anytime soon?

    Reply

  • umesh

    |

    Good Article :)

    Reply

  • Rafael Ochoa

    |

    Ok this is scarry…. I don’t know but I don’t understand very well webOrb…. the website is really confusing… there is gonna be a par 2 of these article? very good article by the way

    Reply

  • mallsop

    |

    Nice article.

    For logins, speaking about php, once the user has authenticated onseself via login, you can set a session username variable and hash with php and recheck that variable per page. If the user does not have that variable set, then kick then back to the login page.

    Reply

  • Fahim Ilyas

    |

    I think this scenerio is valid if you r requesting HTTP Service in flex using POST or GET Methods. If you are using amf which is available in weborb and amfphp to send request, things get little easier…

    Reply

  • satheesh

    |

    i want flex3 login page with php.. i try this one but i cant get answer … please post flex3 login page with php..

    Reply

  • coolness

    |

    wow!! this is such a great and helpful for our project, thnx for sharing your code..^^

    Reply

  • Billigflüge

    |

    It´s a pitty, you aren’t around here. But your new Blog is great as well. Great programming, looks nice!

    Reply

  • Armando Wall

    |

    These are not Flex security issues. At the least, it would be a PHP issue, not Flex. At most, it’s an issue with sloppy programmers. What you are describing could happen with Javascript (AJAX), online Java applications, Ruby, Perl, you name it. My point is: it’s the responsibility of the programmer to make sure the application is secure. Otherwise, the platform can encourage all the security in the world, but it will ultimately fail under the developer’s incompetence.

    Reply

  • Bob de Wit

    |

    As the title says, it’s Flex/PHP security issues. My point is that Flex is great, but you will still need a back-end engine to serve things up. Many Flex developers will use PHP and not necessarily be aware of the issues I listed. Of course there are pure Flex security issues as well (like decompilers), but that wasn’t the topic of the article. And I would say it’s the responsibility of the designer as well as the programmer, which is not necessarily the same thing.

    Reply

  • Brasilien

    |

    great and helpfull, thanks!!

    Reply

  • How to Get Six Pack Fast

    |

    If you ever want to read a reader’s feedback :) , I rate this article for four from five. Detailed info, but I just have to go to that damn google to find the missed parts. Thanks, anyway!

    Reply

  • Wasserbetten

    |

    Thanks for sharing that! I found flex is a really powerfull tool and many websites can’t be without it anymore!

    Reply

  • Lovra

    |

    That article is very usefull for me. Thanks

    Reply

  • Robbie Benningfield

    |

    Hello, I belive this is a really great web pages with impressive stuff. That may be why I are going to ask you if I can speak about your blog on my website if I offer you hyperlink back?

    Reply

  • Darki699

    |

    Just create a function:

    function POST($param)
    {
    // 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”.
    $value = $_POST[$param];
    $invalidChars = array(“‘”, ‘”‘, “,”, “;”, “(“, “)”, “FROM”, “LIKE”, “WHERE”, “=”);
    $result = str_ireplace($invalidChars, “”, $value);
    return $result;
    }

    and instead of the regular $_POST['password'] call POST(‘password’) ;)

    Reply

Leave a comment