PHP アプリケーションのセキュリティ、PHP アプリケーションのセキュリティ
開発中、インタビュー中、または技術的な議論中であっても、セキュリティについては深い理解と習熟が必要です。
目標
このチュートリアルの目標は、構築する Web アプリケーションを保護する方法を理解できるようにすることです。 SQL インジェクション、GET および POST 変数の操作、バッファ オーバーフロー攻撃、クロスサイト スクリプティング攻撃、ブラウザ内データ操作、リモート フォーム送信など、最も一般的なセキュリティの脅威から保護する方法を学びます。
セキュリティの簡単な紹介
Web アプリケーションの最も重要な部分は何ですか?誰が質問に答えるかによって、この質問に対する答えは異なる場合があります。ビジネスマンは信頼性と拡張性を必要としています。 IT サポート チームは、堅牢で保守可能なコードを必要としています。エンドユーザーは、タスクを実行する際に美しいユーザー インターフェイスと高いパフォーマンスを必要とします。しかし、答えが「セキュリティ」であれば、それが Web アプリケーションにとって重要であることに誰もが同意するでしょう。
しかし、ほとんどの議論はここで終わります。セキュリティはプロジェクトのチェックリストに含まれていますが、多くの場合、プロジェクトが納品されるまで対処されません。このアプローチを採用している Web アプリケーション プロジェクトの数は驚異的です。開発者は何か月もかけて取り組み、最後にセキュリティ機能を追加して、Web アプリケーションを一般公開できるようにしました。
セキュリティ機能が追加される前にコードが検査され、単体テストされ、より大きなフレームワークに統合されているため、結果は混乱したり、再作業が必要になったりすることがよくあります。セキュリティを追加すると、主要なコンポーネントが動作しなくなる場合があります。セキュリティを統合すると、スムーズな (ただし安全ではない) プロセスに余分な負担やステップが追加されます。
このチュートリアルは、PHP Web アプリケーションにセキュリティを統合するための優れた方法を提供します。ここでは、いくつかの一般的なセキュリティのトピックについて説明し、その後、主要なセキュリティの脆弱性とその解決方法について詳しく説明します。このチュートリアルを完了すると、セキュリティについてより深く理解できるようになります。
トピックには以下が含まれます:
SQL インジェクション攻撃
GET 文字列の操作
バッファ オーバーフロー攻撃
クロスサイト スクリプティング攻撃 (XSS)
ブラウザ内データ操作
リモート フォーム送信
Web セキュリティ 101
実装についての説明セキュリティの詳細については、Web アプリケーションのセキュリティを高レベルの観点から議論するのが最善です。このセクションでは、作成する Web アプリケーションの種類に関係なく、心に留めておくべきセキュリティ哲学の基本原則をいくつか紹介します。これらのアイデアの中には、Chris Shiflett (PHP セキュリティーに関する著書は貴重な宝庫です) から得たもの、Simson Garfinkel (「参考文献」を参照) から得たもの、そして長年蓄積された知識から得たものもあります。
ルール 1: 外部データや入力を決して信頼しない
Web アプリケーションのセキュリティについて最初に認識しなければならないことは、外部データは信頼すべきではないということです。外部データには、プログラマによって PHP コードに直接入力されないデータが含まれます。他のソースからのデータ (GET 変数、フォーム POST、データベース、構成ファイル、セッション変数、Cookie など) は、セキュリティを確保するための手順が講じられるまで信頼できません。
たとえば、次のデータ要素は PHP で設定されているため安全であると考えられます。
リスト 1. 安全で完璧なコード
[php]$myUsername = 'tmyer';
$arrayUsers = array('tmyer', 'tom', 'tommy');
define("GREETING", 'hello there' . $myUsername); [/php]
ただし、次のデータ要素にはすべて欠陥があります。 、 リスト 2. 安全でない欠陥のあるコード
[PHP] $ myusername = $ _post ['username'] // 汚染されています
$ arrayusers = Array ($ myusername, 'tom', 'tommy'); !
define("GREETING", 'hello there' . $myUsername); //tainted! [/php]
最初の変数 $myUsername が間違っているのはなぜですか?これはフォーム POST から直接取得されるためです。ユーザーはこの入力フィールドに任意の文字列を入力できます。これには、ファイルを駆除したり、以前にアップロードしたファイルを実行したりする悪意のあるコマンドも含まれます。 「A ～ Z の文字のみを受け入れるクライアント側 (JavaScript) フォーム検証スクリプトを使用すれば、この危険を回避できないのですか?」と疑問に思われるかもしれません。はい、これは常に有益なステップですが、後で説明するように、誰でもあらゆるフォームを自分のマシンにダウンロードし、変更して、必要なものを再送信できます。
解決策は簡単です。サニタイズコードは $_POST['username'] で実行する必要があります。これを行わないと、(配列や定数などで) $myUsername を使用するたびに、これらのオブジェクトが汚染される危険があります。
ユーザー入力をサニタイズする簡単な方法は、正規表現を使用して処理することです。この例では、文字のみが受け入れられることが想定されています。文字列を特定の文字数に制限したり、すべての文字を小文字にすることを要求したりすることも良いアイデアかもしれません。
リスト 3. ユーザー入力を安全にする
リスト$arrayUsers = array($myUsername, 'tom', 'tommy'); //clean!
define("GREETING", 'こんにちは' . $myUsername); $clean = strto lower($input);
$clean = preg_replace(”/[^a-z]/”, “”, $clean);
$clean = substr($clean,0,12);
return $clean;
}[/php]
ルール 2: セキュリティの実装を困難にする PHP 設定を無効にする
ユーザー入力を信頼できないということは、マシン上での PHP の構成方法も信頼すべきではないことも知っておく必要があります。たとえば、register_globals が無効になっていることを確認してください。 register_globals が有効な場合、$variable を使用して GET または POST 文字列を同じ名前に置き換えるなどの不注意な行為が可能になります。この設定を無効にすると、PHP は正しい名前空間の正しい変数を参照するように強制します。フォーム POST から変数を使用するには、$_POST['variable'] を引用符で囲む必要があります。こうすることで、この特定の変数を Cookie、セッション、または GET 変数と間違えることがなくなります。
2 番目に確認する設定は、エラー報告レベルです。開発中はできるだけ多くのエラー レポートを取得したいと考えますが、プロジェクトを納品するときは、エラーを画面に表示するのではなくログ ファイルに記録したいと考えます。なぜ？悪意のあるハッカーは、エラー報告情報 (SQL エラーなど) を使用して、アプリケーションが何を行っているかを推測する可能性があるためです。この種の偵察は、ハッカーがアプリケーションに侵入するのに役立つ可能性があります。この脆弱性を解決するには、php.ini ファイルを編集して error_log エントリの適切な保存先を指定し、display_errors を Off に設定します。
ルール 3: 理解できない場合、保護することはできません
一部の開発者は、奇妙な構文を使用したり、ステートメントを非常に厳密に編成したりするため、短いながらも曖昧なコードを作成します。このアプローチは効率的かもしれませんが、コードが何をしているのかを理解していないと、コードを保護する方法を決定できません。
たとえば、以下の 2 つのコードのうちどれが好きですか?
リスト 4. コードを保護しやすくする
$input = ”;
if (isset( $_POST['ユーザー名'])){
$input = $_POST['ユーザー名'];
}else{
$ input = ”;
}[/php]
2 番目の明確なコード スニペットでは、$input に欠陥があり、安全に処理する前にクリーンアップする必要があることが簡単にわかります
ルール 4: 「多層防御」新しい魔法の武器
このチュートリアルでは、フォームを処理する PHP コードで必要な措置を講じながらオンライン フォームを保護する方法を説明する例を示します。同様に、GET 変数が完全に数値であることを確認するために PHP 正規表現を使用する場合でも、 SQL クエリがエスケープされたユーザー入力を使用するようにするための措置を講じることもできます
多層防御は良いアイデアであるだけでなく、深刻な問題に巻き込まれないようにするための手段です
基本的なルールについて説明したので、見てみましょう。最初の脅威: SQL インジェクション攻撃
SQL インジェクション攻撃の防止
SQL インジェクション攻撃では、ユーザーがフォームまたは GET クエリ文字列を操作してデータベース クエリに情報を追加します。たとえば、単純なログインがあるとします。このデータベースの各レコードには、ユーザー名フィールドとパスワード フィールドがあります。
リスト 5. 単純なログイン フォーム head >
[/php]
なぜ maxlength 属性を指定し、バックエンドで substr() チェックを行うのでしょうか?多層防御は常に有効だからです。ブラウザーは、PHP や MySQL が安全に処理できない非常に長い文字列 (誰かが最大 1,000 文字の名前を入力しようとしているところを想像してください) をユーザーが入力することを防ぎ、バックエンド PHP チェックにより、誰もフォーム データをリモートまたはブラウザーで操作していないことを確認します。 。
ご覧のとおり、このアプローチは、前のセクションで strlen() を使用して GET 変数 pid の長さをチェックするのと似ています。この例では、5 桁を超える入力値は無視されますが、以下に示すように、値は適切な長さに簡単に切り詰められます。 php
$pid = $_GET['pid'];
if (strlen($pid)){
if (!ereg("^[0-9]+$",$pid)){
/ /if non数値の $pid、ホームページに送り返す
}
}else{
//$pid が空なので、ホームページに送り返す
}
//数値の pid がありますが、長すぎる可能性がありますので、確認してみましょう
if (strlen($pid)>5){
$pid = substr($pid,0,5);
}
//架空のクラス Page のオブジェクトを作成します。これは現在
//悪意のあるユーザー入力からさらに保護されます
$obj = new Page;
$content = $obj->fetchPage($pid);
//これで、ページを表示する一連の PHP が完成しました
// …
/ /…
?>[/php]
バッファ オーバーフロー攻撃は、数字や文字の長い文字列に限定されないことに注意してください。また、長い 16 進文字列 (xA3 や xFF のように見える) が表示される場合もあります。バッファ オーバーフロー攻撃の目的は、特定のバッファをフラッディングし、悪意のあるコードや命令を次のバッファに配置し、それによってデータを破損したり、悪意のあるコードを実行したりすることであることに注意してください。 16 進バッファ オーバーフローに対処する最も簡単な方法は、入力が特定の長さを超えないようにすることです。
データベース内で長いエントリを許可するフォームのテキスト領域を扱っている場合、クライアント側でデータの長さを簡単に制限する方法はありません。データが PHP に到達したら、正規表現を使用して 16 進数のような文字列を消去できます。
リスト 15. 16 進文字列の防止
, 0,40);
//潜在的な 16 進文字をすべて削除します
$name = cleanHex($name);
//処理を続行します….
}
function cleanHex($input){
$clean = preg_replace("![][xX]([A-Fa-f0-9]{1,3})!", "",$input);
return $clean;
}
?>
[/php]
この一連の操作は少しわかりにくいかもしれません厳しすぎる。結局のところ、16 進文字列には、外国語で文字を印刷するなど、正当な用途があります。 16 進正規表現をどのように展開するかはあなた次第です。より良い戦略は、1 行に 16 進文字列が多すぎる場合、または文字列が特定の文字数 (128 や 255 など) を超える場合にのみ、16 進文字列を削除することです。
クロスサイト スクリプティング攻撃クロスサイト スクリプティング (XSS) 攻撃では、多くの場合、悪意のあるユーザーが (または他のユーザー入力方法を通じて) フォームに情報を入力し、悪意のあるクライアント側タグをフォームに挿入します。プロセスまたはデータベース内で。たとえば、サイトに訪問者が名前、電子メール アドレス、簡単なメッセージを残せる簡単なゲストブック プログラムがあるとします。悪意のあるユーザーはこの機会を利用して、他のユーザーにとって不適切な画像や、ユーザーを別のサイトにリダイレクトする JavaScript など、短いメッセージ以外のものを挿入したり、Cookie 情報を盗んだりする可能性があります。
幸いなことに、PHP には、HTML タグで囲まれたコンテンツを削除できるstrip_tags() 関数が用意されています。また、strip_tags() 関数を使用すると、
や など、許可されるタグのリストを提供できます。
リスト 16 は、前の例を基にした例を示しています。用户 リスト 16. ユーザー入力から HTML マークをクリアします
[php] & lt ;? php
if ($ _post ['submit'] == "go") {
//strip_tags
$ name =trip_tags ($ _ post [ 'name']);
$name = substr($name,0,40);
//潜在的な 16 進文字をすべて削除します
$name = cleanHex($name);
//処理を続行します….
}
function cleanHex($input){
$clean = preg_replace
("![][xX]([A-Fa-f0-9]{1,3})!", "",$input);
return $clean ;
}
?>
“” method=”post”>
”text” name=”name” id=”name” size=”20″ maxlength=”40″/>
< p
[/php]
セキュリティの観点から、一般ユーザー向けinput ストリップタグ()を使用する必要があります。フォームが保護領域 (コンテンツ管理システムなど) にあり、ユーザーがタスク (Web サイトの HTML コンテンツの作成など) を正しく実行することを信頼している場合、strip_tags() の使用は不要であり、生産性に影響を与える可能性があります。
もう 1 つの質問: 投稿やゲスト登録エントリへのコメントなどのユーザー入力を受け入れ、この入力を他のユーザーに表示する必要がある場合は、必ず応答を PHP の htmlspecialchars() 関数に入れてください。この関数は、アンパサンド、< > 記号を HTML エンティティに変換します。たとえば、アンパサンド (&) は & になります。この場合、悪意のあるコンテンツがフロントエンドのstrip_tags()の処理を逃れたとしても、バックエンドのhtmlspecialchars()によって処理されます。
ブラウザ内データ操作
ユーザーがページ上のヘッダー要素やフォーム要素を改ざんできるようにするブラウザー プラグインのクラスがあります。 Mozilla プラグインである Tamper Data を使用すると、多くの非表示のテキスト フィールドを持つ単純なフォームを簡単に操作して、PHP や MySQL に指示を送信できます。
ユーザーがフォームで「送信」をクリックする前に、データ改ざんを開始できます。フォームを送信すると、フォーム データ フィールドのリストが表示されます。データの改ざんを使用すると、ブラウザーがフォームの送信を完了する前に、ユーザーがこのデータを改ざんできます。
前に作成した例に戻りましょう。文字列の長さがチェックされ、HTML タグが削除され、16 進文字が削除されました。ただし、以下に示すように、いくつかの隠しテキスト フィールドが追加されます。
リスト 17. 隠し変数
[php]if ($_POST['submit'] == "go"){
//strip_tags
$name = ストリップ_タグ($_POST['名前']);
$name = substr($name,0,40);
//潜在的な 16 進文字をすべて削除します
$name = cleanHex($name);
//処理を続行します….
}
function cleanHex($input){
$clean =
preg_replace("![][xX]([A-Fa-f0-9]{1,3})!", "",$input);
return $clean;
}
?>
”” method=”post”>
[/php]
注、隠し変数の 1 つがテーブル名 users を公開します。また、create という値を持つアクション フィールドも表示されます。基本的な SQL の経験がある人なら、これらのコマンドがおそらくミドルウェアの SQL エンジンを制御していることがわかります。大混乱を引き起こしたい人は、テーブル名を変更するか、削除などの別のオプションを提供するだけで済みます。
図 1 は、改ざんデータがもたらす可能性のある損害の範囲を示しています。データ改ざんにより、ユーザーはフォーム データ要素だけでなく、HTTP ヘッダーや Cookie にもアクセスできることに注意してください。
図 1. Tamper Data ウィンドウ
このツールを防御する最も簡単な方法は、どのユーザーも Tamper Data (または同様のツール) を使用できると想定することです。システムがフォームを処理するために必要な最小限の情報のみを提供し、フォームを専用のロジックに送信します。たとえば、登録フォームは登録ロジックにのみ送信する必要があります。
共通のフォーム処理関数を構築し、多くのページがこの共通ロジックを使用している場合はどうなるでしょうか?隠し変数を使用してフローを制御するとどうなるでしょうか?たとえば、非表示のフォーム変数で、書き込むデータベース テーブルや使用するファイル リポジトリを指定できます。オプションは 4 つあります:
何も変更せず、システムに悪意のあるユーザーがいないことを密かに祈ります。
より安全な専用フォーム処理関数を使用し、非表示のフォーム変数の使用を回避するように関数を書き換えます。
md5() またはその他の暗号化メカニズムを使用して、隠しフォーム変数内のテーブル名またはその他の機密情報を暗号化します。 PHP 側で復号化することを忘れないでください。
略語やニックネームを使用して値の意味を曖昧にし、PHP フォーム処理関数でこれらの値を変換します。たとえば、users テーブルを参照したい場合は、u または任意の文字列 (u8y90×0jkL など) を使用して参照できます。
後の 2 つのオプションは完璧ではありませんが、ユーザーがミドルウェア ロジックやデータ モデルを簡単に推測するよりははるかに優れています。
今残っている質問は何ですか?リモートフォーム送信。
リモートフォーム送信 Web の利点は、情報やサービスを共有できることです。欠点は、情報やサービスの共有です。何の躊躇もなく物事を行う人もいます。
フォームを例に挙げてみましょう。誰でも Web サイトにアクセスし、ブラウザ上で [ファイル] > [名前を付けて保存] を使用してフォームのローカル コピーを作成できます。次に、完全修飾 URL (formHandler.php ではなく、フォームはこのサイトにあるため http://www.yoursite.com/formHandler.php) を指すようにアクション パラメーターを変更し、必要な操作を行うことができます。変更を加えて [送信] をクリックすると、サーバーはこのフォーム データを法的な通信フローとして受信します。
まず、$_SERVER['HTTP_REFERER'] をチェックして、リクエストが自分のサーバーからのものであるかどうかを判断することを検討してください。この方法では、ほとんどの悪意のあるユーザーをブロックできますが、最も高度なハッカーをブロックすることはできません。これらの人々は、ヘッダー内の参照元情報を改ざんして、フォームのリモート コピーをサーバーから送信されたように見せかけるほど賢いのです。
リモート フォームの送信を処理するより良い方法は、一意の文字列またはタイムスタンプに基づいてトークンを生成し、このトークンをセッション変数とフォームに入れることです。フォームを送信した後、2 つのトークンが一致するかどうかを確認します。一致しない場合は、誰かがフォームのリモート コピーからデータを送信しようとしていることがわかります。ランダム トークンを作成するには、以下に示すように、PHP 組み込みの MD5 ()、Uniqid ()、および RAND () 関数を使用できます。
リスト 18. 防御リモート フォームの送信
[php] & lt;? );
if ($_POST['submit'] == "go"){
//トークンをチェック
if ($_POST['token'] == $_SESSION['token']){
//strip_tags
$name = ストリップ_タグ($_POST['名前']);
$name = substr($name,0,40);
//潜在的な 16 進文字をすべて削除します
$name = cleanHex($name);
//処理を継続します….
}else{
//すべての処理を停止します!リモートフォーム投稿試行!
}
}
$token = md5(uniqid(rand(), true));
$_SESSION['token']= $token;
function cleanHex($input){
$clean = preg_replace ("![][xX]([A-Fa-f0-9]{1,3})!", "",$input);
return $clean;
}
?>
<フォームアクション=”method=”post”>
”/>
[/php]
この手法が機能するのは、PHP ではセッション データをサーバー間で移行できないためです。誰かがあなたの PHP ソース コードを取得し、それを自分のサーバーに移動し、あなたのサーバーに情報を送信したとしても、あなたのサーバーが受け取るのは、空の、または不正な形式のセッション トークンと、最初に提供されたフォーム トークンだけです。これらは一致しないため、リモート フォームの送信は失敗します。
結論このチュートリアルでは多くの問題について説明しました:
SQL インジェクションの問題を防ぐには mysql_real_escape_string() を使用します。
正規表現と strlen() を使用して、GET データが改ざんされていないことを確認します。
正規表現と strlen() を使用して、ユーザーが送信したデータがメモリ バッファーをオーバーフローしないようにします。
strip_tags() と htmlspecialchars() を使用して、ユーザーが有害な可能性のある HTML タグを送信しないようにします。
データ改ざんなどのツールによるシステムの侵害を防ぎます。
一意のトークンを使用して、ユーザーがリモートからサーバーにフォームを送信できないようにします。
このチュートリアルでは、ファイル インジェクション、HTTP ヘッダー スプーフィング、その他の脆弱性などのより高度なトピックについては説明しません。ただし、ここで学んだことは、現在のプロジェクトをより安全にするために十分なセキュリティをすぐに追加するのに役立ちます。
http://www.bkjia.com/PHPjc/1121567.htmlwww.bkjia.com本当http://www.bkjia.com/PHPjc/1121567.html技術記事 PHP アプリケーションのセキュリティ 開発中、インタビュー中、または技術的な議論中であっても、セキュリティについては深い理解と習得が必要です。 目的 このチュートリアル...
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
