search

yousuketanaka / phptraining

0 stars 0 forks source link

セキュリティ対策について調べてみましょう。 #13

Open saitos01 opened 8 years ago

saitos01 commented 8 years ago

こちらのIssueは作成中です。

こちら空いた時間でやるタスクになります。

yousuketanaka commented 8 years ago

主に知っておかなければならないセキュリティ対策は6つだと理解しています。情報の不足、修正などありましたら、ご指摘ください。

また、先日、静的プレイスホルダを学習しましたので、SQLインジェクションは理解できましたが、それ以外はまだピンときていない状況です。

①SQLインジェクション

🔹意味 データベースと連動したWebサイトで、データベースへの問い合わせや操作を行うプログラムにSQL文の断片として解釈できる文字列をパラメータに含めることで、プログラムが想定していないSQL文を合成し、不正にデータベースの内容を削除したり、本来アクセスできない情報を表示させたりすることができてしまう攻撃のこと。

🔹原因 外部から受け取った値（パラメータ）をSQL文に埋め込む際にきちんとチェックが行われていないために起こる。

🔹対策

  1. 前提条件的な対策 　1-1.「開発用のエラーメッセージをブラウザに出さない」 ⇨開発時のデバッグではエラーメッセージは有益だが、本番稼働時にも同じ状態のままで放置する 　　と、攻撃者にとってSQLインジェクションの攻撃状況を確認するのに有益な情報源を与える。

    1-2.「データベースの権限を正しく設定する」 　⇨機能の範囲ごとに、データベースの権限を割り当てたユーザーを作成し、そのユーザーを使用して 　　アクセスすべきである。

    1-3.「入力パラメタのチェック」 　⇨入力項目ごとに決められたチェック処理を行うようにする。例えば郵便番号の場合は、 　「123-4567」の形式のみを有効とする、あるいは都道府県を「01～48」のコードで表している 　 場合は、「01～48」の文字列のみを有効とするなど。

    1-4.「日本語の誤認識を防ぐ」 ⇨日本語などのマルチバイトに対する処理がきちんと行われている必要がある。

  2. バインド機構(バインドメカニズム)」の使用 あらかじめSQL文のひな型を用意し、後から変動個所（プレースホルダ）に実際の値（バインド値） を割り当ててSQL文を生成するデータベースの機能を使用する。

    例) INSERT INTO example(テーブル名)(name, age, birthday, workplace) VALUES(?,?,?,?); $stmt->bindValue(1, $name, PDO::PARAM_STR);

    また、バインド機構を採用するために、プリペアドステートメントで以下の設定も行う。

　・PDO::ATTR_EMULATE_PREPARES => False　⇨　静的プレイスホルダへ

  1. バインド機構で実装できない場合は、「エスケープ処理(別の文字列への変換)」 SQLインジェクションのために挿入された文字列を攻撃が成功しないように文字列の置き換えを行う 処理を言う。エスケープ処理は、SQL文を生成する直前に実施するのが定石である。

    $name = htmlspecialchars($name, ENT_QUOTES, 'UTF-8'); ⇩ INSERT INTO example(テーブル名)(name, age, birthday, workplace) VALUES(?,?,?,?);

②クロスサイトスクリプティング

🔹意味 JavaScriptを実行するコードを制作者の意図していない場所に埋め込む手法。有名なクロスサイトスクリプティングの手法として以下の2点を理解している。

　1. 訪問者のクッキー情報を抜き取るスクリプトを埋め込む事による「セッションハイジャック」 　　例) 　　

　2. 訪問者の個人情報の入力を促す入力フォーム（HTMLタグ）を埋め込むことによる、 　　個人情報の不正搾取 例)

    <form method=”post” action=”http://●●●●●.com/script.cgi”>
           <p>氏名（漢字）：<input type=”text” name=”name”></p>
           <p>メール：<input type=”text” name=”email”></p>
           <p><input type=”submit” value=”送信する”></p>
    </form>

上記2点は、「<」と「>」などのHTML上の文字を特殊文字（タグ）として認識するブラウザの特徴を利用した攻撃手法。

🔹原因

  1. テキストノードに出力する際の「<」「>」のエスケープ漏れ
  2. 属性値に出力する際の「"」「'」のエスケープ漏れ
  3. URLをリンクとして取り扱う際のプロトコルスキームの確認漏れ

🔹対策

  1. 文字列のエスケープ ※IT用語で、「サニタイジング」とは、HTMLの特殊文字を、別の文字列へ置き換える事を指し 　　ます。「エスケープ」も、「サニタイジング」と同じ意味で用いられます。 　　http://viral-community.com/blog/html-sanitizing-escape-1859/

　$str = htmlspecialchars($str, ENT_QUOTES, 'UTF-8'); 　※第2引数は、ENT_QUOTESが一番強くエスケープしてくれる。

2.hrefやsrcの値がURLか確認する

　Javascriptはscriptは、aタグのhref属性や、imgタグのsrc属性の中でも実行することが可能。これは、 　htmlspecialcharsを使っても取り除けない。従って、正規表現などを使って、本当にURLが指定され 　ているかを事前に確認する。

　function isUrl($url) { 　　　return (boolean)preg_match('/A(https?://|/)/',$url); 　}

  1. php.iniでsession.cookie_httponly=on

　JavascriptからCookieにアクセスできると、XSS脆弱性によってCookieに保存されたセッションID 　等が漏えいする恐れがある。php.iniでsession.cookie_httponlyをonにしておくと、Javascript経由で 　Cookieにアクセスすることができなくなる。

　　ini_set('session.cookie_httponly',1);

  1. httpd.confでTraceEnable Off

    保険的な対策だが、XSS対策に漏れがあった場合に、クロスサイトトレーシング(XST)という攻撃 を受ける恐れがある。

　httpd.conf　⇨ TraceEnable Off

③クロス・サイト・リクエスト・フォージェリ ※CSRF（シーサーフ）と呼ばれている。

🔹意味 別のサイトに用意したコンテンツ上の罠のリンクを踏ませること等をきっかけとして、インターネッ トショッピングの最終決済や退会等Webアプリケーションの重要な処理を呼び出すようユーザを誘導 する攻撃。具体的には、Webサイトの掲示板などに、誰かになりすましてコメントしたり、Webサイ 　トへコメントを第三者になりすまして書き込むことなどができてしまいます。

　具体的には次のようなWebアプリケーションが対象となる。

　・Cookieを用いてセッションIDを搬送している Webアプリケーション 　・Basic認証を用いているWebアプリケーション 　・Digest認証を用いているWebアプリケーション 　・そのほかWebクライアントから自動で得られる情報にもとづきユーザやセッションを識別している 　　Webアプリケーション

　フォームと呼ばれる機能を持っているWebサイトは注意が必要。特に掲示板や、コメントを入力でき 　るようなWebサイトはCSRF対策が必須になる。

🔹原因 　form要素のaction属性にはどのドメインのURLも使用できるため。 　クッキーに保管されたセッションIDは、対象サイトに自動的に送信されるため。

🔹対策 1.重要な処理の前には、リクエストが正規利用者のものか確認する。

 具体的には、、、
 1-1.秘密情報（トークン）を埋め込む。トークンとは第三者が知り得ないような情報を指す。
 1-2.パスワードを再入力させる（再度認証する）。
 1-3.Refererを確認する。Refererとは、webページにアクセスする前に、それまでに見ていたページ
       情報がわかるようになる場合がある。そのリファラーを見て、自分のサイトからきていれば正し
       いとする。

 ⭐️トークンとは?

<?php session_start() ?> <DOCTYPE!>

CSRFサンプル

お問い合わせフォーム

<?php // CSRF対策 session_start(); if (session_id() !== $_POST['token']) { die('正しい画面からご使用下さい'); } // お問い合わせ内容の受付、DB格納処理など

?> <DOCTYPE!>

XSSサンプル

お問い合わせを受け付けました

④ディレクトリトラバーサル

🔹意味 　意図しないファイルにアクセスされる。 　※Webサイトなどで公開されている、ファイル名やその一部をパラメータとして受け取るような 　 プログラムが主な攻撃対象となる。

🔹原因 　外部から受け取った値を、エスケープせずにファイル名を取得するために発生。

🔹対策 　1. 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。

2. ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれな
     いようにする。

　3. ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する。

　4. ファイル名のチェックを行う。 意図するファイルが指定された場合にのみ操作可能なようにするか、ディレクトリ階層をたどる".." 　 が含まれる場合に処理を中断するなどの方法がある。

　 /$fileはGETまたはPOSTなどでユーザから入力された変数とします。

　 //".."が含まれてた場合は処理中断 　 if(strpos($file, "..") !== FALSE)exit; 　 readfile($file);

⑤セッション・ハイジャック

🔹意味 　不正に取得した第三者のセッションIDを利用し、正規ユーザーのセッションを乗っ取ることで、 　不正な操作を行うことをセッション・ハイジャックという。

　この場合、正規ユーザーと同じ権限で操作が可能になるため、ユーザーの個人情報を改ざんしたり、 　取得が可能になる。

🔹原因 　・リファラによる漏洩

   セッション管理方法に関する設定値が以下の場合、セッションIDの漏洩が起きる可能性がある。

　　session.use_only_cookies = 0(クッキーが利用できない場合に、get変数、post変数による 　　　　　　　　　　　　　　　セッション管理を行うか。0は無効、1は有効) session.use_trans_sid = 1(セッションIDの管理にクッキーのみを使用するか。1は有効。)

　・クロスサイトスクリプティングによるセッションIDの入手

　　クロスサイトスクリプティング対策を行っていないサイトへ攻撃コードを含むリンクを貼ったり 　　することでセッションIDを盗み出す。

　・セッション固定攻撃によるセッションIDの強制

　　セッション固定攻撃に弱い、ログインを必要とするサイトに対して、攻撃者が指定するセッション IDを含むリンクを貼っておくだけで成立する。あとは、ユーザーがリンクをクリックし、ログイン 　　したところで、ユーザーのログインIDを使って対象サイトにアクセスする。

🔹対策 　クロスサイトスクリプティング対策を行った上で、以下の対応を行う。 　 　1. セッションIDをクッキーのみで扱う。

　　セッションIDをクッキーのみで扱うようにするには、php.iniや.htaccess, ini_set()関数で、 　　セッション IDに関する値を以下のようにセットする。 　　session.use_cookies = 1 　　session.use_only_cookies = 0 session.use_trans_sid = 1 session.cookies_httponly = 1

　2. セッションハイジャックのチェック。

    Accept-Charset、Accept-Language、User-Agentをもとに生成した乱数をセッションに保存してお

　　き、セッション開始直後にセッション内の値とアクセスしてきた情報をもとに生成した乱数の生合 　　成をチェックする。

　3. パスワード入力による多重チェックの実装。

　　厳密には、セッションハイジャックへの対応方法ではないが、万が一の被害を少なくするために、 　　有効。だが、ユーザビリティの低下とのバランスを取る必要がある。

　 ⑥OSコマンドインジェクション

🔹意味 　サーバー内の任意のコマンドを実行させることで攻撃をしかけること。任意のコマンドを実行するこ 　とで、最悪管理者権限を乗っ取られる危険性もある。

　プログラム実行関数である、system(), exec(), passthru(), popen(), shell_exec()関数やバックティック 　演算子を用いて実行するコマンドの中に外部からのリクエストが含まれる場合には、この脆弱性が存 　在しないか確認する必要がある。

🔹原因 　外部から受け取った値を、エスケープせずにシェルコマンドを実行させるために発生。具体的に、 1行の指定で複数のプログラムを起動するというシェル機能の悪用によって発生する。 シェルとは、 　ユーザの操作を受け付けて、与えられた指示をOSの中核部分に伝えるソフトウェア。 　悪用の条件は以下の３つです。

　　（Ａ）シェルを呼び出す機能のある関数（system、openなど）を利用している。 　　（Ｂ）シェル呼び出し機能のある関数にパラメータを渡している。 　　（Ｃ）パラメータ内に含まれるシェルのメタ文字をエスケープしていない。 　　　http://senmon.cfc.ac.jp/studentreport/report2/OS.html

🔹対策

　１．OSコマンド呼び出しを使わない実装方法を選択する。 OSコマンド呼び出しを使わない実装方法を選ぶ。

　２．シェル呼び出し機能のある関数の利用を避ける。 　　　シェルを起動できる言語機能を避ける必要があります。他の関数で代替できる場合があります。

　３．外部から入力された文字列をコマンドラインのパラメータに渡さない。

　４．OSコマンドに渡すパラメータを安全な関数によりエスケープする。 　　　使用などの理由からどうしても利用せざるを得ない場合は、エスケープを行った上で実行する 　　　外部コマンドに応じたホワイトリスト方式などのチェックを行うと良い。

http://www.ipa.go.jp/files/000017316.pdf http://viral-community.com/blog/xss-1835/ https://www.websec-room.com/2013/03/07/479 http://phpcode.jp/c7_csrf.php http://runble1.com/security-directory-traversal/

saitos01 commented 8 years ago

返信遅れて申し訳ありません。こちらのIssue作成中でして、セッションの項目が終わった後に、SQLインジェクション、XSS、CSRFを調べていただく予定だったのですが、他にもいくつか調べて頂いたようですね。 かなり詳しく調べて頂いたようですね。あとはXSS、CSRFが引き起こる簡単なケースを頭の中でイメージできるといいと思います。

また項目ごとに追記しますのでお待ちくださいませ。

saitos01 commented 8 years ago

①SQLインジェクションは理解されているようですね。 前提条件的な対策はもちろん大切ですが、トレーニング内では気にしすぎないほうが良いと思います。

②クロスサイトスクリプティング

意味の理解としては良さそうですね。 本トレーニングでは後ほどになりますが、htmlspecialchars での文字列のエスケープに重点を置いて学習していきましょう(すでにコードの中でもつかわれていますね)。

③クロス・サイト・リクエスト・フォージェリ

意味の理解としてはこちらも良さそうですね。 秘密情報（トークン）を埋め込みに関しての簡単な例をやれればと思っていたのですが、既にあげていただいていますね(さすがです)。

④ディレクトリトラバーサル

こちらはトレーニングの中では扱えないのですが、対策としては抑えられているかと思います。

⑤セッション・ハイジャック

こちらの対策としては「セッションの理解」と「クロスサイトスクリプティングの理解」が必要になってきます。 まずはそちらを抑えていきましょう。クロスサイトスクリプティング対策はこのセッションハイジャックを防ぐためとも言えるでしょう。

⑥OSコマンドインジェクション

最近はSQLインジェクション、XSS、CSRFに比べて被害が減ってきているセキュリティ侵害になります(PHPの機能拡充によりプログラム実行関数を使うケースが減ったからです)。 田中さんが既に抑えられている理解で大丈夫です。