情報セキュリティ
ウェブサイトの中には、運営者のセキュリティに対する認識のなさから、不適切な設計で作成されたウェブサイトが運用されていることがあります。本節では、脆弱性関連情報として届出を受けた「アクセス制御」や「認可制御」等の機能欠落に伴う脆弱性についての対策を紹介します。
ウェブサイトで非公開とされるべき情報を取り扱う場合や、利用者本人にのみデータの変更や編集を許可することを想定する場合等には、アクセス制御機能の実装が必要です。
しかし、たとえば、個人情報を閲覧する機能にアクセスするにあたり、メールアドレスのみでログインできてしまうウェブサイトが、脆弱なウェブサイトとして届出を受けた例があります。
一般に、メールアドレスは他人にも知られ得る情報であり、そのような情報の入力だけで個人情報を閲覧できてしまうのは、アクセス制御機能が欠落していると言えます(*1)。
パスワード等(みだりに第三者に知らせてはならないものとして一般に考えられている情報)の入力を必要とするようにウェブアプリケーションを設計し、実装してください。
ウェブサイトにアクセス制御機能を実装して、利用者本人にのみデータの閲覧や変更等の操作を許可する際、複数の利用者の存在を想定する場合には、どの利用者にどの操作を許可するかを制御する、認可(Authorization)制御の実装が必要となる場合があります。
アクセス制御機能が装備されたウェブアプリケーションの典型的な実装では、ログインした利用者にセッションIDを発行してセッション管理を行い、アクセスごとにセッションIDからセッション変数等を介して利用者IDを取得できるように構成されています。単純な機能のウェブアプリケーションであれば、その利用者IDをキーとしてデータベースの検索や変更を行うように実装することができ、この場合は、利用者のデータベースエントリしか操作されることはないので、認可制御は結果的に実装されていると言えます。
しかし、ウェブサイトによっては、利用者IDをURLやPOSTのパラメータに埋め込んでいる画面が存在することがあります。そのような外部から与えられる利用者IDをキーにしてデータベースを操作する実装になっていると、ログイン中の利用者ならば他の利用者になりすまして操作できてしまうという脆弱性となります。
これは、認可制御が実装されていないために生じる脆弱性です。データベースを検索するための利用者IDが、ログイン中の利用者IDと一致しているかを常に確認するよう実装するか、または、利用者IDを、外部から与えられるパラメータから取得しないで、セッション変数から取得するようにします。
また、他の例として、たとえば注文番号等をキーとしてデータベースの検索や変更を行う機能を持つウェブアプリケーションの場合、注文番号がURLやPOSTのパラメータで与えられる実装になっていると、ログイン中の利用者であれば、他人用に発行された注文番号をURLやPOSTのパラメータに指定することによって、他の利用者にしか閲覧できないはずの注文情報等を閲覧することができてしまう脆弱性が生じることがあります。
これも、認可制御が実装されていないために生じる脆弱性です。データベースを検索するための注文番号が、ログイン中の利用者に閲覧を許可された番号であるかどうかを常に確認するように実装してください。