1 はじめに

企業ホームページやECサイト、SNSなど日々様々なWebサイトがリリースされていますが、サイバー攻撃を受けてしまうケースが後を絶ちません。原因の多くは、システム開発時に意図せず作りこんでしまった脆弱性によるものです。
そこでおススメなのが、サイトリリース前に脆弱性の有無を第三者がチェックする脆弱性診断です。
しかし「脆弱性診断ってよく聞くけれど、具体的にどのような脆弱性が見つかるの？」「どうやって対策するの？」という疑問を持たれている方も多いのではないでしょうか。

本ブログでは、エムオーテックスで数々のサイトに対し脆弱性診断を実施している筆者が、脆弱性診断でよく検出される脆弱性TOP5を分かりやすく解説します。
開発中のシステムにおいて、脆弱性を生まないための事前対策となれば幸いです。

２　Webアプリケーション脆弱性診断でよく発見される指摘ポイントTOP5

まずはそれぞれの指摘ポイントの概要を説明します。

1位：アクセス制御の不備

本来であれば権限を付与されたユーザーでのみアクセス可能な機能や情報に対して、権限を持たないユーザーがアクセス可能となってしまっている事象です。
アクセス制御の不備は、権限外の操作による情報漏洩やサービス妨害のリスクがあります。

アクセス制御の方法は多岐に渡り、Webサイト毎の独自な作りである場合が多く見受けられます。当該指摘ポイントの診断をするためには、決まりきったパターンではなく人間的な思考が必要になる要素が多く、ツールでの診断では簡単には検出できず、昨今はやりのAIでの検出も難しいとされる診断項目となります。

２位：クロスサイトスクリプティング（XSS）

Webサイトの作りとして、サーバーはユーザーが入力した文字や設定値からブラウザに表示するHTMLソースを出力し、ブラウザに返しています。

そこに本脆弱性があると「<>」（タグ文字）などのHTML特殊文字が正しく無害化処理されず、攻撃者が用意したスクリプトが不正に実行されてしまう可能性があります。その結果、フィッシングサイトなどの別のWebサイトへの誘導や認証情報の窃取等の情報漏洩につながるリスクがあります。
なお、クロスサイトスクリプティングは、診断時に送信した文字列に対するレスポンスの内容で判定ができるケースが多く、ツールなどでの診断でも検出しやすい診断項目でもあります。

3位：クロスサイトリクエストフォージェリ（CSRF）

クロスサイトリクエストフォージェリは登録処理や削除処理の際に、ユーザーのリクエストを偽装し、意図しないリクエストを実行させられてしまう脆弱性です。

何も対策されていない場合、攻撃者が用意したページにアクセスさせるだけで、対象サイトの情報を変更させられてしまう可能性があります。例えばそれがパスワード変更やメールアドレス変更だとしたら、攻撃者が不正にログインするための情報に変更させられてしまうかもしれません。また、退会処理であればアカウントがなくなってしまいますし、それが管理者アカウントであった場合は目も当てられません。

4位：意図しないリダイレクト　^※

サイトの構成上、転送先のURLをパラメータとして保持していることがあります。攻撃者が罠サイトのURLを含んだ攻撃用のURLを作成し、被害者にアクセスさせます。
URL自体は正規のサイトのドメインであるため気付きにくく、アクセスしてしまいます。
何らかの処理の後、攻撃者の罠サイトに誘導されフィッシング詐欺等の被害に発展する可能性があります。
※オープンリダイレクトともいいます

5位：SQLインジェクション

現在、ほとんどのWebサイトのコンテンツは動的コンテンツとなっており、Webサイトの内部的にはSQLの実行が必要となるケースが多くなっています。
SQLインジェクションは被害事例も多く、被害を受けた際に、例えば数万件などの情報が漏洩するなど、インパクトも大きい事例が多くなっています。
意識して対策されているケースも多いかと思いますが、スクラッチで開発した場合など、当該脆弱性を作りこんでしまう可能性も十分あり得ます。

以上が、脆弱性診断で発見される指摘ポイントTOP5です。
今回は、このTOP5の中から、「アクセス制御の不備」と「意図しないリダイレクト」をピックアップしてご説明します。

３　各指摘ポイントの詳細

■アクセス制御の不備
簡潔に説明すると、認可された権限を超えることや認証をバイパスして情報の閲覧や処理が実行できてしまう脆弱性です。認証や認可という言葉を耳にすることがあるかと思いますが、セキュリティの一般的なアクセス制御の言葉として使う場合、以下のように意味が異なります。

アクセス制御とは、これらの違いを正しく認識し、利用者に対して与えられた権限から外れた行動をしないように制御することです。
ここでは、アクセス制御における「認可」に関して、横の認可制御や縦の認可制御などについてご説明します。

・横の認可制御

被害者と攻撃者のアカウントが同レベルの操作権限を持ち、それぞれのデータは自身に紐づくものしかアクセスできない場合、横の認可制御が存在していると言えます。
この際に、横の認可制御を突破して、攻撃者が被害者のデータにアクセスを試みます。

例えば、サイトを操作する権限は同じだが、主に閲覧可能なデータが異なる場合が該当します。
※自身のユーザーデータ変更なども含みます
具体的な例として、ユーザーが自身で行うパスワード変更処理を挙げてみます。

この図では、攻撃者であるユーザーBが、ユーザーAの情報を取得しようとしています。
横の認可制御に問題がある場合、このような攻撃を受ける可能性があります。

上記のHTTPリクエストの例では攻撃者であるユーザーBがパスワード変更の処理を実施していますが、その際にユーザーAの「user=123」というクエリパラメータが送信されています。このパラメータの値がユーザーAに紐づいており、ユーザーAのパスワード変更を実施する処理である場合、攻撃者であるユーザーBは、ユーザーAのパスワードが変更できてしまうかもしれません。
（例なのであえて分かり易くしています。実際にはこのようなずさんなつくりはないと思っています）

さらに、この例では「user=123」のように、数字の連番が使われているので、攻撃者にとっては容易に推測が可能です。また、推測できない値だったとしても、その値が漏洩してしまう可能性があります。参考までに、この例では、、ユーザーの認証時点からセッション管理を行い、その後の処理ではパラメータにユーザーを識別するような値を持たない、という対策が考えられます。

・縦の認可制御

管理者と一般ユーザーのように操作可能な範囲が異なるものが、縦の認可制御です。

この図では、管理者であるadminと一般ユーザーであるuserのアカウントで見えている画面が違います。図では色を変えて表現していますが、adminが見ているのは管理者用の画面、userが見ているのは一般ユーザーの画面だと思ってください。管理者と一般ユーザーで、表示される画面が違うという事はよくあると思います。

このように、表示上はそれぞれの正しい画面が表示されているため、一般ユーザーでは管理者の機能が使用できないように見えますが、果たして本当にそうでしょうか？

一般ユーザーで、試しに管理者のURLにアクセスしてみると、管理者用の画面が表示されてしまうことがあります。

これは、サーバー側で権限チェックを実施していないケースや、ユーザーからのURLの入力を受け入れているケースがあり、本来実行できない機能を権限がないユーザーが実行できてしまうために発生しています。

以下に実際の悪用例を挙げてみます。

攻撃をするためには、攻撃者はURLやパラメータを推測する必要がありますが、内部犯や類似システムの場合それを推測するのは容易になります。

上記にて、アクセス制御の不備のうち、主に認可について、横の認可権限、縦の認可権限をそれぞれ簡単な例を用いて説明しましたが、アクセス制御の不備には他にも下記のような様々なケースがあります。

このように、アクセス制御の不備は、サイトの構成やアクセス制御の仕様を把握する必要があるなど、脆弱性診断を実施するベンダーの知見・経験によって精度が大きく変わります。

４　「意図しないリダイレクト」の詳細

いわゆるオープンリダイレクトやURL誘導といわれるものになります。
オープンリダイレクトとは、Webアプリケーションの脆弱性の一種で、攻撃者が特定のWebサイトに偽装したリンクを作成し、そのリンクをクリックすることで、別の危険なWebサイトに誘導するものです。

例えば、普段利用しているショッピングサイトのリンクが、攻撃者によって改ざんされている場合、クリックすると別の危険なサイトに誘導され、個人情報が盗まれたり、マルウェアに感染する可能性があります。
弊社の診断では、このようにURLを保持している個所に対して、任意のURLへの転送ができないかといった観点で検査をしています。

上記の図では、URLを外部から指定できてしまう状態となっていました。ではどうするべきか？

例えば、指定されるURLが固定であれば、そもそもパラメータにURLを持つ必要はありません。
以下のようなURLをサーバーにリクエストし、サーバーは「urlparam」というクエリパラメータに紐づく値をDB等から参照し、それを転送先のURLとして返すような対策が考えられます。

※サーバーでは「1」に紐づくURLが「https://tenso.motex.co.jp/」と把握しているため。

しかしながら、Webサイトの構成上どうしても外部からURL指定したいケースというのは出てきます。その場合には、しっかりと対策を施さなければなりません。
対策の例としては、URLをチェックする方法がありますが、対策に不備がある場合、例えばドメインのみをチェックしているケースがあります。

「https://motex.co.jp/」というURLがあった場合、「motex.co.jp」ドメインが文字列として含まれているかをチェックするとします。
この場合、以下のケースでもチェックを通り抜けてしまいます。

①「https://motexevil.co.jp/aaaa/motex.co.jp/」

URL内に存在すればいい（ディレクトリ名にでもつければOK）ので、攻撃者の指定したevilドメインへ転送が許可されてしまいます。

②「https://evilmotex.co.jp/」

また、正規表現等で一致チェックを実施していない場合、②のようなドメイン名でも許可されてしまう可能性があります。

では、「https://motex.co.jp」のような形でURLの一致をチェックすればよいかというと・・・

③「https://motex.co.jp.evil.co.jp/」

ドメインのパス部分までのチェックがなければ、このように後方に攻撃者のドメインを追加する攻撃が成立する可能性があります。
DNSの仕組み上、トップレベルドメイン（ここで言うjp）からたどるため、攻撃者の指定したevil.co.jpのドメインが先行して名前解決されます。
このように対策が完全ではない場合、攻撃に悪用されてしまう可能性があります。そうならないためにも、ホワイトリスト方式で転送先のドメイン一致チェックを正しく行うことを推奨します。

5　おわりに

　本コラムでは、弊社で実施しているWebサイトの脆弱性診断の結果から、指摘ポイントTOP５について解説しました。開発者がサイト開発時にセキュリティ対策を意識したつもりでも、意図せず脆弱性が生まれてしまうという事があります。

特にアクセス制御の不備についてはサイトの構成や権限の種類によって確認すべき内容が変わってきます。そのため、いくら開発工程で万全なテストをしても攻撃者の視点が不足している場合は脆弱性が残った状態でリリースされてしまうことになります。病気は専門の医療機関が実施するようにセキュリティに関しては専門家に任せた方が安全となります。
本ブログが、皆様のセキュリティ対策の一助となりましたら幸いです。