開発:セキュリティ

作成中です - Mitsuhiro Yoshida 2010年1月9日 (土) 15:53 (UTC)

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

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

1. 危険性とは
2. トラブルを避けるため、Moodleはどのように設計されているか
3. Moodle開発者として、あなたのコードをセキュアなものにするには何をすべきか
4. あなたの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は非常に柔軟なシステムであり、管理者は複数のロールを定義することができます。Each role is a set of capabilities defined at system level, roles may be modified via overrides at lower context levels. Risks are part of description of each capability, administrators have to make sure only trusted users get potentially dangerous capabilities.

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

• Unauthenticated access
• Unauthorised access
• Cross-site request forgery (XSRF)
• クロスサイトスクリプティング (Cross-site scripting) (XSS)
• SQLインジェクション
• Command-line injection
• Data-loss
• Confidential information leakage
• Configuration information leakage
• Session fixation
• Denial of service
• Brute-forcing login
• Insecure configuration management
• Buffer overruns, and other platform weaknesses
• 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

• Before allowing the user to see anything or do anything, call to has_capability or require_capability.
• Capabilities should be annotated with the appropriate risks.
• If appropriate, restrict what people can see according to groups.

Don't trust any input from users

• Use moodleforms whenever possible, with an appropriate setType method call for each field.
• 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

• Use s or p to output plain text content.
• 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 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

• 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 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.
  • Look to see if there is a PHP library instead.
• If you can't avoid shell commands, use escapeshellcmd and escapeshellarg.

Log every request

• Every script should call 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.
• 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:

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

関連情報

• 開発:コーディング