6

私は通常、自分で情報を見つけることについてかなり機知に富んでいますが、この主題になると、そこにある膨大な量の情報に本当に気が遠くなります. 少し情報過多になってきました。

個々のセキュリティ トピックに関する多数の記事を見つけましたが、全体像と、実際にすべてがどのように組み合わされるかを理解することはできません。

俯瞰的なロードマップを見る必要があります。次の架空の例を見てください。

単純な架空の「コメント」セクション:

  • サインアップ: MySQL テーブルに安全に保存されるパスワード/ユーザー名の組み合わせを作成します。

  • ログイン。

  • コメントを残す。

この最も基本的なケースに従うべき「セキュリティ ロードマップ」は何でしょうか?

地球上のすべてのチュートリアルや PHP の本で MySQL 拡張機能が使用されていることは役に立ちません。私の理解が正しければ、それは悪い考えでしょうか?

4

3 に答える 3

9

A. 一般的に…</h2>

  1. ここでは、プログラマーがサーバー管理者ではなく、サーバー管理者がデフォルトで LAMP を正しく安全に構成する方法を多かれ少なかれ知っていると想定しています。

    もちろん、必要に応じて、プログラマーphp.iniは Web ルートにあるカスタム ファイルでほとんどの PHP 設定をオーバーライドできます。

  2. MVC フレームワークを使用します。

    私はCakePHPを使用しています。フレームワーク自体は、根本的に健全で安全なコーディング プラクティスを確保するのに大いに役立ちます。

B. 受信データ…</h2>

  1. データをプログラムで操作する前に$_GET, $_POST, $_COOKIE,、含まれているすべてのデータをサニタイズして検証します。$_REQUEST

  2. SQL インジェクション

    定義:アプリケーションのデータベース層で発生するセキュリティの脆弱性を悪用するコード インジェクション手法。この脆弱性は、ユーザー入力が SQL ステートメントに埋め込まれた文字列リテラル エスケープ文字に対して正しくフィルター処理されない場合、またはユーザー入力が厳密に型指定されていないために予期せず実行される場合に存在します。

    防止:mysqliまたはなどのライブラリを使用したパラメータ化されたクエリPDO。OWASP SQL インジェクション チート シートを参照してください(文字列エスケープ関数などmysql_real_escape_stringは推奨されません) 。

  3. クロスサイトスクリプティング (XSS)

    定義:通常、Web アプリケーションに見られるセキュリティの脆弱性で、悪意のある Web ユーザーが他のユーザーが表示する Web ページにコードを挿入できるようにするものです。このようなコードの例には、クライアント側のスクリプト (つまり、JavaScript) が含まれます。

    防止: コンテキスト依存の出力エスケープとエンコーディング。OWASP XSS 防止チート シートを参照してください。

C. ブラウザのリクエスト…</h2>

  1. クロス サイト リクエスト フォージェリ (CSRF)

    定義: Web サイトが信頼するユーザーから不正なコマンドが送信される、Web サイトの悪意のある悪用の一種。ユーザーが特定のサイトに対して持っている信頼を悪用するクロスサイト スクリプティング (XSS) とは異なり、CSRF は、サイトがユーザーのブラウザーで持っている信頼を悪用します。

    防止:通常、ブラウザ セッションの開始時に一意の「トークン」を生成します。POSTすべてのGETリクエストでトークンを渡します。POST/アクションに続いてGET、セッション内のトークンの存在を確認し、POST/によって送信されGETたトークンがセッションに保存されているトークンと同一であることを確認します。(CakePHP のような MVC フレームワークを使用すると、これをアプリケーション全体で均一に実装するのが比較的簡単になります。)

D. セッション…</h2>

  1. セッションを強制終了するときにセッション データを破棄する

    セッションが完了したら (「ログアウト」)、そのデータを破棄し、Cookie をクリアするだけではありません (悪意のあるユーザーが Cookie を元に戻し、セッションを再度使用する可能性があります)。$_SESSION空の配列に割り当てて、すべてのインデックスの設定を解除します。

  2. セッションを Web ルートまたはデータベースにファイルとして保存する

    サーバー上でセッションを保存するためのデフォルト パスは、ハイジャックされる可能性があります。特に、共有ホスティング環境ではそうです。

E. パスワード…</h2>

  1. 強力なパスワードの選択を強制する

    • パスワードに数字、記号、大文字と小文字を要求する

    • パスワードの長さは約 12 ～ 14 文字にする必要があります

  2. すべてのパスワードのハッシュとソルト

    またはをパスワードのハッシュにsha1()使用しないでくださいmd5()hash()。それらはこのために設計されていません。bcryptや PBDFK2などの関数を使用する必要があります。この質問には本当に良い提案がいくつかあります。ソルト値は完全にランダムで、データベースに保存する必要があります (実際には秘密ではありません)。追加のシークレット値 (一般に "pepper" と呼ばれます) をアプリケーションに保存し、bcrypt を使用する前にパスワードの先頭に追加できますが、これが実際にどの程度のセキュリティを追加するかは明らかではありません。

F. Web ルートにあるカスタムphp.iniで…</h2>

  1. register_globals を無効にする

    防止： register_globals = Off

  2. 魔法の引用符を無効にする

    防止： magic_quotes_gpc = Off

  3. エラー報告を無効にする

    防止： display_errors = Off

  4. エラー ログを有効にし、ログ ファイルを Web ルートの上のディレクトリに保存します。

    防止：

    log_errors = On; 
ignore_repeated_errors = On; 
html_errors = Off; 
error_log = /path/above/webroot/logs/php_error_log

  5. Web ルートの上のディレクトリ内にセッション データを保存する

    防止： session.save_path = /path/above/webroot/sessions

G. .htaccessWeb ルートにあるファイル内…</h2>

  1. サイト全体でディレクトリ リストを無効にする

    防止： Options -Indexes

H. 貴重な/機密ファイル…</h2>

  1. そのようなファイルを Web ルートの上に保存することで、不正なアクセス/ダウンロードを防ぎます

    これには、サイト管理/メンバー専用セクションとサイト/データベース構成ファイルが含まれます!!

  2. 中間スクリプトを使用して、ファイルをインラインまたは添付ファイルとして提供します

  3. スクリプト (WordPress、PHPMyAdmin など) を最新の状態に保ちます。

  4. PHPMyAdmin を使用している場合にのみ、PHPMyAdmin へのアクセスを許可してください。これにより、ユーザーがインストールでゼロデイ エクスプロイトを使用できなくなります。

I. アップロードされたファイル…</h2>

  1. $_FILESあらゆる種類のデータ操作に使用する前に、に保存されているファイル名を検証します

  2. 提供された MIME タイプはなりすましであるか、間違っている可能性があることに注意してください。

  3. ユーザーがアップロードしたすべてのファイルを Web ルートの上のディレクトリに移動します!!!

  4. アップロードされたファイルを include() で実行/提供しないでください

  5. 「application/octet-stream」、「application/unknown」、または「plain/text」のコンテンツ タイプを持つファイルを提供しないようにしてください</p>

J.その他…</h2>

  1. サイト/アプリケーションの開発中に開発者によって作成および使用される Web ルート内のすべての「ユーティリティ」ファイル/プログラムは、将来のサイト ユーザーがアクセスすることを意図または要求されていないか、何らかのセキュリティ リスクをもたらすものではありません。サイトが公開されると削除されます。

    たとえば、これにはphpinfo.phpファイル (の結果を出力するファイルphpinfo())、データベース ユーティリティ スクリプトなどが含まれます。

于 2012-09-04T05:48:16.383 に答える
1

安全のために、サーバー側のプログラミング (php など) に移る前に、まず mysql 側の構築から始めます。ストアド プロシージャ、ビュー、プリペアド ステートメント、おそらくトランザクションを作成します。それらはアプリケーションをより安全にするためのものです..あまりにも悪いphpプログラマーはそれらを頻繁に使用しません.

次に、サーバー側のプログラミングに来るときは、pdo を使用します (mysqli よりも好きです)。これにより、パラメーターをバインドできます (これは、asp.net でも使用される安全な戦略です)。

検証戦略を使用することもできます..入力が電子メール、クレジットカードなどであるかどうかを確認して、期待されるもののホワイトリストを提供します（ブラックリストの作成は安全性の低いアイデアです..いくつかのハッキング本）。

エスケープとフィルタリングは、必要に応じて使用できます。パスワードでは、タグを削除したい場合がありますが、コメントを使用すると、削除できない場合があります..

幸運を！

于 2012-09-04T05:58:10.360 に答える
0

通常のアドバイスは、クライアントからのすべての入力をサニタイズすることです。通常、入力内のあらゆる形式のコードを取り除きたいと思うでしょう。それらが目的です。使用可能な防御線は次のとおりです。

まず、プログラムの設計がしっかりしている場合、問題を軽減できます。たとえば、不要なシンボルを取り除く適切なフォーム検証を行うことで、SQL インジェクションやクロスサイト スクリプティングを防ぐことができます。ただし、コメントのようにかなりオープンエンドの入力はトリッキーです。

次に、入力をきれいにする必要があります。通常、いくつかの防御線があります。タグを削除したり、エスケープしたりできますが、より高度なインジェクションには役立ちません。それらを表示するときに、出力をエスケープできます。

第三に、パラメーター化されたクエリを使用して入力を保存する方法も保護できます。これにより、ほとんどの場合、SQL インジェクションが防止されます。

HTML Purifierなど、入力のサニタイズに役立つオープンソース ライブラリがあります。

要約すると：

  • 入力を正しくモデル化します。受け入れられる入力と受け入れられない入力

    DB に保存するときに入力タグを削除またはエスケープするか、表示するときにそれらをきれいにします。

    MySQL がサポートするパラメーター化されたクエリを使用する

于 2012-09-04T05:52:05.327 に答える