タイトル
Webアプリケーションのセキュリティ完全対策―不正アクセスや情報漏洩を防ぐ
著者
徳丸 浩 (著), 田畑 拓 (著), 三好 雅貴 (著), 園田 健太郎 (著)
出版社
日経BP社
Amazonで購入する

セキュリティーとか個人情報保護とか、ソフトウェア開発においても守るべきこと、気をつけるべきことがたくさんあります。特に、Webアプリケーションでは、不特定多数のクライアントから、ネットワークを通じてアプリケーションを動作させます。

クライアント側で何を行われているか、サーバーサイドからでは分からない分、スタンドアローンのアプリケーションに比べて、注意する点が多くあります。入力値のチェックから、SQLインジェクション、セッション乗っ取りなど、さまざまなことに対処しなければなりません。

本書では、Webアプリケーションに焦点を当てて、実際の攻撃方法とその予防策を例を挙げて説明しています。Webアプリケーション開発において、最低限対応しなければならないことが分かりやすく説明されています。本書に載っている予防は、ベター(better) ではなく マスト(must) の要件になります。

覚書き

セキュア・プログラミングの一般原則

とにかく、セキュアなシステムを作ろうと思ったら、「信用」しないことが大切。プログラム同士はもとより、クライアントから送られてきたデータは、絶対にそのまま信頼しない。セキュアなシステムを構築するには、以下の点に注意する。

フェイルセーフ
不測の事態、エラーが少しでも起こったら、直ちに安全な方向に処理を誘導する。
明示的に許可されないもの以外はすべて禁止
許可できない文字を決めるのではなくて、許可できる文字を決めてそれ以外はすべて禁止するように処理を施す。
相互不信
プログラム同士はお互いに信用しない。クライアントの入力を、チェックなしで許可するようには絶対にしない。
最低限のユーザ権限
アプリケーションを実行するユーザの権限は、最低限のものにしておく。管理者権限で動かすようなことはしない。

Webアプリケーションの一般原則

Webアプリケーションは特にセキュリティを意識しなければならないシステムの一つです。

入力文字種チェック
アプリケーション仕様で許可された文字以外はすべて禁止するようにして、不正な文字列を入力されてもビクともしないようにする。
エスケープ処理
入力文字に関して、エスケープ処理を施す。Webブラウザでの特殊文字「”」「&」「<」「>」や、SQL文で使われるクウォート、コメント文字などをエスケープして、不正な処理を行えないようにする。
Webサーバの設定
Webサーバの設定で、公開を意図していないファイルに関して保護できるような設定を心がける。
セッション管理
HIddenフィールドやCookieの使い方に気をつけ、セッション乗っ取りされないようにする。

ディレクトリ・リスティング

内容

ディレクトリ配下にあるファイルの一覧を見られてしまう。それによって、重要なファイルが置いてあったり、公開を意図していないファイルをダウンロードされてしまったりする。

原因

主な原因はWebサーバの設定にある。基本的に、ディレクトリ名で終了されたURLは、index.html/index.htm というファイルがなければ、ファイルの一覧を表示する仕組みになっている。

対策

主な対策としては、すべてのディレクトリに、「index.html」ファイルを置く。これは、ほとんどのWebサーバでデフォルトの表示ファイルが index.html になっていることに帰伏する。そのほか、Webサーバの設定で、ディレクトリ一覧を表示しないようにすることでも対応できる。

その他

ディレクトリ・リスティング以外にも、類推しやすいファイル名を付けてしまうと、URLを直接入力された場合に見つけられてしまう可能性がある。重要なファイルは、公開ディレクトリに置かないことが大切であり、一時的に公開ディレクトリにおく場合でも、類推しにくいランダムな値をファイル名にしたりする処置をとる必要がある。

SQLインジェクション

内容

ユーザの入力によって、不正なSQL文が実行されてしまい、データの改ざんや個人情報の流出、成りすましなどがおこなわれてしまう。

原因

ユーザの入力をそのままSQL文として使ってしまう。SQL文で使われるパラメータなどは、適切にエスケープする必要がある。

対策

ビジネスルールに従って、不正な入力は入力エラーとしてチェックする。不正な入力ではないが、SQLの特殊文字だった場合には、適切にエスケープする。言語に実装されている、「コンパイル済みSQL」を使って、エスケープ抜けを防ぐこともできる。

その他

SQLインジェクションの例としては、「’ (シングルクウォート)」を入力される場合に起こることが多い。また、「– (コメント)」 の入力を許可した場合にも起こる。

クロスサイト・スクリプティング (XSS)

内容

Webページに埋め込まれたリンクなどによって、不正な JavaScript や VBScript が実行され、ユーザの成りすましやCookie による個人情報の漏洩などが起こる。

原因

掲示板など、入力された文字をそのまま画面に出力してしまう場合に起こる。悪意のあるスクリプトによって、Cookie などの情報が漏洩してしまい、ユーザの成りすましやセッションハイジャックなどが起こる。

対策

HTMLタグの適切なエスケープ。「<」「>」「&」「”」などを、それぞれ「&lt;」「&lt;」「&amp;」「&quot;」にエスケープする。

その他

掲示板や、ゲストブックなどの、HTMLタグを含む文字列を入力された場合に発生する場合があるので注意。

チェックリスト

本書に書かれていることを実践して、初めて「最低限のセキュリティが保たれる」レベルになると思います。本書は、非常に基礎的でオーソドックスなポイントを紹介しています。ですが、これだけでは絶対に足りないと思います。セキュリティポリシーを定めたり、日ごろからログのチェックを行ったりといったことも実践していくべきです。

本書に載っている点で、心にとまった点をリストアップしておきます。

  1. ファイアーウォールは、セキュリティホールに関しては無力
  2. 画面遷移の正当性チェックを「Referrer」のみに依存させない。Referrer は容易に書き換えられる
  3. HTMLエンコードを怠ると、「クロスサイトスクリプティング」の餌食にされる
  4. フェイルセーフを心がける
  5. 許可していないものはすべて禁止
  6. プログラム同士をお互いに信用しない
  7. アプリケーションは、最低限のユーザ権限で実行する
  8. 入力文字チェックを忘れない
  9. エスケープ処理を忘れない
  10. Webサーバの設定は適切か
  11. Hiddenフィールドや Cookie に重要な情報を持たせない
  12. ディレクトリ・リスティングされないようになっているか
  13. 重要なファイルのファイル名を類推しやすいものになっていないか
  14. 公開ディレクトリに不要なファイルが存在しないか
  15. 重要なページが検索エンジンに登録されないようになっているか
  16. HTMLコメントに、設定情報などが書かれていないか
  17. 認証は、安全な方法で行われるようになっているか
  18. データベースへパスワードを格納するとき、「メッセージダイジェスト」になっているか
  19. セッションIDに、連番などの類推しやすい値が使われていないか
  20. URLパラメータの変更で、重要なページが表示されてしまわないか
  21. 一覧画面から詳細画面への遷移で、再度アクセス権限チェックをおこなっているか
  22. Cookie の有効期限は適切か
  23. セキュアページ(SSL)の Cookie は secure 属性が付けられているか
  24. Referrer 漏洩対策にリダイレクタ等の仕組みを使っているか
  25. SQLインジェクション対策がなされているか
  26. チェック漏れのアプリケーション例外が画面に表示されないようになっているか
  27. SQLで使われる特殊文字はエスケープされているか
  28. RDBMSの権限は、最小のものが付与されているか
  29. ファイル名のパスを入力される場合、「パスの乗り換え」が発生しないか
  30. OSコマンドを入力させる場合、安全な方法で実行できているか
  31. HTMLタグが反映されるようになっていないか

参考

@IT 「Webアプリケーションに潜むセキュリティホール」

参考

  • @IT の記事で、Webアプリケーションのセキュリティ対策記事がありました。

@IT 「Webアプリケーションに含むセキュリティホール」

  • 「IPA ISEC セキュア・プログラミング講座」より

IPA ISEC セキュア・プログラミング講座

  • 「マイクロソフトでの必読書」といわれている、セキュリティ対策本です。
  • セキュアなコードを書くための本です。C/C++ プログラマ向けの濃い本です。
  • オライリーから発売している、セキュアプログラミングの本です。