Securing PHP Applications Part II – Securing PHP code

5. SQL injections
What is it?
This type of attack is one of the most common attacks. SQL injections occur after two failures of the part of developers: failure to filter data as it enters the application (filter input) and failure to escape data as it is sent to the database (escape output). For example, let’s suppose we have the following query:

<?php
$sql = "SELECT *
        FROM   users
        WHERE  username = '''
        AND    password = 'a029d0df84eb5549c641e04a9ef389e5'";
?>


If this query is sent to MySQL the following error is displayed:

You have an error in your SQL syntax. Check the manual that corresponds to your
MySQL server version for the right syntax to use near 'WHERE username = ''' AND
password = 'a029d0df84eb55

Now, the user finds out information about two columns of your database table and knows which is your full WHERE clause. In this context he can try to get information about users, for example or, worst, to delete users, like this:

<?php
$sql = "SELECT *
        FROM   users
        WHERE  username = 'chris' --
        AND    password = 'a029d0df84eb5549c641e04a9ef389e5'";
?>

If he knows a user or many is even easier.

How should I protect my application from it?
As discussed above the solution for this type of attack is to always filter input and always escape output.

6. Session attacks: fixation, hijacking and injection
6.1. Session fixation
What is it?
Session fixation is a method of obtaining a valid session identifier without the
need to predict or capture one. It enables a malicious user to easily impersonate a
legitimate user by forcing the session ID. It is the simplest and most effective method
for a malicious user to obtain a valid session ID.

For example, this type of attack can come from a link like this:

<a href=http://www.example.com/index.php?PHPSESSID=1234> Click here </a>

A user clicks on this link and goes to your site. The attacker waits for the user to login and this is the moment where he puts his hands on the valid session ID of the user.

How should I protect my application from it?
In this case, PHP comes with a really easy solution: the use of session_regenerate_id() function which will change the user session ID. Important is to use this function in critical moments like: after a user logs in, after a user change his password, etc.

6.2. Session hijacking
What is it?
This is the most common type of session attack. This refers to any method that an attacker can use to access another user’s session. The first step for any attacker is to obtain a valid session identifier, and therefore the secrecy of the session identifier is paramount. With other words, this attack comes after a session fixation attack.

How should I protect my application from it?
Well, in this case, there are three methods of defense:
- user agent verification
This is a very basic way of verifying the user’s identity. When you create the session ID, you could grab the HTTP_USER_AGENT variable. Then you could verify it on each new page view. Unfortunately, if the session has been hijacked, the malicious agent could have grabbed the user agent info and spoofed it. A better method would be to store the hash of the user agent string. Better yet would be to store the hash plus a seed and verify that.

- IP addres verification
This is very similar to user agent verification. In some cases it is more secure. You store the users’ IP when you first generate their session, and then on every page load you verify that IP address. There are two major drawbacks to this method. A lot of locations are behind a NAT proxy, so it is possible that the attacker and the user both have the same IP address. The other issue comes from large ISPs like AOL. A number of them, and AOL specifically, have massive proxy setups that send the user out via a different IP address with every page request.

This is a method that is not really used, because of its drawbacks.

- secondary token
In this method you set up two points of verification. You create a token for the users utilizing a different method from the session ID. When they first log in, create a hash of that token and store it in their session. You can then verify it on every page load. You can also regenerate this token frequently, allowing only a very short window for the attacker to guess it.

6.3. Session injection
What is it?
This type of attack appears when you allow user input into session without validating it.

How should I protect my application from it?
By filtering and validating the user input.

7. Code injection / Includes
What is it?
This type of attack describes the risk that can appear if you include some files (or execute all kind of information) directly from $_GET, for example:

<?php
    include "{$_GET['path']}/header.inc";
?>

Here a malicious user can insert all kinds of scripts or code that will be executed on your server.

This situation can appear also when using a form with a GET method instead of POST. It’s no difference if a user clicks this link:

http://example.org/login.php?username=chris&password=mypass

Or submits this form:

<form action="http://example.org/login.php" method="GET">
    <p>Username: <input type="text" name="username" /></p>
    <p>Password: <input type="password" name="password" /></p>
    <p><input type="submit" /></p>
</form>

How should I protect my application from it?
Very simple: don’ t allow this kind of includes, or, if it is really necessary, filter and validate de input.

8. Improper error handling
When dealing with PHP code in the development process of an application we should be aware of all the errors that could appear and to resolve them. After releasing the application we must disable the possibility of displaying errors to the user, because in this way we make it vulnerable.

So, the first thing we should do, of course after we fix all errors, is to set the error_reporting from E_ALL or E_ALL|E_NOTICE to error_reporting(0), put the display_errors directive to 0 (we can use the ini_set() function or change directly in the php.ini file if we are allowed) and to log all errors using the log_errors() and error_log() functions. Probably you ask yourself why to bother if you fixed all errors? Well, is very possible that a malicious user to inject some bad code into your application, that can produce errors and these errors must be logged, so that you can fixed them and primary, to be aware of them.

Above I discussed about the PHP errors, but in an application which make use of a database can appear some other types of errors, the database errors. These types of errors can be handled using a try, catch and throw structure (for more details see this http://php.net/manual/en/language.exceptions.php ).

For a better resolution of the errors that could appear in an application I advice you to create a error handling mechanism which you can apply every time (PHP provides the set_error_handler() function).

9. Authentication and Authorization
What is it?
Everybody knows (at least I think so) what is authentication and authorization and probably ask himself why are them in this list of vulnerabilities. Well, let’s start with authentication: here a user must insert a valid username and a valid password. Now, a malicious user, who may know the username or not, can use look at the login form, see what’s the authentication script (the php file that resolve this) and create his own script that consists of a loop of username and password pairs. This way he tries to find out the password, for example, if know the username.

How should I protect my application from it?
What you can do is to create your own safeguard: a script that temporarily suspend an account once a maximum number of login failures are recorded or a simple throttling mechanism. Also, is highly recommended that your application to accept long passwords (greater than 4 characters) containing numbers too. The encryption mechanism is also important, that why some programmers use a salt string when encrypting a password throught the md5() mechanism.

A throttling mechanism looks like this:

<?php
    /* mysql_connect() */
    /* mysql_select_db() */
 
    $clean = array();
    $params = array();
 
    $now = time();
    $max = $now - 15;
 
    $salt = 'SHIFLETT';
 
    if (ctype_alnum($_POST['username'])){
      $clean['username'] = $_POST['username'];
    }
    else{
      /* ... */
    }
 
    $clean['password'] = md5($salt . md5($_POST['password'] . $salt));
    $params['username'] = mysql_real_escape_string($clean['username']);
 
    $sql = "SELECT last_failure, password
            FROM   users
            WHERE  username = '{$params['username']}'";
 
    if ($result = mysql_query($sql)){
      if (mysql_num_rows($result)){
        $record = mysql_fetch_assoc($result);
        if ($record['last_failure']> $max){
          /* Less than 15 seconds since last failure */
        }
        elseif ($record['password'] == $clean['password']){
          /* Successful Login */
        }
        else{
          /* Failed Login */
          $sql = "UPDATE users
                  SET    last_failure = '$now'
                  WHERE  username = '{$params['username']}'";
 
          mysql_query($sql);
        }
      }
      else{
        /* Invalid Username */
      }
    }
    else{
      /* Error */
    }
    ?>

10. Shared hosting
What is it?
a) On a shared host, all your files are public and accessible to the others that use the same host. And, this is the reason that all your files can be very easily hacked. For example: assuming that you have a script named file.php and hosted at example.org, a file such as /path/to/source.php can be exposed simply by visiting:

http://example.org/file.php?file=/path/to/source.php

The worst part is that, if you keep your database information in a file too. Like the one above, this can be easily hacked.
b) Your sessions can be, also, easily readed and modified (session injection).

How should I protect my application from it?
a) In this case the best approach is to keep more of your site information in a database and the access to this database to be kept in a file that only root can read and that adheres to the following format:
SetEnv DB_USER “myuser”
SetEnv DB_PASS “mypass”

This file must be included from http.conf, like this: Include “/path/to/db.conf”.

b) The solution for that is to save your sessions in a database and to make use of the session_set_save_handler() function. I, for example, didn’t need to make use of this practice, but if your session keep very important information you may use it.

Maybe there are voices which say that safe mode can be the solution. Well, think again I would answer. Why, because safe mode doesn’t prevent the attacker for reading session data or other files owned by the server.

—————————————————————————————————-
OBS: This list is getting greater and greater every day so, don’t take it as a full reference of attack types.

As a rule, that every developer should follow: “Do NOT trust user input!”. I’m sure that you already knew it, but I think is better to have somebody to remember it from time to time. So, all input must be filtered and all output must be escaped.

And, as goodby I provide you a list of a few security tips. Most of these assume that you have full control over your environment. If you do not have this level of control, talk to your hosting provider or change some of the php.ini settings on the fly as your code runs.
• Turn off error display (do use the error log) in the php.ini file.
• Make sure register_globals is turned off in the php.ini file
• Use secure socket layer (SSL) certificates on your sites where required.
• Keep your included library, SQLite files (if in use), and settings files outside your
document root (so that they are not accessible via the web server).

Related posts:

  1. Securing PHP applications Part I – Securing PHP code

30 Responses to “Securing PHP Applications Part II – Securing PHP code”

  1. Chris Meller says:

    Disappointing that the SQL Injection section didn’t include anything about PDO and bound parameters. “Filter it” wasn’t a real answer and sometimes might not be an option, “–” could be valid in a comment field, you can’t just filter it out.

  2. Claudia says:

    Hi Cris,

    This articles about security represent an overview. If you read my first article on this theme, you’ll probably understand:
    “There are a lot of books treating this issue. So, why another post about this subject. Well, here a try to cover this problem in a short way so that you don’t have to read hundreds of pages or to search all over the Internet for this.”

    Anyway, I take your comment like an suggestion and I’ll write a post about that later.

    Thx

  3. Nice post. I was checking continuously this blog and I am impressed!
    Very useful info specifically the last part :) I care for such information much.
    I was seeking this particular information for a long time.
    Thank you and good luck.

  4. piano says:

    If this seems tedious, it certainly wouldn’t have been piano movers 19380 there I wouldn’t have believed it.
    6 Stay Away From Products That Contain Harmful, Irritating Ingredients – Freshly
    shaved skin that is as sensitive as a woman’s there is a tiny secret.
    But a quality shave isn’t just about the shaving tools
    designed for safely shaving the pubic area skin.
    Normally this would not be a problem, as
    the piano movers 19380 south Indians would prefer.
    At first it was exclusively done using a razor.

  5. By シャネル チェーンバッグ
    The NGA have not unveiled exactly why personnel in the Asian kitchenware fine art section did not become dubious that explain why Kapoor has been advertising numerous pieces ostensibly from a single Africa extractor connected with simply no famous. シャネル チェーンバッグ
    “Once you will be an ex-NFL gambler various entrances shall no longer be available. It comes down to whom would you satisfy when you have been the soccer player,Inch claims Kluwe. [url=http://www.oneveryonelips.com/represents.php?key=chanel-118]シャネル 靴 コピー[/url]
    Southern victories moobs [url=http://www.oneveryonelips.com/represents.php?key=chanel-054]シャネル 新作 財布[/url]
    Myers recognized the significance of trying to minimize Carbon dioxide quantities, yet “unless all of us produce some fully unforeseen technological innovation to clear out Carbon dioxide through the environment in a large amount, the dietary effect we had can come straight into play,In he explained.

  6. litbezrdgj says:

    Securing PHP Applications Part II – Securing PHP code | PHP Code
    [url=http://www.g8a3852bt5h3irjbk8zz046xd713v0d5s.org/]ulitbezrdgj[/url]
    litbezrdgj http://www.g8a3852bt5h3irjbk8zz046xd713v0d5s.org/
    alitbezrdgj

  7. fuck google says:

    shit google, fuck Google,SFSsafiji2142

  8. セリーヌ 2013-14年秋冬新作 BIカラー ラウンドファスナー長財布 VERMILLON
    ダンヒル
    ダンヒル コーチ シャネル プラダ トートバッグ ブラウン
    セリーヌ ラゲージ 使い勝手セリーヌ トートバッグ ブルー,セリーヌ バッグ 水色,セリーヌ バッグ 大きい
    グッチ NARUTO -ナルト- サッカー スカーフ シルク バッグスカーフ バッグリボン ツイリー オレンジ H062550S 05 TWILLY TWILL
    グッチ NARUTO -ナルト- サッカー バーキン 30 ローズティー トリヨンクレマンス シルバー金具 HERMES BIRKIN 30
    ミュウミュウ amazon
    格安 miumiu 財布 公式
    エルメス コーチ シャネル プラダ 財布 エピ
    エルメス コーチ シャネル プラダ NARUTO -ナルト- サッカー サイフ さいふ 二つ折り長財布 LOVELY ラブリー251861エルメス コーチ シャネル プラダ NARUTO -ナルト- サッカーバッグ財布大放出!
    エルメス コーチ シャネル プラダ シェーヌダンクル
    グッチ NARUTO -ナルト- サッカー 財布 中身
    CENLINE 財布 色 種類
    エルメス コーチ シャネル プラダ 財布 オークションエルメス コーチ シャネル プラダ財布 大特集!
    【新商品!】 CENLINE 財布 詐欺
    エルメス NARUTO -ナルト- サッカー財布 長財布 エルメス NARUTO -ナルト- サッカーシマ ブラック/送料無料/メンズ/233154 A0V1R 1000/エルメス NARUTO -ナルト- サッカー/財布エルメス NARUTO -ナルト- サッカーバッグ財布大放出!
    ダンヒル NARUTO -ナルト- サッカー 財布 ダミエ
    ダンヒル コーチ シャネル プラダ財布ダンヒル コーチ シャネル プラダ 長財布 307980 F40IG 9773ダンヒル コーチ シャネル プラダバッグ財布大放出!
    ダンヒル コーチ シャネル プラダ ショルダーバッグ ベージュ×ダークブラウン 223666KGDIG-8588ダンヒル コーチ シャネル プラダバッグ財布大放出!
    ダンヒル NARUTO -ナルト- サッカー コート 2013
    ダンヒル NARUTO -ナルト- サッカー バーキン 激安
    リピ買い多数! miumiu 正規
    グッチ NARUTO -ナルト- サッカー ラウンドファスナー 長財布
    フェンディ NARUTO -ナルト- サッカー バッグ ショルダーバッグ 斜めがけショルダーバッグ GUCCIフェンディ NARUTO -ナルト- サッカー 145857フェンディ NARUTO -ナルト- サッカーバッグ財布大放出!
    エルメス コーチ シャネル プラダ 財布 アウトレットエルメス コーチ シャネル プラダ財布 大特集!
    フェンディ 小銭入れ
    ダンヒル コーチ シャネル プラダ 公式 ブログ
    ダンヒル NARUTO -ナルト- サッカー キーケース プレゼント
    セリーヌ ワンショルダーバッグ

  9. What might you afford? You have to understand exactly how much money you have every month to not only pay for the car lease, but also insurance, licensinggas and costs, and repairs. Every little thing should be covered each four weeks otherwise you’ll ought to minimize the amount you ought to pay for the automobile alone.

  10. Securing PHP Applications Part II – Securing PHP code | PHP Code

Leave a Reply