「開発:セキュリティ」の版間の差分

2010年3月10日 (水) 15:27時点における最新版

このページでは、不道徳な人たちがMoodleサイトを攻撃できないよう、セキュアなMoodleコードを書く方法を記述します。

また、ページでは、一般的なタイプの脆弱性について整理しています。それぞれのタイプに関して、以下のことを説明します:

危険性とは
トラブルを避けるため、Moodleはどのように設計されているか
Moodle開発者として、あなたのコードをセキュアなものにするには何をすべきか
あなたのMoodleをさらに安全にするため、管理者として何をすべきか

それぞれの脆弱性に関する説明は、下記一覧にリンクされるページにあります。

また、このページでは、ガイドラインのキーとなる内容すべてに関して、要約しています。

ウェブアプリケーションのセキュリティ

ウェブアプリケーションをセキュアにするための必要条件

いくつかの法人では、ウェブアプリケーションに関して、最大レベルのセキュリティを要求しています。多くの場合、あなたは類似の一般的な推奨内容を読むことになります:

管理バックエンドを分離する。
ウェブアプリケーションに機密情報を保存しない。
SSLを使用して、コミュニケーションを暗号化すべき。
ユーザすべての行動をログに記録する。
サーバアプリケーションは、完全に分離されるべき。
ユーザからサーバにファイルをアップロードさせない。
ユーザからサーバにリッチテキストを入力させない (プレインテキストのみに制限する)。
分離されたチャネル経由で、ユーザIDおよび操作を認証する。
すべてのソフトウェアを常に最新にする。
サードパーティのブラウザ拡張モジュールを推奨しない。
1つのウェブページのみ使用して、異なるサイトを複数のウィンドウで開かない。セキュアアプリケーションを使用する前および後に、ブラウザを閉じる/開く。

ウェブベースのバンキングシステムは、これらの「セキュア」なウェブアプリケーションの良い例です。ここではセキュリティが最優先されます - セキュリティ上の問題は、顧客、銀行または保険会社にコストを発生させ、銀行の世間一般に対するイメージも失墜させます。限定要因は、アプリケーション開発、メンテナンス、ユーザビリティであると考えられますが、代替チャネルでのコミュニケーションコストも含まれます。

安定したセキュリティ

今日、あなたは、数多くのウェブアプリケーションがセキュリティデザインのルールに反していることを知ることができます。例えば、ウェブベースのメールシステムでは、添付ファイルとしてリッチテキストを受け入れたり、極めて機密な情報をメールメッセージが含んだりしています。実際のところ、Web 2.0の考え方はセキュリティデザインのルールに直接反して、誰でもコンテンツを送信することができます - アプリケーション開発者/管理者のみ信頼できるコンテンツを追加すべきです。

ウェブアプリケーションを設計する場合、私たちのユーザが何をサポートされるべきか調査して、機能およびセキュリティ間の適切なバランスを探ります。

Moodleセキュリティデザイン

ウェブアプリケーションのセキュリティは、使用目的およびそれぞれのタイプのユーザが利用できる機能に依存します。

ユーザタイプ

管理者

管理者には、以下の権限があります:

すべての設定を変更する
コースを作成する
すべてのコースにアクセスする
言語パックを変更する
すべてのユーザを変更する

間接的に、管理者はシェルおよびPHPコードの実行を許可されます。Moodle管理者は、config.php内のハードコードされた設定により、制限を受ける場合もあります。低水準のサーバでは、管理者はPHPコードを読んで修正することができるため、権限を制限することはできません。

すべての管理者は、完全に信頼された存在です。

教師

通常、教師はコースコンテンツを作成して、学生をコースに登録した後、指導します。また、教師には、以下の権限が必要です:

ファイルのアップロードおよびHTMLテキストの送信
活動の作成および管理
学生の評点および他の個人情報へのアクセス

Javaスクリプト、Flashおよび他のスクリプトを使用してファイルをアップロードすることは、多くの場合、セキュリティ上のリスクがあると考えられます。ユーザセッションに使用する基本的なSCORMパッケージでさえ、HTMLおよびJavaスクリプトにより構成されるため、残念ながら、私たちはこれらのリスクを教師ロールから取り除くことはできません。

ブラウザは、1つのサーバから来るコンテンツすべてを信頼します。また、私たちのコースまたはデータの発信元に関して、知ることはありません。サーバにファイルがアップロードされた場合、それらはサーバアプリケーションの一部となります。サーバに保存されている必要なコード、不必要なコードを区別することは不可能です。

教師アクセスを学生に与えることはできないため、危険なケイパビリティを持った教師すべてを信頼すべきです。理論的には、教師は、管理者アクセスを取得するため、XSSアタックを使用することはできます。

技術的には、教師が他のユーザを攻撃できないシステムを開発することは可能ですが、すべてのJavaスクリプト、Flash、SCORM、Java、HTMLフォーム、SVG等の使用を阻むことになります。

学生

学生はコースに受講登録しますが、信頼されたユーザというわけではありません。学生には、次の権限が必要です:

フォーマットされたテキストを埋め込みイメージおよび添付ファイルと共に投稿する
バイナリドキュメントをアップロードする

アップロードされたファイルは、同じサーバよりブラウザで直接開かれるべきではありません。代わりに、ファイルを異なるドメインから提供するか、ファイルを開く前に、サーバがファイルのローカルハードドライブへのダウンロードを強制させる必要があります。異なるドメインからの信頼されないファイルを提供する機能は、Moodle 2.0に実装されます。

学生が送信したテキストすべては、すべてのページに表示される前にサニタイズされます。これにより、他のユーザによるXSS攻撃を防ぐことができますが、同時にFlash、Javaスクリプト、SVGおよび他のHTMLスクリプトを使えないようにしてしまいます。HTMLのクリーニングには、2つの方法があります - 信頼性の薄いブラックリスティング (KSES) およびさらに堅牢なホワイトリスティング (HTML Purifier) です。

ゲスト

セキュリティ上の理由から、Moodleサイトに登録していないユーザは、ファイルをアップロードすること、データベースに保存されるテキストを送信することは、許可されていません。ゲストユーザは、他のユーザへのスパム送信、HTMLクリーニングルーチンの脆弱性攻撃、他の脆弱性を悪用したり、ソーシャル・エンジニアリングをベースとした攻撃を試みることができます。

Eメール経由でのユーザ登録を有効にしているサイトは、スパムおよび他のタイプの攻撃を防ぐよう、十分な注意が必要です。

ケイパビリティリスク

Moodleは非常に柔軟なシステムであり、管理者は複数のロールを定義することができます。それぞれのロールは、システムレベルで定義された一連のケイパビリティであり、ロールは、低いレベルのコンテクストでのオーバーライドにより、修正することができます。リスクは、それぞれのケイパビリティの記述であり、管理者は、信頼できるユーザのみが潜在的に危険なケイパビリティを持てるよう確認すべきです。

セキュリティ脆弱性の一般的なタイプ

ガイドラインの要約

ユーザを認証する

非常に少ない例外として、可能な限りトップの近くで、すべてのスクリプトは、require_login または require_course_login をコールする必要があります。

コースおよびモジュールアクセスを確認する

すべてのコースエリアは、正しい$courseパラメータを使用して、require_loginまたはrequire_course_loginにより保護される必要があります。
すべてのモジュールエリアは、正しい$courseおよび$cパラメータを使用して、require_loginまたはrequire_course_loginにより保護される必要があります。

パーミッションをチェックする

ユーザが何かを閲覧または何かをする前に、has_capability または require_capabilityをコールしてください。
ケイパビリティは、適切なリスクにより注釈を付けてください。
適切な場合、グループによって、ユーザに表示される内容が制限されます。

ユーザからのインプットすべてを信用しない

それぞれのフィールドに要求される適切なsetTypeを使って、可能な限りmoodleformを使用してください。
処理を実行する前、セッションキーおよびPOSTキーでの処理を確認するため、is_post_with_sesskeyを使用してください。
- Moodle 1.9では、代わりにdata_submitted()およびconfirm_sesskey()を使用してください。
大量のデータを削除する前、確認ステップを入れてください。
moodleformを使用しない場合、適切なPARAM_...タイプおよびoptional_paramまたはrequired_paramを使用してください。
- 直接、$_GET、$_POSTまたは$_REQUESTにアクセスしないでください。
- 簡単に見つけやすいよう、optional_paramおよびrequired_paramコールのグループは、スクリプトのトップに置いてください。

同様に、RSSフィードのような他の外部リソースのデータを使用する前にクリーニングします。

出力前にデータをクリーニングおよびエスケープする

プレインテキストコンテンツの出力には、s または p を使用してください。
multi-lang spanのような最小限のHTMLコンテンツの出力には、format_stringを使用してください (例コースおよび活動名)。
他のすべてのコンテンツを出力するには、format_textを使用してください。
- コンテンツの入力にケイパビリティRISK_XSSを必須とする場合 (例ウェブページリソース)、$options->nocleanのみ使用してください。
Moodle 2.0以前のバージョンでは、optional_paramまたはrequired_paramからの入力内容がデータベースに保存されるのではなく、直接表示される場合、「stripslashes」または「stripslashes_recursive」を適用してください。
Javaスクリプトに向かうデータは、$PAGE->requires->data_for_js (Moodle 2.0) または addslashes_js (Moodle 1.9) を使用して、エスケープしてください。

詳細は、開発:アウトプット関数をご覧ください。

データベースに保存する前にデータをエスケープする

XMLDBライブラリを使用してください。このライブラリは、ほとんどのエスケープに関する問題に対応します。
あなたがカスタムSQLコードを使用する必要がある場合、クエリに値を入れるには、プレスホルダを使用してください。
- Moodle 2.0以前のバージョンでは、あなたは、ストリングを連結してSQLを作成する必要がありました。SQLインジェクションに対する脆弱性を防ぐため、引用値には特に十分注意する必要があります。
Moodle 2.0以前のバージョンでは、データベースから読み込まれるデータは、データベースに書き戻される前に、「addslashes」または「addslashes_object」を適用する必要がありました (Moodle 2.0コードでは、addslashesは使用されません)。
Moodle 2.0において、変数は固定変数を通して、データベースクエリに渡される必要があります。

シェルコマンドで使用する前にデータをエスケープする

可能な限り、シェルコマンドの実行を避けてください。
- PHPライブラリがある場合、代わりに使ってください。
あなたがシェルコマンドの使用を避けられない場合、escapeshellcmdまたはescapeshellargを使用してください。

すべてのリクエストをログに記録する

すべてのスクリプトでは、必ずadd_to_logをコールしてください。

他の優れた実践

... セキュリティに関する助けとなるもの。

あなたのコードを美しく構築して、グローバル変数の使用を最小限にしてください。これにより、データフロー、つまりセキュリティに関して、検証がより簡単になります。
あなたが最初に使用する前、オブジェクト ($x = new stdClass;) および配列 ($x = array()) を初期化してください。
すべての入力フィールドに関して、巧妙な入力により、すべての場所で正しい回数のエスケープおよびエスケープ解除が実施されているかどうかテストしてください。そして、ユニコード文字が文字化けしていないかどうかもテストしてください。ユニコード文字に関する私の標準的な入力は次のとおりです:

< > & &lt; &gt; &amp; ' \' 碁 \ \\

@@ 1行目: / 1行目: @@
-作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] 2010年1月9日 (土) 15:53 (UTC)
 このページでは、不道徳な人たちがMoodleサイトを攻撃できないよう、セキュアなMoodleコードを書く方法を記述します。
@@ 8行目: / 6行目: @@
 # Moodle開発者として、あなたのコードをセキュアなものにするには何をすべきか
 # あなたのMoodleをさらに安全にするため、管理者として何をすべきか
-それぞれの脆弱性に関する説明は、下記一覧でリンクされている、異なるページにあります。
+それぞれの脆弱性に関する説明は、下記一覧にリンクされるページにあります。
 また、このページでは、ガイドラインのキーとなる内容すべてに関して、要約しています。
@@ 31行目: / 29行目: @@
 ===安定したセキュリティ===
-今日、あなたは、数多くのウェブアプリケーションがセキュリティデザインのルールに反していることを知ることができます。例えば、ウェブベースのメールシステムでは、ファイル添付としてリッチテキストを受け入れたり、極めて機密な情報をメールメッセージが含んでいます。実際のところ、Web 2.0の考え方はセキュリティデザインのルールに直接反して、誰でもコンテンツを送信することができています - アプリケーション開発者/管理者のみ信頼できるコンテンツを追加すべきです。
+今日、あなたは、数多くのウェブアプリケーションがセキュリティデザインのルールに反していることを知ることができます。例えば、ウェブベースのメールシステムでは、添付ファイルとしてリッチテキストを受け入れたり、極めて機密な情報をメールメッセージが含んだりしています。実際のところ、Web 2.0の考え方はセキュリティデザインのルールに直接反して、誰でもコンテンツを送信することができます - アプリケーション開発者/管理者のみ信頼できるコンテンツを追加すべきです。
-ウェブアプリケーションを設計する場合、私たちのユーザが何をサポートされるべきなのか調査して、機能およびセキュリティ間に適度なバランスを見つけます。
+ウェブアプリケーションを設計する場合、私たちのユーザが何をサポートされるべきか調査して、機能およびセキュリティ間の適切なバランスを探ります。
 ==Moodleセキュリティデザイン==
@@ 58行目: / 56行目: @@
 * 学生の評点および他の個人情報へのアクセス
-Javaスクリプト、Flashおよび他のスクリプトを使用してファイルをアップロードすることは、多くの場合、セキュリティ上のリスクがあると考えられます。ユーザセッションに使用するため、基本的なSCORMパッケージでさえ、HTMLおよびJavaスクリプトにより構成されるため、残念ながら、私たちはこれらのリスクを教師ロールから取り除くことはできません。
+Javaスクリプト、Flashおよび他のスクリプトを使用してファイルをアップロードすることは、多くの場合、セキュリティ上のリスクがあると考えられます。ユーザセッションに使用する基本的なSCORMパッケージでさえ、HTMLおよびJavaスクリプトにより構成されるため、残念ながら、私たちはこれらのリスクを教師ロールから取り除くことはできません。
-ブラウザは、1つのサーバから来るコンテンツすべてを信頼します。また、ブラウザは、私たちのコースまたはデータの発信元に関して、知ることはありません。サーバにファイルがアップロードされた場合、それらはサーバアプリケーションの一部となります。サーバに保存されている必要なコード、不必要なコードを区別することは不可能です。
+ブラウザは、1つのサーバから来るコンテンツすべてを信頼します。また、私たちのコースまたはデータの発信元に関して、知ることはありません。サーバにファイルがアップロードされた場合、それらはサーバアプリケーションの一部となります。サーバに保存されている必要なコード、不必要なコードを区別することは不可能です。
 教師アクセスを学生に与えることはできないため、危険なケイパビリティを持った教師すべてを信頼すべきです。理論的には、教師は、管理者アクセスを取得するため、XSSアタックを使用することはできます。
@@ 102行目: / 100行目: @@
 * [[開発:セキュリティ:Social engineering|Social engineering]]
-==Summary of the guidelines==
+==ガイドラインの要約==
-===Authenticate the user===
-* With very few exceptions, every script should call '''require_login''' or '''require_course_login''' as near the start as possible.
-===Verify course and module access===
+===ユーザを認証する===
-* all course areas have to be protected by "require_login" or "require_course_login" with correct $course parameter
-* all module areas have to be protected by "require_login" or "require_course_login" with correct $course and $cm parameter
-===Check permissions===
+* 非常に少ない例外として、可能な限りトップの近くで、すべてのスクリプトは、'''require_login''' または '''require_course_login''' をコールする必要があります。
-* Before allowing the user to see anything or do anything, call to '''has_capability''' or '''require_capability'''.
+===コースおよびモジュールアクセスを確認する===
-* Capabilities should be annotated with the appropriate '''[[Development:Hardening_new_Roles_system#Basic_risks|risks]]'''.
+* すべてのコースエリアは、正しい$courseパラメータを使用して、'''require_login'''または'''require_course_login'''により保護される必要があります。
-* If appropriate, restrict what people can see according to '''groups'''.
+* すべてのモジュールエリアは、正しい$courseおよび$cパラメータを使用して、'''require_login'''または'''require_course_login'''により保護される必要があります。
-===Don't trust any input from users===
+===パーミッションをチェックする===
-* Use '''[[Development:lib/formslib.php|moodleforms]]''' whenever possible, with an appropriate '''setType''' method call for each field.
+* ユーザが何かを閲覧または何かをする前に、'''has_capability''' または '''require_capability'''をコールしてください。
-* Before performing actions, use '''is_post_with_sesskey''' to check sesskey and that you are handling a POST request.
+* ケイパビリティは、適切な'''[[開発:新しいロールシステムのハードニング#基本リスク|リスク]]'''により注釈を付けてください。
-** In Moodle 1.9, use '''data_submitted() && confirm_sesskey()''' instead.
+* 適切な場合、'''グループ'''によって、ユーザに表示される内容が制限されます。
-* Before destroying large amounts of data, add a confirmation step.
-* If not using a moodleform, clean input using '''optional_param''' or '''required_param''' with an appropriate '''PARAM_...''' type.
-** Do not access $_GET, $_POST or $_REQUEST directly.
-** Group optional_param and required_param calls together at the top of the script, to make them easy to find.
-Similarly, clean data from other external resources like RSS feeds before use.
+===ユーザからのインプットすべてを信用しない===
-===Clean and escape data before output===
+* それぞれのフィールドに要求される適切な'''setType'''を使って、可能な限り'''[[Development:lib/formslib.php|moodleform]]'''を使用してください。
+* 処理を実行する前、セッションキーおよびPOSTキーでの処理を確認するため、'''is_post_with_sesskey'''を使用してください。
+** Moodle 1.9では、代わりに'''data_submitted()'''および'''confirm_sesskey()'''を使用してください。
+* 大量のデータを削除する前、確認ステップを入れてください。
+* moodleformを使用しない場合、適切な'''PARAM_...'''タイプおよび'''optional_param'''または'''required_param'''を使用してください。
+** 直接、$_GET、$_POSTまたは$_REQUESTにアクセスしないでください。
+** 簡単に見つけやすいよう、optional_paramおよびrequired_paramコールのグループは、スクリプトのトップに置いてください。
-* Use '''s''' or '''p''' to output plain text content.
+同様に、RSSフィードのような他の外部リソースのデータを使用する前にクリーニングします。
-* use '''format_string''' to output content with minimal HTML like multi-lang spans (for example, course and activity names).
-* Use '''format_text''' to output all other content.
-** Only use $options->noclean if it requires a capability with RISK_XSS to input that content (for example web page resources).
-* Before Moodle 2.0, input from optional_param or required_param must have [[Developer:Slashes|'''stripslashes''' or '''stripslashes_recursive''']] applied if it is being output directly, rather than being stored in the database.
-* Data destined for JavaScript should be escaped using '''$PAGE->requires->data_for_js''' (Moodle 2.0) or '''addslashes_js''' (Moodle 1.9).
-See [[Development:Output functions]] for more details.
+===出力前にデータをクリーニングおよびエスケープする===
-===Escape data before storing it in the database===
+* プレインテキストコンテンツの出力には、'''s''' または '''p''' を使用してください。
+* multi-lang spanのような最小限のHTMLコンテンツの出力には、'''format_string'''を使用してください (例 コースおよび活動名)。
+* 他のすべてのコンテンツを出力するには、'''format_text'''を使用してください。
+** コンテンツの入力にケイパビリティRISK_XSSを必須とする場合 (例 ウェブページリソース)、$options->nocleanのみ使用してください。
+* Moodle 2.0以前のバージョンでは、optional_paramまたはrequired_paramからの入力内容がデータベースに保存されるのではなく、直接表示される場合、[[Developer:Slashes|「stripslashes」または「stripslashes_recursive」]]を適用してください。
+* Javaスクリプトに向かうデータは、'''$PAGE->requires->data_for_js''' (Moodle 2.0) または '''addslashes_js''' (Moodle 1.9) を使用して、エスケープしてください。
-* Use the XMLDB library. This takes care of most escaping issues for you.
+詳細は、[[開発:アウトプット関数]]をご覧ください。
-* When you must use custom SQL code, '''use place-holders''' to insert values into the queries.
-** Before Moodle 2.0, you have to build SQL by concatenating strings. Take particular care, especially with quoting values, to avoid SQL injection vulnerabilities.
-* Before Moodle 2.0, data loaded from the database must have [[Developer:Slashes|'''addslashes''' or '''addslashes_object''']] applied to it before it can be written back to the database. (addslashes should no longer be use anywhere in Moodle 2.0 code.)
-* In Moodle 2.0 variables must be passed to database queries through bound parameters
-===Escape data before using it in shell commands===
+===データベースに保存する前にデータをエスケープする===
-* Avoid shell commands if at all possible.
+* XMLDBライブラリを使用してください。このライブラリは、ほとんどのエスケープに関する問題に対応します。
-** Look to see if there is a PHP library instead.
+* あなたがカスタムSQLコードを使用する必要がある場合、クエリに値を入れるには、'''プレスホルダを使用してください'''。
-* If you can't avoid shell commands, use '''escapeshellcmd''' and '''escapeshellarg'''.
+** Moodle 2.0以前のバージョンでは、あなたは、ストリングを連結してSQLを作成する必要がありました。SQLインジェクションに対する脆弱性を防ぐため、引用値には特に十分注意する必要があります。
+* Moodle 2.0以前のバージョンでは、データベースから読み込まれるデータは、データベースに書き戻される前に、[[開発者:スラッシュ|「addslashes」または「addslashes_object」]]を適用する必要がありました (Moodle 2.0コードでは、addslashesは使用されません)。
+* Moodle 2.0において、変数は固定変数を通して、データベースクエリに渡される必要があります。
+===シェルコマンドで使用する前にデータをエスケープする===
-===Log every request===
+* 可能な限り、シェルコマンドの実行を避けてください。
+** PHPライブラリがある場合、代わりに使ってください。
+* あなたがシェルコマンドの使用を避けられない場合、'''escapeshellcmd'''または'''escapeshellarg'''を使用してください。
-* Every script should call '''add_to_log'''.
+===すべてのリクエストをログに記録する===
+* すべてのスクリプトでは、必ず'''add_to_log'''をコールしてください。
-===Other good practice===
+===他の優れた実践===
-... that helps with security.
+... セキュリティに関する助けとなるもの。
-* Structure your code nicely, minimising the use of global variables. This makes the flow of data, and hence security, easier to verify.
+* あなたのコードを美しく構築して、グローバル変数の使用を最小限にしてください。これにより、データフロー、つまりセキュリティに関して、検証がより簡単になります。
-* Initialise objects ($x = new stdClass;) and arrays ($x = array()) before you first use them.
+* あなたが最初に使用する前、オブジェクト ($x = new stdClass;) および配列 ($x = array()) を初期化してください。
-* Test every input field with tricky input to ensure that it is escaped and un-escaped the right number of times everywhere, and that Unicode characters are not corrupted. My standard test input is:
+* すべての入力フィールドに関して、巧妙な入力により、すべての場所で正しい回数のエスケープおよびエスケープ解除が実施されているかどうかテストしてください。そして、ユニコード文字が文字化けしていないかどうかもテストしてください。ユニコード文字に関する私の標準的な入力は次のとおりです:
   <nowiki>< > & &amp;lt; &amp;gt; &amp;amp; ' \' 碁 \ \\</nowiki>

Documentation