ANNAIマガジン
security
この記事の目次

適切なセキュリティ対策を施すことでサイトをハッカーの攻撃から守ることができます。この記事では、サイトのセキュリティリスクを軽減する方法について説明します。

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やセキュリティに関する知識と経験を持っているか、などを確認したほうがいいでしょう。

 
フッターの採用情報
 
Yoshikazu Aoyamaの写真

この記事を書いた人: Yoshikazu Aoyama

昔は回線交換やL2/L3のプロトコルスタックの開発をしてました。その後、組み込みLinuxやJava/Ruby on RailsなどのWebシステム開発などを経て現職。
インフラからDrupalのモジュール開発、Drupal以外の開発までなんでもやります。
普段は札幌で猫と一緒にリモートワークしています。 好きなモジュールは Restful Web Services と Rules

関連コンテンツ