サイト脆弱性をチェックしよう！--第1回：ウェブアプリケーションに潜む危険 - (page 3)

　「メール送信機能」の悪用では、たとえばアンケート結果をメールで送信する機能を搭載したアプリケーションがあったとしよう。このアプリケーションは送信先をHiddenパラメータで指定するような設計になっていた場合、攻撃者がこのアプリケーションを使ってSPAMメールを送信することができる。

　対策としては、送信先をパラメータで指定するのではなく、設定ファイルで指定することで悪用することを防ぐことができる。

　また「パスワードエラー通知機能」の悪用では、たとえばログイン時にパスワードを間違っていたら「パスワードエラー」と表示し、ユーザーIDが間違っていたら「存在しないユーザーです」と表示するアプリケーションが考えられる。

　この場合、攻撃する側にとって存在しているユーザーが判明するため、ブルートフォース攻撃（パスワードとユーザーIDの組み合わせを総当りでログイン試行する攻撃）を短時間に行うことができるようになる。

　どんなメッセージでも、攻撃者には有用な情報となるため、可能な限りメッセージは内部の情報が分からないようにすべきだろう。特にエラー内容の詳細を画面に表示することはアプリケーション内部の重要な情報を攻撃者に与えることになる。

　エラーメッセージは内部で何が起こったかを記述するのではなく、例えば「エラーが発生しました。再度実行してください」といった簡単なものを表示し、エラーの詳細は安全な場所に保存されるログに出力するようにするべきだ。

　この例の場合であれば、パスワードおよびユーザーIDのどちらが間違っていても、「ユーザIDもしくはパスワードが違います」と同じメッセージを表示することで、より安全なアプリケーションになる。

　さらに「バックドアとデバッグオプション」の悪用は、たとえばシステムの障害が発生した場合のために、デバッグオプションやバックドアをあらかじめ準備しておくことがある。このとき、デバッグモードを起動するためのパラメータやバックドアを利用されると内部情報が漏えいしたり、サーバに侵入されることになる。

　このような機能は悪用されるので、極力実装しないことが望ましいのだが、デバッグに便利であるため、機能として搭載したいときがある。この場合、デバッグモード、バックドアの起動を制御するパラメータを利用するのではなく、設定ファイルに記述した内容をもとに起動を制御することで、デバッグモード、バックドアを安全に利用することができる。

まとめ

　今回、紹介した脆弱性はすべて、設計時にその機能を実装することにより、どのようなリスクがあるかを十分に検討し、リスクを軽減するための機能を設計／実装することで悪用を防ぐことができる。

　また、取り扱う情報についても漏えい、改ざんされた場合にどのような被害があるのか十分に検討し、被害にあうと損失が大きい場合には、被害を最小限にできる設計をしておく必要がある。

　設計時に機能、取り扱う情報にどのような脅威があり、どの程度重要なものなのかを検討し、その脅威に対して重要度に見合った対策を行うことで、より安全なアプリケーションを設計、構築することができるようになる。

　次回は、コーディング時に発生する脆弱性について解説したいと思う。