PHPコードの監査

この文書は昨年作成されたものであり、十分に書かれていない部分もあります。

owasp コードレビューといえば、2.0 がリリースされる時期が来ました。

牛たちが通りかかり、アドバイスをしてくれました。

目次

1. 概要3

2. 入力検証と出力表示3

2.1 コマンドインジェクション4
2.2 クロスサイトスクリプティング4
2.4 コードインジェクション5
2.5 SQL インジェクション6
2.6 XPath インジェクション6
2.7 HTTP応答分割 6

2.8 ファイル管理 6
2.9 ファイルアップロード 7
2.10 変数カバレッジ 7
2.11 動的関数 7

3. セッションセキュリティ 8

3.1 HTTPOnly 設定 8

3.2 ドメイン設定 8
3.3 パス設定 8
3.4 クッキー期間 8
3.5 安全な設定 8
3.6 セッション固定 9
3.7 CSRF 9

4. 暗号化 9

4.1 パスワードを平文で保存する 9

4.2 弱いパスワード暗号化 9
4.3 攻撃者がアクセスできる場所にパスワードを保存するファイルが到着しました 9

5. 認証と認可 10

5.1 ユーザー認証 10

5.2 関数またはファイルへの認証されていない呼び出し 10
5.3 パスワードのハードコーディング 10

6. ランダム関数 10

6.1 rand() 10

6. 2 mt_srand()および mt_rand() 11

7. 特殊文字とマルチバイト エンコーディング 11

7.1 マルチバイト エンコーディング 11

8. PHP の危険な関数 11

8.1 バッファ オーバーフロー 11

8.2 session_destroy() によるファイルの削除脆弱性 12
8. 3 unset()-zend_hash_del_key_or_index 脆弱性 12

9. 情報漏洩 13

9.1 phpinfo 13

10. PHP 環境 13

10.1 open_basedir 設定 13

10.2allow_url_fopen 設定 13
10.3allow_url_include設定13
10.4safe_mode_exec_dir設定14
10.5magic_quote_gpc設定 14
10.6 register_globals 設定 14
10.7 セーフモード設定 14
10.8 session_use_trans_sid 設定 14
10.9 display_errors 設定 14
10.10 Expose_php 設定 14

概要

1. コードレビューはアプリケーションの体系的なレビューです。ソースコード 動作を確認します。その目的は、開発段階でアプリケーションに存在する抜け穴やプログラム ロジック エラーを見つけて修正し、企業に不必要なリスクをもたらすプログラムの脆弱性の不正使用を回避することです。

コードレビューは単にコードをチェックするだけではなく、コードが情報やリソースを安全に保護できるかどうかを確認するためのものであるため、アプリケーション全体のビジネスプロセスを理解し、可能性を制御することが非常に重要です。リスク。レビュー担当者は、以下のような質問を使用して開発者にインタビューすることで、アプリケーション情報を収集できます。

アプリケーションにはどのような種類の機密情報が含まれていますか?また、アプリケーションはこの情報をどのように保護しますか?

アプリケーションは内部または外部にサービスを提供しますか?誰がそれを使用しますか? 彼らは全員信頼できるユーザーですか?

アプリケーションはどこにデプロイされていますか?

企業にとってアプリケーションはどの程度重要ですか?

最善の方法は、チェックリストを作成し、開発者に記入してもらうことです。チェックリストは、アプリケーション情報と開発者が作成したコーディングのセキュリティをより直観的に反映できます。データ検証、ID 認証、セッション管理、認可、暗号化、エラー処理、ロギング、セキュリティなど、重大な脆弱性がある可能性のあるモジュールをカバーする必要があります。構成、ネットワーク アーキテクチャ。

2. 入力の検証と出力の表示

ほとんどの脆弱性の主な原因は、入力データが安全に検証されていないか、出力データが安全に処理されていないことです。

1.完全に一致する

2. ホワイトリストからのデータを受け入れる

3. ブラックリストからのデータを拒否する
4. ブラックリストに一致するデータをエンコードする

PHP でユーザーが入力できる変数のリストは次のとおりです:

$ _SERVER

$ _GET

$_POST

$_COOKIE

$_REQUEST

$_FILES

$_ENV

$_HTTP_COOKIE_VARS

$_HTTP_ENV_VARS

$_HTTP _GET_VARS

$_HTTP_POST_FILES

$_HTTP_POST_VARS

$_HTTP_SERVER_VARS

これらの入力変数がチェックされます

1. コマンドインジェクション

PHP は次の関数を使用してシステムコマンドを実行できます: system、exec、passthru、"、shell_exec、popen、proc_open、pcntl_exec

これらの関数を検索しますすべてのプログラム ファイルを確認し、外部からの送信によって関数のパラメーターが変更されるかどうかを判断し、これらのパラメーターが安全に処理されたかどうかを確認します。

予防方法:

1. カスタム関数または関数ライブラリを使用して、その関数を置き換えます。外部コマンド

2. コマンド パラメータを処理する関数

3. 実行可能ファイルのパスを指定するために、safe_mode_exec_dir を使用します

2. クロスサイト スクリプティングユーザーが受け入れられて処理され、出力がクライアントに直接表示されます。ストレージ このタイプのクロスサイトは、ユーザーによって送信された変数が処理されてデータベースに保存され、その後、情報がデータベースから読み取られて、クライアントへの出力はよく使用されます: echo、print、printf、vprintf、< %=$test%>

リフレクティブ クロスサイトの場合、出力はすぐにクライアントに表示されます。現在のPHPページで変数が顧客によって送信された直後に表示されるかどうか、および変数がこのプロセス中に表示されるかどうかを確認します セキュリティチェックに合格しました

ストレージ型クロスサイトの場合、変数をデータベースに入力して表示用に出力するプロセスで、変数がセキュリティチェックに合格しているかどうかを確認します。

防止方法:

1. 入力データに文字と数字のみが含まれている場合は、特殊文字をブロックする必要があります

2. 電子メール形式、ユーザー名には英語または中国語、アンダースコアのみが含まれるなど、入力データと厳密に一致します。 、ハイフン

3. 出力の HTML エンコード、エンコード仕様

( (

) )

" "

' ..完全に一致するようにデータを入力します。たとえば、変数の値に基づいて言語 en.php と cn.php を決定し、これら 2 つのファイルを同じディレクトリ ' language/'.$_POST['lang'] に配置します。 .'.php', 次に、送信されたデータが en か cn かをチェックするのが最も厳密です。

2. パラメーターに /、.. およびその他の文字が含まれているかどうかをチェックすることもできます。

4. コードインジェクション

コードインジェクションは PHP 関数で発生する可能性があります: eval、preg_replace+/e、assert、call_user_func、call_user_func_array、create_function

プログラム内でこれらの関数が使用されている場所を見つけ、送信された変数がユーザー変数であるかどうかを確認します。制御可能か、入力検証の有無

防止方法:

1.入力データの完全一致

2.実行可能関数をフィルタリングするホワイトリスト方式

5.SQLインジェクション

SQLインジェクションはデータベースの操作を必要とするため、一般的にSQL ステートメントのキーワードを検索します: 挿入、削除、更新、選択、チェック 渡された変数パラメーターがユーザー制御可能かどうか、およびそれらが安全に処理されたかどうか

防止方法:

パラメーター化されたクエリを使用する

6.関数は安全に処理されました

予防方法:

データの正確な一致

7. HTTP レスポンスの分割

PHP で HTTP レスポンスの分割が発生する可能性がある状況は、header 関数の使用と $_SERVER 変数の使用です。 PHP の上位バージョンでは HTTP ヘッダーに改行文字を使用することが禁止されているため、このテストを直接スキップできることに注意してください。

回避方法:

1. 入力データと完全に一致します

2. 入力に r または n があるかどうかを検出し、それを直接拒否します

8. ファイル管理のための PHP の関数 (入力変数の場合)ユーザーが送信できますが、プログラム内でデータ検証が行われていないため、高リスクの脆弱性となる可能性があります。プログラム内で次の関数を検索する必要があります: copy、rmdir、unlink、delete、fwrite、chmod、fgetc、fgetcsv、fgets、fgetss、file、file_get_contents、fread、readfile、ftruncate、file_put_contents、fputcsv、fputs ですが、通常はすべてファイル操作機能であっても危険な場合があります。

http://ir.php.net/manual/ja/ref.filesystem.php

防止方法:

1. 提出されたデータと厳密に一致する

2. ファイルを操作できるディレクトリを制限する

9. ファイルのアップロード

PHP ファイルのアップロードでは通常、move_uploaded_file が使用されます。特定の分析用のファイル アップロード プログラムも見つかります

防止方法:

1. ファイルのサフィックスを検出するためにホワイトリスト メソッドを使用します

2.時間に基づいてアルゴリズムで生成できます 名前

3. アップロード ディレクトリのスクリプト ファイルは実行可能ではありません

4. %00 の切り捨てに注意してください

PHP 変数の上書きは、次の状況で発生します。初期化変数のトラバース

例:

foreach($_GET as $key => $value)

$$key = $value;

2. 関数カバレッジ変数: parse_str、mb_parse_str、import_request_variables

3. Register_globals の場合=ON、GET モードで変数を送信すると、直接オーバーライドされます

防止方法:

1. Register_globals=OFF を設定します

2. 動的関数を使用する場合、

ユーザーが変数を制御できるため、攻撃者が任意の関数を実行する可能性があります。

例:

< ?php $myfunc = $_GET['myfunc']; ?>

このような関数は使用しないでください

3.

1. HTTPOnly 設定

session.cookie_httponly = ON、クライアント スクリプト (JavaScript など) が Cookie にアクセスできないようにすることで、XSS 攻撃によるセッション ID のハイジャックを効果的に防ぐことができます

2. ドメイン設定

を確認します。 session.cookie_domain にはこのドメインのみが含まれます。親ドメインの場合、他のサブドメインはこのドメインの Cookie を取得できます

3.パス設定

Web サイト自体が /app に適用されている場合は、パスが必要です。セキュリティを確保するために /app/ に設定する必要があります

4.cookie 期間

session.cookie_lifetime を確認します。時間設定プロセスが長すぎる場合、ユーザーがブラウザを閉じたとしても、攻撃者はアカウントのセキュリティを侵害します

5.安全な設定

HTTPS を使用する場合は、Cookie の転送に HTTPS が使用されるようにするために session.cookie_secure=ON を設定する必要があります

6.session は修正されました

権限レベルが変更された場合 (たとえば、ユーザー名とパスワードを確認した後、一般ユーザーが管理者に昇格した場合)、再生成されるセッション ID を変更する必要があります。そうしないと、プログラムがセッション固定のリスクに直面します。攻撃。

7.CSRF

クロスサイトリクエストフォージェリ攻撃とは、攻撃者が悪意のあるリクエストリンクを偽造し、通常のユーザーがさまざまな方法でそれにアクセスできるようにし、ユーザーとしてこれらの悪意のあるリクエストを実行することです。ユーザーのパスワード変更やユーザーの追加機能など、より重要なプログラム モジュールを見直し、CSRF 攻撃に対する防御にワンタイム トークンが使用されているかどうかを確認する必要があります。

4. 暗号化

1. パスワードを平文で保存する

パスワードを平文で保存すると、ユーザー、アプリケーション、システムのセキュリティが著しく脅かされます。

2. 弱いパスワード暗号化

簡単に解読できる暗号化アルゴリズムを使用しているため、MD5 クラッキング Web サイトを使用すると、MD5 暗号化を部分的に解読できます

3. パスワードは、攻撃者がアクセスできるファイルに保存されます

例: パスワードを保存するtxt、ini、conf、inc、xml などのファイル、または HTML コメントに直接記述されています

5. 認証と認可

1. ユーザー認証のコードの場所を確認し、ユーザー認証をバイパスできるかどうかを確認します。認証、例：login コード内にフォームインジェクションが存在する可能性があります。

ブルートフォースクラッキングを防ぐために、ログインコードが認証コードなどを使用していないか確認してください

2. 認証されていない関数やファイルの呼び出し

一部の管理ページは一般ユーザーによるアクセスが禁止されており、開発者が権限を付与し忘れている場合があります。これらのファイルの検証は、脆弱性につながります

一部のページでは、index.php?action=upload などの権限検証を行わずにパラメーター呼び出し関数を使用します

3. ハードコードされたパスワード

一部のプログラムは、アカウントとパスワードをデータベースにリンクし、データベースリンク関数に直接書き込みます。

6. ランダム関数

1.rand()

rand() 最大乱数は 32767 です。 rand を使用してセッションを処理する場合、攻撃者は mt_rand() を使用することを推奨します。

2.mt_srand() および mt_rand()

PHP4 および PHP5 7.特殊文字とマルチバイトエンコーディング

1.マルチバイトエンコーディング

8.PHPの危険な関数

1.バッファオーバーフロー

confirm_phpdoc_compiled

影響を受けるバージョン:

phpDocumentor phpDocumentor 1.3.1

phpDocumentor phpDocumentor 1.3 RC4

phpDocumentor phpDocumentor 1.3 RC3

phpDocumentor phpDocumentor 1.2.3

phpDocumentor phpDocumentor 1.2.2

phpDocumentor phpDocumentor 1.2

phpDocumentor phpDocumentor 1.2

mssql_pconnect/mssql_connect

影響を受けるバージョン: PHP crack_opendict

影響を受けるバージョン: PHP = 4.4.6

snmpget

影響を受けるバージョン: PHP ibase_connect

影響を受けるバージョン: PHP = 4.4.6

uns シリアライズ

インパクトバージョン: PHP 5.0.2、PHP 5.0.1、PHP 5.0.0、PHP 4.3.9、PHP 4.3.8、PHP 4.3.7、PHP 4.3.6、PHP 4.3.3、PHP 4.3.2、PHP 4.3。 1. PHP 4.3.0、PHP 4.2.3、PHP 4.2.2、PHP 4.2.1、PHP 4.2.0、PHP 4.2-dev、PHP 4.1.2、PHP 4.1.1、PHP 4.1.0、PHP 4.1、 PHP 4.0.7、PHP 4.0.6、PHP 4.0.5、PHP 4.0.4、PHP 4.0.3pl1、PHP 4.0.3、PHP 4.0.2、PHP 4.0.1pl2、PHP 4.0.1pl1、PHP 4.0.1

2.session_destroy() 削除ファイルの脆弱性

影響を受けるバージョン: 不気味、特定のテストが必要

テストコードは次のとおりです:

01

02

session_save_path('./');

03

session_start();

04

if( $_GET['del']) {

05

session_unset();

06

session_destroy();

07

}else{

08

$_SESSION['do']=1;

09

echo(session_id());

10

print_r($_SESSION);

11

}

12

?>

cookie:PHPSESSIONID=/../1.php を送信すると、このファイルを削除するのと同じになります

3.unset()-zend_hash_del_key_or_index の脆弱性

zend_hash_del_key_or_index PHP4 は 4.4.3 未満、PHP5 はそれ未満5.1.3 より、zend_hash_del が間違った要素を削除する可能性があります。 PHP の unset() 関数が呼び出されると、変数の設定が解除されなくなります。

9. 情報漏洩

1.phpinfo

プログラム内でphpinfoを呼び出して表示される環境情報を攻撃者が参照できると、さらなる攻撃が容易になります

10.PHP環境

1.open_basedir設定

open_basedirアプリケーションがアクセスできるディレクトリを制限し、open_basedir が設定されているかどうかを確認できます。もちろん、Apache の php_admin_value、nginx+fcgi は conf を通じて php 設定を制御します

2.allow_url_fopen 設定

。 allow_url_fopen =ON の場合、PHP は操作のためにリモート ファイルを読み取ることができ、攻撃者によって簡単に悪用される可能性があります

3.allow_url_include 設定

allow_url_include=ON の場合、PHP はリモート ファイルをインクルードすることができ、深刻な脆弱性を引き起こす可能性があります

4.safe_mode_exec_dir設定

このオプションは、PHP プログラムで呼び出される外部コマンドのディレクトリを制御できます。PHP プログラム内で呼び出される外部コマンドがある場合、外部コマンドのディレクトリを指定することで、プログラムのリスクを制御できます

5.magic_quote_gpc設定

このオプションはエスケープして送信できます。パラメータ内の特殊文字については、magic_quote_gpc=ON に設定することをお勧めします

6.register_globals 設定

このオプションを有効にすると、PHP は外部から送信されたすべての変数をグローバル変数として登録し、結果は非常に深刻です

7.safe_mode設定

safe_modeはPHPの重要なセキュリティ機能です。有効にすることをお勧めします

8.session_use_trans_sid設定

session.use_trans_sidが有効な場合、PHPはセッションIDを通過させますこれにより、攻撃者が現在のセッションをハイジャックしたり、ユーザーをだまして攻撃者が制御する既存のセッションを使用したりすることが容易になります。

9.display_errors 設定

このオプションが有効な場合、PHP はすべてのエラーまたは警告情報を出力し、攻撃者はこの情報を使用して Web ルート パスなどの機密情報を取得できます

10.expose_php 設定

expose_phpオプションが有効な場合、PHP インタープリターによって生成された各応答には、ホスト システムにインストールされている PHP のバージョンが含まれます。リモート サーバーで実行されている PHP のバージョンを知ることで、攻撃者はシステムに対する既知の漏洩方法を列挙することができ、攻撃が成功する可能性が大幅に高まります。

論文:
http://0xsec.org/paper/phpfuzz.html

参考文書:

https://www.fortify.com/vulncat/zh_CN/vulncat/index.html

http:// secinn.appspot.com/pstzine/read?issue=3&articleid=6

http://riusksk.blogbus.com/logs/51538334.html

http://www.owasp.org/index.php/Category: OWASP_Code_Review_プロジェクト