Web Application Security Overview

With the web and web sites open to everyone — including malicious hackers — the security of web applications sits at the top of the list of issues on any web developer’s mind. In this eight-part series, we will look at the security concerns of PHP developers, and what they can do to make their web applications more secure.

Introduction

With more and more personal information — such as credit card information, maiden names, passwords, etc. — being stored on the web, any developer(especially a PHP developer) cannot afford to be lax about application security. The most secure website is one that does not have any PHP or CGI or even HTML. But then it would not be a website at all, would it?

The battle for supremacy in web application security is not between hackers and programmers; it is between what you want your web application to do and whether it is safe for it to carry out those tasks. It is always better for a developer to start any project with the knowledge that any application that he  creates will only be as safe as he makes it. It is for this reason that every developer should ensure that he or she stays informed about the latest security threats and to look for possible solutions for these threats if at all possible.

A security plan

When starting a new project a programmer must think of security from the word go. Think of security first, last and in between. Security is abstract in any language, unlike language features such as conditional expressions or loops or any of the other characteristics. Security in a scripting language such as PHP is more developer dependent than language dependent. In other words, although the language offers you the tools to create secure code, it cannot prevent insecure code.

Thus, the degree to which code is secure almost entirely depends on how security conscious and well informed its developer is. If you have developed web applications before, then you will know that nothing is really one hundred percent secure. So everything boils down to three points when developing an application:

  • Identify the needs and potential weaknesses of an application from the word go.

  • Try as much as possible to deal with those weaknesses when programming.

  • Always have a backup plan for when things go pear shaped. And believe me, things do go wrong!

Not all is doom and gloom on the security front. If you know a particular language well, then you will be able to write very secure code that will enable you to sleep well at night, instead of worrying about the new attacks and techniques that are constantly being thrown at web applications. So what does PHP offer in this regard and what can we do to make our applications more secure? There are things that we can do to make our PHP installation more secure. The first thing we need to do is look at the installation itself. In the coming sections we will cover the following:

  • Register Globals

  • Error reporting

  • Code Exposure

There are quite a few other features available that we can look at, but for the sake of brevity we will focus on the above topics because I think these are among the most important ones.

{mospagebreak title=Is your PHP Installation Secure?}

The first thing you should check is your Register Globals. They have to be turned off for security reasons. All PHP developers should know this and make sure that it is the case in their PHP installations. There are two main reasons why this is necessary:

  • If Register Globals are not turned off, they can increase the magnitude of a security vulnerability.

  • Turning Register Globals on hides the origin of data, conflicting with a developer’s responsibility to keep track of data at all times.

So what happens if the register globals are not turned off? Two things happen:

  • It takes care of the complexity of parsing raw form data. This makes working with form data considerably easier for the developer, but at the expense of control.

  • Global variables are created from numerous remote sources. This makes tracking variables very difficult, and from a security point of view this is a huge risk.

It is worth pointing out that register globals on their own do not necessarily create a security vulnerability; the vulnerability usually comes as a result of the developer making a mistake. You should still ensure that your register globals are turned off for both security reasons and also for portability issues. Most production environments will have their register globals turned off, and if your applications were created with register globals turned on, they will be unusable in those environments.

On a precautionary note, if you develop applications that you think will be deployed in an environment where register_globals are enabled, then make sure that you initialize all variables and set error reporting to E_ALL or E_STRICT. This is to alert yourself to the use of uninitialized variables, as any use of uninitialized variables is almost always a security risk when register_globals are turned on.

So where do you turn off register globals? Simply open up your PHP ini file and set register globals to off. Below is an extract from my PHP configuration file with register globals set to off:

; You should do your best to write your scripts so that they do not require

; register_globals to be on; Using form variables as globals can easily lead

; to possible security problems, if the code is not very well thought of.

register_globals = Off

{mospagebreak title=Error Reporting}

Another area in which security vulnerabilities are common is error reporting. Every developer makes mistakes, and while most mistakes are harmless, some can also be a security risk. So, in the interest of writing efficient, and risk free code, I would suggest that error reporting be turned on. This is particularly useful at the development stage of a project and will enable you to effectively debug code before deploying it.

PHP provides detailed information, and this information can be a security risk. So it is important to hide this information from the public. You can simply do it by setting display_errors to off. Below is an extract of my PHP configuration file(php.ini) showing display errors set to off:

display_errors = Off [Security]

; With this directive set to off, errors that occur during the execution of

; scripts will no longer be displayed as a part of the script output, and thus,

; will no longer be exposed to remote users. With some errors, the error message

; content may expose information about your script, web server, or database

; server that may be exploitable for hacking. Production sites should have this

; directive set to off.

But how will you be able to see what errors are in your code? Well, the safest way would be to make PHP write those errors to a log. You do this by setting log_errors to on and indicate the location of the log with error_log.

Because the level of error reporting can cause some errors to be hidden, you should turn up PHP’s default error_reporting setting to at least E_ALL ( E_ALL | E_STRICT is the highest setting, offering suggestions for forward compatibility, such as deprecation notices).

PHP error reporting is such that all error-reporting behavior can be modified at any level, so if you are on a shared host or are otherwise unable to make changes to files such as php.ini, httpd.conf, or . htaccess, you can implement these recommendations with code similar to the following:

<?php


ini_set(‘error_reporting’, E_ALL | E_STRICT);

ini_set(‘display_errors’, ‘Off’);

ini_set(‘log_errors’, ‘On’);

ini_set(‘error_log’, ‘/usr/local/apache/logs/error_log’);


?>

Another feature of PHP error reporting is that it allows you to handle your own errors, with the set_error_handler() function:

<?php

set_error_handler(“my error handler”);

<?

This allows you to define your own function ( my_error_handler( ) ) to handle errors; the following is an example implementation:

<?php


function my_error_handler($number, $string, $file, $line, $context)

{

$error = "= == == == ==nPHP ERRORn= == == == ==n";

$error .= "Number: [$number]n";

$error .= "String: [$string]n";

$error .= "File: [$file]n";

$error .= "Line: [$line]n";

$error .= "Context:n" . print_r($context, TRUE) . "nn";


error_log($error, 3, ‘/usr/local/apache/logs/error_log’);

}


?>

{mospagebreak title=Data Exposure}

Finally, let’s take a brief look at another area of security risks: data exposure. This is a common security risk, especially when it comes to SQL queries. When it comes to retrieving data from a database, you should only retrieve the information that you require. This way you minimize the risk of data being exposed unnecessarily. For example:

<?php

$query = “SELECT name,surname from usertable WHERE name=”‘.$_POST['uname'].”‘ AND surname='”.$_POST['usurname'].”‘”;

<?

The above query only exposes two fields of the database and actually only retrieves data that is required as opposed to the query below that exposes a lot more data:

<?php

$query = “SELECT * from usertable WHERE name=”‘.$_POST['uname'].”‘ AND surname='”.$_POST['usurname'].”‘”;

<?

The second query actually retrieves a lot more data than is required. Thus the risk of data exposure is higher.

Conclusion

In the next few articles we will explore the remaining areas of security vulnerabilities.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye