情報セキュリティ

安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落

概要

ウェブサイトの中には、運営者のセキュリティに対する認識のなさから、不適切な設計で作成されたウェブサイトが運用されていることがあります。本節では、脆弱性関連情報として届出を受けた「アクセス制御」や「認可制御」等の機能欠落に伴う脆弱性についての対策を紹介します。

1.11.1 アクセス制御の欠落

根本的解決

11-(i) アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の秘密情報の入力を必要とする認証機能を設ける。

ウェブサイトで非公開とされるべき情報を取り扱う場合や、利用者本人にのみデータの変更や編集を許可することを想定する場合等には、アクセス制御機能の実装が必要です。

しかし、たとえば、個人情報を閲覧する機能にアクセスするにあたり、メールアドレスのみでログインできてしまうウェブサイトが、脆弱なウェブサイトとして届出を受けた例があります。

一般に、メールアドレスは他人にも知られ得る情報であり、そのような情報の入力だけで個人情報を閲覧できてしまうのは、アクセス制御機能が欠落していると言えます(*1)。

パスワード等(みだりに第三者に知らせてはならないものとして一般に考えられている情報)の入力を必要とするようにウェブアプリケーションを設計し、実装してください。

1.11.2 認可制御の欠落

根本的解決

11-(ii) 認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。

ウェブサイトにアクセス制御機能を実装して、利用者本人にのみデータの閲覧や変更等の操作を許可する際、複数の利用者の存在を想定する場合には、どの利用者にどの操作を許可するかを制御する、認可(Authorization)制御の実装が必要となる場合があります。

アクセス制御機能が装備されたウェブアプリケーションの典型的な実装では、ログインした利用者にセッションIDを発行してセッション管理を行い、アクセスごとにセッションIDからセッション変数等を介して利用者IDを取得できるように構成されています。単純な機能のウェブアプリケーションであれば、その利用者IDをキーとしてデータベースの検索や変更を行うように実装することができ、この場合は、利用者のデータベースエントリしか操作されることはないので、認可制御は結果的に実装されていると言えます。

しかし、ウェブサイトによっては、利用者IDをURLやPOSTのパラメータに埋め込んでいる画面が存在することがあります。そのような外部から与えられる利用者IDをキーにしてデータベースを操作する実装になっていると、ログイン中の利用者ならば他の利用者になりすまして操作できてしまうという脆弱性となります。

これは、認可制御が実装されていないために生じる脆弱性です。データベースを検索するための利用者IDが、ログイン中の利用者IDと一致しているかを常に確認するよう実装するか、または、利用者IDを、外部から与えられるパラメータから取得しないで、セッション変数から取得するようにします。

また、他の例として、たとえば注文番号等をキーとしてデータベースの検索や変更を行う機能を持つウェブアプリケーションの場合、注文番号がURLやPOSTのパラメータで与えられる実装になっていると、ログイン中の利用者であれば、他人用に発行された注文番号をURLやPOSTのパラメータに指定することによって、他の利用者にしか閲覧できないはずの注文情報等を閲覧することができてしまう脆弱性が生じることがあります。

これも、認可制御が実装されていないために生じる脆弱性です。データベースを検索するための注文番号が、ログイン中の利用者に閲覧を許可された番号であるかどうかを常に確認するように実装してください。

脚注

  1. (*1)
    「不正アクセス行為の禁止等に関する法律」では、第二条第二項で「識別符号」を定義しており、その第一号では、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号」と定義しています。この定義に従うと、メールアドレスは識別符号に該当しないと解釈され、メールアドレスだけでログインする仕組みは、アクセス制御機能に該当しないと解される可能性があります。