cvs: phpdoc /ja/chapters security.xml

fujimoto Wed Dec 12 09:02:37 2001 EDT Modified files: /phpdoc/ja/chapters security.xml Log: updated translation (up to 1.37).

Index: phpdoc/ja/chapters/security.xml diff -u phpdoc/ja/chapters/security.xml:1.15 phpdoc/ja/chapters/security.xml:1.16 --- phpdoc/ja/chapters/security.xml:1.15 Tue Nov 20 20:48:37 2001 +++ phpdoc/ja/chapters/security.xml Wed Dec 12 09:02:37 2001 @@ -1,4 +1,5 @@ <?xml version="1.0" encoding="utf-8"?> +<!-- $Revision: 1.16 $ --> <chapter id="security"> <title>セキュリティ</title> @@ -36,6 +37,48 @@ ティ上のアドバイスを行います。 </simpara> + <sect1 id="security.general"> + <title>一般的な考慮事項</title> + <simpara> + 完全に安全なシステムは理想の産物でしかないため、セキュリティ業界で + しばしば使用される手法は、リスクと利便性のバランスのとれた手法です。 + 変数がユーザから投稿される度に(網膜スキャンと指紋のような)2種類の + 生体認証が必要だとしたら、極端に高いレベルの説明義務を生じます。ま + た、かなり複雑なフォームを埋めるために30分もかかるとすれば、ユーザ + がセキュリティをバイパスする手段を探す気分にさせる傾向があります。 + </simpara> + <simpara> + 最善のセキュリティは、通常、ユーザによる業務の達成を防たげずに要求 + を十分に達成できる程度にさしでがましくないものです。むしろ、いくつ + かのセキュリティ攻撃は、単純にこの種の多げさに構築され、時間を浪費 + しがちなセキュリティ機構を狙うものです。 + </simpara> + <simpara> + 記憶するに値する言葉として次のようなものがあります。「システムは鎖 + の最も弱い輪と同程度に優れている」全てのトランザクションが時間、場 + 所、トランザクションの型等に基づき大量に記録されているが、ユーザは + 一つのクッキーのみにより認証されている場合、ユーザとそのトランザク + ションログの結び付きの確実性はかなり弱くなります。 + </simpara> + <simpara> + テストの際に、最も簡単なページに関してでさえ、全ての可能性をテスト + することは不可能であるということを頭に入れておいて下さい。期待する + 入力は、不機嫌な社員、経験のあるクラッカー、キーボードの上を歩く家 + の猫による入力とは全く無関係でしょう。これが、想定外のデータが入力 + される可能性がある場所を見分けるために論理的な視点からコードを見て、 + その後、修正、減少、または詳細に調べるというのが、最善であるという + 理由です。 + </simpara> + <simpara> + インターネットにはあなたのコードを壊したり、システムを破壊したり、 + 不適切な内容を投稿したり、その他あなたの一日を不快にするようなこと + により自分の名を馳せたいと思う人がたくさんいます。サイトの規模の大 + 小によらず、単にオンラインであり、接続できるサーバを有しているだけ + で攻撃目標となりえます。多くのクラック用プログラムはサイトの大きさ + を考慮せず、犠牲者を探しつつ大きなIPブロックで網を張っています。 + </simpara> + </sect1> + <sect1 id="security.cgi-bin"> <title>CGI バイナリとしてインストール</title> @@ -150,8 +193,10 @@ 通常、Apache 用設定でのリダイレクションは、 次の命令を使用して行います。</simpara> <programlisting role="apache-conf"> +<![CDATA[ Action php-script /cgi-bin/php AddHandler php-script .php +]]> </programlisting> <simpara> このオプションは、Apache Web サーバーでのみテストされており、リク @@ -197,7 +242,6 @@ (以下の <parameter>user_dir</parameter> を除き、)確実に このディレクトリの外側でスクリプトが実行されないようにします。 </simpara> - <simpara> ここで利用可能な別のオプションは、<link linkend="ini.user-dir"> user_dir</link> です。user_dir が設定されていない場合、 @@ -241,7 +285,9 @@ 行に次のような一行を加える必要があることです。 <informalexample> <programlisting> -&num;!/usr/local/bin/php +<![CDATA[ +#!/usr/local/bin/php +]]> </programlisting> </informalexample> また、ファイルを実行可能にしておく必要があります。この場合、実行 @@ -332,14 +378,16 @@ <example> <title>甘い変数の確認から生じるリスク</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php // ユーザのホームディレクトリからファイルを削除する $username = $HTTP_POST_VARS['user_submitted_name']; $homedir = "/home/$username"; $file_to_delete = "$userfile"; unlink ($homedir/$userfile); echo "$file_to_delete は削除されました!"; -?&gt; +?> +]]> </programlisting> </example> usernameはユーザフォームから投稿可能であるため、usernameを投稿し、 @@ -350,7 +398,8 @@ <example> <title>... ファイルシステムへの攻撃</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php // 外部からPHPユーザがアクセス可能なハードドライブを削除します。PHPが // ルートのアクセス権限を有している場合、 $username = "../etc/"; @@ -358,7 +407,8 @@ $file_to_delete = "passwd"; unlink ("/home/../etc/passwd"); echo "/home/../etc/passwd は削除されました!"; -?&gt; +?> +]]> </programlisting> </example> こうした問題を防止するために必要な重要なチェック手段として以下の2 @@ -379,7 +429,8 @@ <example> <title>より安全なファイル名の確認</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php // PHPユーザがアクセス可能なハードドライブからファイルを削除する。 $username = $HTTP_SERVER_VARS['REMOTE_USER']; // 認証機構を使用する @@ -394,7 +445,8 @@ fclose($fp); echo "$file_to_delete は削除されました!"; -?&gt; +?> +]]> </programlisting> </example> しかし、これでも、傷口を塞いだことにはなりません。 @@ -405,7 +457,8 @@ <example> <title>より安全なファイル名の確認</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php $username = $HTTP_SERVER_VARS['REMOTE_USER']; // 認証機構を使用する $homedir = "/home/$username"; @@ -417,7 +470,8 @@ die('bad username'); // 処理せず、終了。 //etc... -?&gt; +?> +]]> </programlisting> </example> </para> @@ -448,10 +502,12 @@ <example> <title>カスタムHTMLページにより変数を攻撃する</title> <programlisting role="php"> -&lt;form method="post" action="attacktarget?username=badfoo&amp;password=badfoo"&gt; -&lt;input type="hidden" name="username" value="badfoo"&gt; -&lt;input type="hidden" name="password" value="badfoo"&gt; -&lt;/form&gt; +<![CDATA[ +<form method="post" action="attacktarget?username=badfoo&password=badfoo"> +<input type="hidden" name="username" value="badfoo"> +<input type="hidden" name="password" value="badfoo"> +</form> +]]> </programlisting> </example> </para> @@ -473,11 +529,13 @@ <example> <title>一般的なデバッグ変数を探す</title> <programlisting role="php"> -&lt;form method="post" action="attacktarget?errors=Y&amp;showerrors=1"&amp;debug=1"&gt; -&lt;input type="hidden" name="errors" value="Y"&gt; -&lt;input type="hidden" name="showerrors" value="1"&gt; -&lt;input type="hidden" name="debug" value="1"&gt; -&lt;/form&gt; +<![CDATA[ +<form method="post" action="attacktarget?errors=Y&showerrors=1"&debug=1"> +<input type="hidden" name="errors" value="Y"> +<input type="hidden" name="showerrors" value="1"> +<input type="hidden" name="debug" value="1"> +</form> +]]> </programlisting> </example> </para> @@ -527,14 +585,16 @@ <example> <title>E_ALLで危険な変数を見つける</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php if ($username) { // 使用前に初期化または確認されていない変数 $good_login = 1; } if ($good_login == 1) { // 上のテストが失敗した場合、使用前に初期化または確認されていない fpassthru ("/highly/sensitive/data/index.html"); } -?&gt; +?> +]]> </programlisting> </example> </para> @@ -557,7 +617,8 @@ <example> <title>register_globals=offを指定しない場合の動作</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php if ($username) { // get/post/cookiesで上書きされる可能性がある $good_login = 1; } @@ -565,19 +626,22 @@ if ($good_login == 1) { // get/post/cookiesで上書きされる可能性がある fpassthru ("/highly/sensitive/data/index.html"); } -?&gt; +?> +]]> </programlisting> </example> <example> <title>register_globals = offを指定した場合の動作</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php if($HTTP_COOKIE_VARS['username']){ // クッキーから来るもののみ $good_login = 1; fpassthru ("/highly/sensitive/data/index.html"); } -?&gt; +?> +]]> </programlisting> </example> これを賢く使用することにより、偽の入力が試みされた際に警告を @@ -589,22 +653,24 @@ <example> <title>簡単な変数の汚染の有無の検出</title> <programlisting role="php"> -&lt;?php -if ($HTTP_COOKIE_VARS['username'] &amp;&amp; - !$HTTP_POST_VARS['username'] &amp;&amp; +<![CDATA[ +<?php +if ($HTTP_COOKIE_VARS['username'] && + !$HTTP_POST_VARS['username'] && !$HTTP_GET_VARS['username'] ) { // ユーザ名を認証する他の手段を実行する $good_login = 1; fpassthru ("/highly/sensitive/data/index.html"); } else { - mail("admin@example.com", "Possible breakin attempt", $HTTP_SERVER_VARS['REMOTE_ADDR']); - echo "Security violation, admin has been alerted."; + mail("admin@example.com", "侵入が試みられました", $HTTP_SERVER_VARS['REMOTE_ADDR']); + echo "管理者による警告：セキュリティ違反です。"; exit; } -?&gt; +?> +]]> </programlisting> </example> - もちろん、register_globalsをonに変えただけでは、コードが安全である + もちろん、register_globalsをoffに変えただけでは、コードが安全である ことを意味しません。投稿されたデータのあらゆる部分について、他の 手段でも確認する必要がありません。 </para> @@ -620,7 +686,8 @@ <example> <title>危険な変数の使用</title> <programlisting role="php"> -&lt;?php +<![CDATA[ +<?php // ユーザのホームディレクトリからファイルを削除します... または他の誰 // かのディレクトリかも? unlink ($evil_var); @@ -632,7 +699,8 @@ system ($evil_var); exec ($evil_var); -?&gt; +?> +]]> </programlisting> </example> 常に注意してコードをテストし、Webブラウザから投稿された全ての変数 @@ -697,17 +765,21 @@ ファイル拡張子を使用可能です。 <example> <title>PHPを他の言語として隠す</title> - <programlisting role="php"> + <programlisting role="apache-conf"> +<![CDATA[ # PHPコードを他のコード型のようにする AddType application/x-httpd-php .asp .py .pl +]]> </programlisting> </example> または、次のように完全に隠すことも可能です。 <example> <title>PHP拡張子用に未知の型を使用する</title> - <programlisting role="php"> + <programlisting role="apache-conf"> +<![CDATA[ # Make PHP code look like unknown types AddType application/x-httpd-php .bop .foo .133t +]]> </programlisting> </example> または、HTMLコードとして隠すことも可能です。この場合、全てのHTMLファ @@ -715,9 +787,11 @@ 問題があります。 <example> <title>PHP拡張子としてHTML型を使用する</title> - <programlisting role="php"> + <programlisting role="apache-conf"> +<![CDATA[ # 全てのPHPコードをHTMLのように作成する AddType application/x-httpd-php .htm .html +]]> </programlisting> </example> 効率的にこれを使用するには、全てのPHPファイルの名前を上の拡張子に変更 @@ -726,48 +800,6 @@ </para> </sect1> - <sect1 id="security.general"> - <title>一般的な考慮事項</title> - <simpara> - 完全に安全なシステムは理想の産物でしかないため、セキュリティ業界で - しばしば使用される手法は、リスクと利便性のバランスのとれた手法です。 - 変数がユーザから投稿される度に(網膜スキャンと指紋のような)2種類の - 生体認証が必要だとしたら、極端に高いレベルの説明義務を生じます。ま - た、かなり複雑なフォームを埋めるために30分もかかるとすれば、ユーザ - がセキュリティをバイパスする手段を探す気分にさせる傾向があります。 - </simpara> - <simpara> - 最善のセキュリティは、通常、ユーザによる業務の達成を防たげずに要求 - を十分に達成できる程度にさしでがましくないものです。むしろ、いくつ - かのセキュリティ攻撃は、単純にこの種の多げさに構築され、時間を浪費 - しがちなセキュリティ機構を狙うものです。 - </simpara> - <simpara> - 記憶するに値する言葉として次のようなものがあります。「システムは鎖 - の最も弱い輪と同程度に優れている」全てのトランザクションが時間、場 - 所、トランザクションの型等に基づき大量に記録されているが、ユーザは - 一つのクッキーのみにより認証されている場合、ユーザとそのトランザク - ションログの結び付きの確実性はかなり弱くなります。 - </simpara> - <simpara> - テストの際に、最も簡単なページに関してでさえ、全ての可能性をテスト - することは不可能であるということを頭に入れておいて下さい。期待する - 入力は、不機嫌な社員、経験のあるクラッカー、キーボードの上を歩く家 - の猫による入力とは全く無関係でしょう。これが、想定外のデータが入力 - される可能性がある場所を見分けるために論理的な視点からコードを見て、 - その後、修正、減少、または詳細に調べるというのが、最善であるという - 理由です。 - </simpara> - <simpara> - インターネットにはあなたのコードを壊したり、システムを破壊したり、 - 不適切な内容を投稿したり、その他あなたの一日を不快にするようなこと - により自分の名を馳せたいと思う人がたくさんいます。サイトの規模の大 - 小によらず、単にオンラインであり、接続できるサーバを有しているだけ - で攻撃目標となりえます。多くのクラック用プログラムはサイトの大きさ - を考慮せず、犠牲者を探しつつ大きなIPブロックで網を張っています。 - </simpara> - </sect1> - <sect1 id="security.current"> <title>最新版を維持する</title> <simpara> @@ -782,7 +814,6 @@ とです。 </simpara> </sect1> - </chapter> <!-- Keep this comment at the end of the file