Securing PHP Web Applications

In this article, I'll discuss and demonstrate some common web-application security flaws and then show you how to detect them. Hopefully by the time you're done reading this, you'll be aware of at least some of the most common ways that an intruder will try to break through your code and get unauthorized access to your application.

Let's start by looking at some common web-application security flaws that can be tested relatively easily. The most common security flaw revolves around the sanitization of input, or "input validation."

Input Validation

Consider a 'login.php' script that authenticates access to a web site. Suppose this script accepts two parameters, a username and a password , via the HTTP POST method. Included in the source code of this script may be an actual authentication check, as follows:

Looks pretty simple? Suppose a user were to input admin in the username field of the login form, and the following in the password field:

Now, the $sqlquery variable will hold the following value:

When the above query executes, the user will be allowed to login as admin . The reason for this is pretty obvious. The SQL query will always return true because of the additional or 'a'='a' clause, which is of course always true: 'a' will always be equal to 'a' .

This act of injecting SQL queries into web apps that do not perform proper sanitization of HTTP parameters is known as "SQL injection", and it is one of the most common web application security holes.

Another thing to consider is that most programming languages support a function call that allows for the execution of external programs. Many poorly designed web applications sometimes fail to perform input validation on parameters that are passed into calls, such as system() . For example:

If $i were a parameter accepted from the user, then a malicious user may enter the following value:

for the value of $i . This would cause the preceding system call to execute the following:

Thus displaying the /etc/passwd file instead of a static value of $i .

Sanitizing user input can help to prevent input validation vulnerabilities. Web app developers should watch out for and filter out the following characters:

In addition, to have PHP escape your GET and POST parameter input strings automatically, edit your php.ini file to set the value of magic_quotes_gpc to On . This has further implications, so please review the PHP manual appropriately.

Sessions

Since HTTP is not a stateful protocol, the web application must provide any session management it needs. Many sessions use client-side cookies to maintain state. A client-side cookie is a piece of information requested by the web application to be stored on the end user's hard disk. Since these cookies are stored on user's disks, users or other programs can alter them, so they're inherently insecure and untrustworthy. Poorly designed web applications often trust client-side cookies, allowing potential compromises of the web application's authentication mechanism. Consider a cookie with the following data:

A malicious user may attempt to alter this cookie and place admin or root in the user field and have access to a higher privileged account.

A web application may also maintain state by embedding session information in the URL:

Often, web apps provide session IDs sequentially. This would allow the user john to brute-force session values of lower than 12345678 to hijack sessions of users that have logged on before him. The best way to do cirumvent this is to enable PHP Session ID's, which are random MD5-encrypted strings and are not in any sequential order, thus making them a lot harder to replicate and imitate.

Hidden HTML Elements

These are static elements contained in web forms. These values are usually not displayed by the client, but are merely used to pass information back and forth between different web forms via POST requests. Here is an example of an HTML code that defines a hidden element:

The problem in this example is that a malicious user may alter the HTML and submit any value he or she wishes. Often, web applications are designed to trust client-side input fully. So, in our example, a malicious user may use a web proxy server to alter the value of shippingcharges that is submitted to the purchase form. Imagine what would happen if a user were to submit a value such as "-100". Assuming that the web application blindly accepts this value, the user will most likely end up with a credit on his credit card!

Note: The above is only a list of some web-application security flaws that can be rather easily tested. It should by no means be considered an exhaustive list of all possible web-application security vulnerabilities, primarily because there are too many to list.

Conclusion

It is very important to consider security when developing any sort of application, let alone a web application that is open and exposed for the whole world to see. If you don't take measure to secure your program, you run the risk of exposing your company's data, or even worse, your customer's data which in turn makes you, the developer, potentially liable for any losses that may be incurred.

It not only makes programming sense, but it is extremely benefitial to your business to advertise that you take Web Application Security very seriously.

That's all for today. I hope that I've jogged your interest just a little bit, and hopefully you will go on your own search for potential security flaws in your web apps.