
適切なセキュリティ対策を施すことでサイトをハッカーの攻撃から守ることができます。この記事では、サイトのセキュリティリスクを軽減する方法について説明します。
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 8初心者講座バックナンバー
Drupal初心者講座について
第1回 歴史に見るDrupal のDNA
第2回 Drupalはフレームワークか?CMSか?
第3回 Drupalの特徴
第4回 Drupal 8のインストール(1)
第5回 Drupal 8のインストール(2)
第6回 コンテンツを投稿してみる
第7回 ボキャブラリとタクソノミーを使う
第8回 コンテンツ管理におけるDrupalと他のCMSとの比較
第9回 Drupal 8のブロックシステム
第10回 Drupalの標準クエリービルダ Views
第11回 Drupalと他のCMSのクエリビルダー機能を比較
第12回 Drupal 8の多言語機能と他のCMSやサービスとの比較
第13回 Drupalの権限設定とWordPressやMovable Typeとの比較
第14回 Drupalのテーマシステムについて
第15回 Drupalの拡張モジュールの選定と利用方法
第16回 Drupalをもっと知りたい方に向けた各種情報