適切なセキュリティ対策を施すことでサイトをハッカーの攻撃から守ることができます。この記事では、サイトのセキュリティリスクを軽減する方法について説明します。
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.とMy Dad, the Drupal Security Expert | Drupal Watchdog を参照して下さい。
終わりに
DrupalのモジュールやAPIを正しく利用すれば、SQLインジェクション、XSS、CSRFなどへのセキュリティ対策は自動的に行われます。
「Drupalは頻繁にセキュリティ更新が入るので脆弱性が多いのではないか」と言われることがありますが、これは専門のセキュリティーチームによるメンテナンスがしっかりと行われているという結果の裏返しです。世の中には完璧なソフトウェアなどありませんので、ユーザーが少なかったりメンテナンスがされておらず更新されないプロダクトの方が遥かに危険でしょう。
過去のセキュリティ監査では、一般にセキュリティホールの大部分(90%以上)が、そのサイトの開発者が作成したカスタムテーマまたはモジュールに存在することが判明しています。
https://www.drupal.org/documentation/is-drupal-secure
つまり、脆弱性の殆どはDrupal自体ではなく、それを利用したりカスタマイズしたりする我々自身が作り出しているということです。Drupal自体の品質を疑うよりは、ユーザーのリテラシーは十分か、開発や保守をしているエンジニアが十分にDrupalやセキュリティに関する知識と経験を持っているか、などを確認したほうがいいでしょう。
関連コンテンツ
- 11月に公開された複数のセキュリティアドバイザリーについて
- Drupal Core の脆弱性について (SA-CORE-2024-001)
- Drupal Core の脆弱性について (SA-CORE-2023-006)
- Drupal 導入前に必ず考えたい「保守」のこと
- Drupal Core の脆弱性について (SA-CORE-2023-005)
- Drupal Core の脆弱性について (SA-CORE-2023-004)
- Drupal Core の脆弱性について (SA-CORE-2023-003)
- Drupal Core の脆弱性について (SA-CORE-2023-002)
- Drupal Core の脆弱性について (SA-CORE-2023-001)
- Drupal Core の脆弱性について (SA-CORE-2022-016)
Drupal 初心者講座バックナンバー
- Drupal 9/10 初心者講座
- 第 1 回 歴史に見る Drupal の DNA
- 第 2 回 Drupal はフレームワークか?CMS か?他の CMS との比較
- 第 3 回 Drupal の特徴
- 第 4 回 Drupal 9 / 10 のインストール (1)
- 第 5 回 Drupal 9 / 10 のインストール (2)
- 第 6 回 Drupal にコンテンツを投稿してみる
- 第 7 回 Drupal のボキャブラリとタクソノミーの使い方
- 第 8 回 コンテンツ管理における Drupal と他の CMS との比較
- 第 9 回 Drupal のブロックシステム
- 第 10 回 Drupal の標準クエリビルダー Views の使い方
- 第 11 回 Drupal と他の CMS のクエリビルダー機能を比較
- 第 12 回 Drupal の多言語機能と他の CMS やサービスとの比較
- 第 13 回 Drupal の権限設定と WordPress や Movable Type との比較
- 第 14 回 Drupal のテーマシステムについて
- 第 15 回 Drupal の拡張モジュールの選定と使い方
- 第 16 回 Drupal をもっと知りたい方に向けた各種情報