「開発:セキュリティ」の版間の差分
Mitsuhiro Yoshida (トーク | 投稿記録) |
Mitsuhiro Yoshida (トーク | 投稿記録) |
||
126行目: | 126行目: | ||
* moodleformを使用しない場合、適切な'''PARAM_...'''タイプおよび'''optional_param'''または'''required_param'''を使用してください。 | * moodleformを使用しない場合、適切な'''PARAM_...'''タイプおよび'''optional_param'''または'''required_param'''を使用してください。 | ||
** 直接、$_GET、$_POSTまたは$_REQUESTにアクセスしないでください。 | ** 直接、$_GET、$_POSTまたは$_REQUESTにアクセスしないでください。 | ||
** | ** 簡単に見つけやすいように、optional_paramおよびrequired_paramコールのグループは、スクリプトのトップに置いてください。 | ||
Similarly, clean data from other external resources like RSS feeds before use. | Similarly, clean data from other external resources like RSS feeds before use. |
2010年2月20日 (土) 15:03時点における版
作成中です - Mitsuhiro Yoshida 2010年1月9日 (土) 15:53 (UTC)
このページでは、不道徳な人たちが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は非常に柔軟なシステムであり、管理者は複数のロールを定義することができます。それぞれのロールは、システムレベルで定義された一連のケイパビリティであり、ロールは、低いレベルのコンテクストでのオーバーライドにより、修正することができます。リスクは、それぞれのケイパビリティの記述であり、管理者は、信頼できるユーザのみが潜在的に危険なケイパビリティを持てるよう確認すべきです。
セキュリティ脆弱性の一般的なタイプ
- 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
ガイドラインの要約
ユーザを認証する
- 非常に少ない例外として、可能な限りトップの近くで、すべてのスクリプトは、require_login または require_course_login をコールする必要があります。
コースおよびモジュールアクセスを確認する
- すべてのコースエリアは、正しい $course パラメータを使用して、"require_login" または "require_course_login" により保護される必要があります。
- すべてのモジュールエリアは、正しい $course および $cm パラメータを使用して、"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コールのグループは、スクリプトのトップに置いてください。
Similarly, clean data from other external resources like RSS feeds before use.
出力前にデータをクリーニングおよびエスケープする
- 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.
データベースに保存する前にデータをエスケープする
- 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
シェルコマンドで使用する前にデータをエスケープする
- 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.
すべてのリクエストをログに記録する
- Every script should call add_to_log.
他の優れた実践
... 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:
< > & < > & ' \' 碁 \ \\