
適切なセキュリティ対策を施すことでサイトをハッカーの攻撃から守ることができます。この記事では、サイトのセキュリティリスクを軽減する方法について説明します。
Drupalにおけるセキュリティに関するベストプラクティス
Drupalを正しく使用していれば、セキュリティ上問題ありません。ただし、サイトをカスタマイズするとなると、予期しないセキュリティ上の問題が発生する可能性があります。信頼できるユーザーのみにセキュリティリスクを伴うアクセス権限与える必要があります。
Drupalコアやモジュールのアップデートを常に行う
アップデートにより適用される修正や改善などがサイトに直接影響しない場合は、モジュールのアップデートを行わないという選択肢もあります。しかし、セキュリティに関するアップデートの場合は早急に更新プログラムを適用する必要があります。
セキュリティに関する情報は Drupal.orgのセキュリティアナウンスメントを購読しましょう。
強力なパスワードを使用する
パスワードはサイトセキュリティ上のリスクの原因になる可能性の最も高いものです。
Password Policy moduleを利用すると、パスワードの文字数や、使用可能な文字列の種類など
パスワードを設定時に制約を設けることができます。また、パスワードの有効期限を設定することもできます。
ファイルのアップロードを制限し、配信されるファイルを制限する
アップロード可能なファイルの種類を制限し、信頼できるユーザーのみにファイルをアップロードする権限を与えます。コンテンツタイプでフィールドアップロードが許可されているファイルの種類を確認してください。
Security Reviewモジュールの使用
セキュリティレビューモジュールは、サイトの設定を分析し、エラーを修正する方法を知らせます。
このモジュールは、ステージングやテストサイトでのみ使用してください。
本番サイトではこのモジュールを無効化、削除しましょう。
カスタムコードへの攻撃を防ぐ方法
テーマやモジュール内にカスタムコードを使用する場合には、以下の3種類の攻撃に注意してください。
SQLインジェクションを防ぐ方法
- 間違い :
- Drupal APIを使用するのではなく、コードでSQLクエリを使用する。
- 具体例 :
- db_query("select * from table where id=$_GET[‘id’]");
のようなコードを書いてしまうと、example.com/index .php?id=1 に
アクセスすることで、User 1の情報が取得されてしまうかもしれません。 - 解決策 :
- Drupalのデータベース抽象化レイヤーを使用します。
詳細はこちら : Database abstraction layer を参照してください。
XSSクロスサイトスクリプティングを防ぐ方法
- 間違い:
- 閲覧者のパラメータをチェックせずに表示すると、他のユーザーが閲覧したページに悪意のある攻撃者がクライアントサイドのスクリプトを挿入する事が可能な状態になる。
- 具体例:
- <?php echo "Your number is ". $_GET['id']; ?>
のようなコードを書いてしまうと
index.php?id=<script>alert("UAAAT??");</script>
にアクセスすることで、任意のスクリプトを挿入される危険性があります。 - 解決策:
- 信頼できないユーザーからの入力は、ブラウザにレンダリング結果を返す前に必ず、サニタイズまたはフィルタリングする。
詳細はこちら:クロスサイトスクリプティング(XSS)とDrupal
CSRF(クロスサイトリクエストフォージェリ)を防ぐ方法
- 間違い:
- ワイルドカード(%)を含むURLは保護されておらず、直接フォームコードがサイトに入力されます。
フォームからのHTTP Postは、あなたのサイトだけでなく、どこからでもリクエストを発信できます。 - 解決策:
- DrupalのForm APIを使用してください。これらのAPIは、すべてのフォームにトークンを挿入することで攻撃を防ぎます。保護する必要があるURLをレンダリングする場合は、フォームAPIで確認を求めるか、URLでトークンを使用して、トークンが存在し、応答が有効であることを確認してください。
詳細はこちら:Introduction to cross-site request forgery.
Acquiaの図書館でDrupalのセキュリティ専門家になる方法を学んでください!
終わりに
DrupalのモジュールやAPIを正しく利用すれば、SQLインジェクション、XSS、CSRFなどへのセキュリティ対策は自動的に行われます。
「Drupalは頻繁にセキュリティ更新が入るので脆弱性が多いのではないか」と言われることがありますが、これは専門のセキュリティーチームによるメンテナンスがしっかりと行われているという結果の裏返しです。世の中には完璧なソフトウェアなどありませんので、ユーザーが少なかったりメンテナンスがされておらず更新されないプロダクトの方が遥かに危険でしょう。
過去のセキュリティ監査では、一般にセキュリティホールの大部分(90%以上)が、そのサイトの開発者が作成したカスタムテーマまたはモジュールに存在することが判明しています。
https://www.drupal.org/documentation/is-drupal-secure
つまり、脆弱性の殆どはDrupal自体ではなく、それを利用したりカスタマイズしたりする我々自身が作り出しているということです。Drupal自体の品質を疑うよりは、ユーザーのリテラシーは十分か、開発や保守をしているエンジニアが十分にDrupalやセキュリティに関する知識と経験を持っているか、などを確認したほうがいいでしょう。
関連コンテンツ
- Drupal Core の脆弱性について (SA-CORE-2021-001)
- Drupal Coreの脆弱性について(SA-CORE-2019-009)
- Drupal Coreの脆弱性について(SA-CORE-2019-011)
- Drupal Coreの脆弱性について(SA-CORE-2019-010)
- Drupal Coreの脆弱性について(SA-CORE-2019-012)
- ANNAIからのお知らせ 脆弱性SA-CORE-2018-004 に関しまして
- Drupalのセキュリティアップデートに関するANNAIの考え方
- ANNAIからのお知らせ 脆弱性SA-CORE-2018-002 に関しまして
- 脆弱性SA-CORE-2018-002に関するFAQ
- Drupal 8導入前に必ず考えたい「保守」のこと
Drupal 9初心者講座バックナンバー
-
Drupal初心者講座について
-
第1回 歴史に見るDrupal のDNA
-
第2回 Drupalはフレームワークか?CMSか?
-
第3回 Drupalの特徴
-
第4回 Drupal 9のインストール(1)
-
第5回 Drupal 9のインストール(2)
-
第6回 コンテンツを投稿してみる
-
第7回 ボキャブラリとタクソノミーを使う
-
第8回 コンテンツ管理におけるDrupalと他のCMSとの比較
-
第9回 Drupal 9のブロックシステム
-
第10回 Drupalの標準クエリービルダ Views
-
第11回 Drupalと他のCMSのクエリビルダー機能を比較
-
第12回 Drupal 9の多言語機能と他のCMSやサービスとの比較
-
第13回 Drupalの権限設定とWordPressやMovable Typeとの比較
-
第14回 Drupalのテーマシステムについて
-
第15回 Drupalの拡張モジュールの選定と利用方法
-
第16回 Drupalをもっと知りたい方に向けた各種情報