#native_company# #native_desc#

Security Concerns when Developing PHP Applications

By PHP Builder Staff
on December 4, 2009


Security concerns are always important when developing applications. With PHP I tend to find myself considering security more, not because there is anything wrong with PHP, but because PHP’s simplicity is its own downfall; it is easy to put speed of development before security issues. However, over the years I have come to trust a few ideas and concepts of PHP as safe, and, while I do not in any way pretend that these are foolproof, they definately help me to keep in mind that security on the internet is somewhat problematic. Allow me to share these things with you.
One security flaw is so easily overlooked: using POST to transfer information wherever possible, as opposed to using GET. GET is somewhat less secure than post simply because GET is easier to emulate than POST. I can just change the url in my browser to make it emulate a GET request. A POST request usually requires a form to be submitted, which is slightly harder–but not inpossible–to emulate. Specifically on things such as login forms and such, be very careful not to use things like “login.php?username=marc&password=hackme” wherever possible.
Validation is important, and validation is not just about checking if form values are null or not. Firstly, forms should be properly validated to check that all POSTED values are of the correct type, expected length, format, etc. But more than that, it is not only forms that need to be validated. Any data passed from one page to another should be checked for integrity, because that is exactly how security violations happen.
PHP Sessions are there for a reason, USE them. If you don’t already know, the reason why GET, POST and SESSION exist is because PHP is not like a solid state, always-ready system like JAVA. I’m sure you are aware that PHP compiles at runtime, and only really executes for a few split seconds while the page is actually loading. Then it is dead, a closed thing that can only be accessed when the next page loads. So the creators of PHP had to devise a way of moving information between these pageload events, and that is where SESSION, GET and POST come in. It makes absolutely no sense at all that we have a page that only exists in one state for a fraction of a second before dying, so we can use these features to pass information from one pageload to the next, or even store data for a few hours–in a SESSION Array. Sure, you can use ajax to reload a certain part of a page, but all you are doing is loading a different page inside the one you have already loaded. There is no way you can actively revive the information in the page without these transfer systems that have been built into PHP–but it is also important to understand which to use when.
$_GET: Essentially this is for navigation, passing values through the url, such as simple information regarding the URL we are currently viewing.
$_POST: POST is the best way of submitting values from a form. POST values do NOT get carried along in the URL, so they are harder to see and catch. Generally you need a server-side script to catch the values, which makes it the preferred method of form submission, especially where sensitive information is being submitted.