コラム
2022/08/30
（コラム）攻撃されやすいWebアプリケーションの特徴と費用対効果の高いチェック方法
皆さま、日々どのようなWebアプリケーションを使用されていますか？
Amazonに代表されるようなECサイトから組織で使用している業務管理システム、経費精算システム、勤怠管理システムなど、現在提供されているほとんどのシステムがWebアプリケーションです。多くの一般の方にとって、Webアプリケーションといえばブラウザに表示される「Web画面」を想像すると思います。実際にはWeb画面単体で動くものばかりではなく、別にインストールされたソフトウェアが裏側でインターネット上（もしくは社内ネットワーク）にある別のシステムと通信してデータの交換や処理が行われます。この通信にWeb APIが使われています。
しなしながら、このWeb APIを含むWebアプリケーションの脆弱性を悪用した不正アクセスやデータ窃取などの攻撃による企業被害は後を絶ちません。
本コラムでは、実際の事例などを交えながら、どのようなWebアプリケーションが攻撃を受けやすいのか、その攻撃内容、また費用対効果を考えてチェックする方法などを解説します。
狙われやすいサイト
攻撃者は目的を達成するためにあらゆる方法を用いて攻撃を行いますが、一般的に以下のようなサイトが特に攻撃されやすい傾向にあります。
1. 重要情報を取り扱っているサイト
2. 報告されたばかり（流行り）の脆弱性が存在しているサイト
3. 古いソフトウェア／バージョンで構築されたサイト
「1. 重要情報を取り扱っているサイト」は、まさに攻撃者が明確な目的をもって攻撃をする対象です。通常はログイン後の画面に重要情報が存在するので、攻撃者としてはいかにログイン後の画面にアクセスするかが必要となります。例えば、特定ユーザ（取引会社など）のみアクセスを許可する業務アプリの場合はログインできるユーザも限定されているため、攻撃者はログインを突破するところから始めないといけません。[1]
一方、誰でもアカウント登録が可能なサイトは同時に攻撃者もアカウント登録することができるため、攻撃される可能性が高いサイトと言えます。ログイン後の画面には豊富な機能が存在しており複雑になる傾向があります。そのため、必然的に脆弱性が存在するポイントも増えてきます。
また、セキュリティインシデントで時々見かけるのが、企業のコーポレートサイトの中にある特定ユーザ向けのログイン画面です。ログイン後には、社内情報、OB向けの情報、取引先向けの情報や見積もり機能などを掲載していることがあります。このようなログインには、推測容易なID／パスワードのみを使用している、もしくは共通のパスワードを使用していることが時々見受けられ、パスワード攻撃を受けて不正ログインされ、社内情報を窃取される、もしくはログイン後にさらなる攻撃を受けて侵害されているケースがあります。ログイン画面については、アカウントロック機能（5回間違えたらアカウントをロックするなど）を実装することで攻撃される可能性を低くできるのですが、利便性を優先し過ぎたため実装されず、攻撃を許してしまったケースも何件か見られました。
次に「2. 報告されたばかり（流行り）の脆弱性が存在しているサイト」です。皆さまは以下のような脆弱性の名称は聞いたことがありますか？
- ● ProxyShell（CVE-2021-34473, CVE-2021-34523, CVE-2021-31207）
- ● Log4Shell（CVE-2021-44228）
- ● Spring4Shell/SpringShell（CVE-2022-22965）
2021年～2022年前半にかけて報告された脆弱性になります。最初の「ProxyShell」はExchangeサーバの脆弱性となるため、本コラムの趣旨とは若干異なります。しかしExchangeサーバにて公開されているWebサービス及びHttpProxyを介して攻撃をされ、WebShellやランサムウェアが作成／実行されたケースが多々ありました。Webサービスという同じ位置付けのものであるため、ここに記載しています。
「Log4Shell」と「Spring4Shell」はいずれもFrameworkに関連する脆弱性になり、リクエスト時に攻撃コードを挿入することで容易にリモートコードの実行ができてしまう脆弱性です。もちろんセキュリティパッチは公開されていますが、すぐにセキュリティパッチを適用できないサイトなどを中心に、侵害されたケースが目立ちました。
こういった脆弱性が報告されると、攻撃者はすぐにインターネット上に存在するWebアプリケーションに対してスキャンをかけ、脆弱性が放置されていないか確認します。運悪くスキャンに引っ掛かってしまうと、前述のようにWebShellを設置されてから、横展開され、最悪の場合、社内ネットワーク深く侵入されるなど被害が拡大します。危険度が高い脆弱性が報告された場合は、迅速にセキュリティパッチを適用することが大事と痛感される事例でした。
最後に、「3. 古いソフトウェア／バージョンで構築されたサイト」です。前述の「2.」と類似した方法で、攻撃者は、古いバージョンのソフトウェアを使用しているサイトを見つけた場合、そのサイトのセキュリティ管理には不備があり、何らかの脆弱性が存在していると考えます。筆者自身も脆弱性診断の実施（見積もり）前に、事前調査をして対象サイトを確認することがありますが、事前調査の中で使用しているソフトウェアが古い場合やWebサイトのデザインが古い場合は、よく嫌な予感がします。大抵その予感が当たり、緊急度の高い脆弱性を発見することがあります。実際に2021年当時でCGIを使用して問い合わせ画面などを作成していたサイトでは、OSコマンドインジェクションが見つかったケースもありました。
攻撃者は獲物を探すかのようにとりあえずインターネット上に公開しているWebサイトに一斉にスキャンをかけることもあります。ピンポイントで上記だけが狙われるということではなく、インターネット上に公開しているWebサイトすべてが、攻撃を受ける可能性があると認識する必要があります。ただし、攻撃者側も効率的に攻撃を実施するため、攻撃に使えない（の影響を受けない？）静的サイトなどを除外しつつ、より攻撃の成功確率が高い上記のようなサイトに絞って攻撃する可能性もあります。
どういった攻撃をされるのか？
ここでは攻撃者はどのような脆弱性を利用して攻撃を行うかを、筆者がセキュリティ診断業務やインシデント対応などを通して見てきたケースを例に2つご紹介いたします。なお、その他のWebアプリケーションの脆弱性については、OWASPという非営利団体が定期的にWebアプリケーションのセキュリティに関する重大なリスクについての順位をつけて解説していますので、そちらも合わせてご参考ください。
OWASP Top 10 – 2021
まず、Webアプリケーションの脆弱性として思いつくのは、「SQLインジェクション」や「クロスサイトスクリプティング（以下、XSS）」といった脆弱性です。脆弱性の詳細は他サイトでも解説されているため、本コラムでは割愛させていただきますが、入力値のチェック不備や出力時のエスケープ処理の不備などが主な原因です。前述のOWASP TOP10でもインジェクション系の脆弱性として3位に位置付けられており、94%のWebアプリケーションで何らかの問題が確認されていると報告があります。SQLインジェクションの脆弱性は一昔前と比較すると少なくなってきていますが、XSSはセキュリティ診断を実施していると高い確率で検出される脆弱性です。
例えば、以下のような入力画面があった場合に、Webアプリケーションに送信するリクエストとしては次のようなものが考えられます。
＜画面例＞
＜リクエスト例＞
name=オリエントタロウ&address=東京都港区&tel=09012345678&sex=1&test@example.com&submit=add
※実際は、日本語や記号はURLエンコードされて送信されます
例えば、電話番号の値にシングルクオーテーション「’」、ダブルクォーテーション「”」、記号「<」「>」などを入力し、正常遷移と違うレスポンスがある、記号がそのまま次の画面に出力されている場合は脆弱性が存在する可能性が高く、攻撃者はより深掘りして脆弱性を探します。
＜例＞
tel=09012345678’
tel=09012345678”
tel=09012345678<>
運よくこの画面では攻撃が成功しなかったとしても、攻撃者側としては「ここで適切な処理をしていないのであれば、他の画面でも脆弱性が存在するかも？」と考えて執拗に脆弱性を探すことが考えられます。また、性別の項目はラジオボタンとなっているため入力できないと思われがちですが、上記のように値自体は送信されているため、攻撃者はここにも不正な値を入力してWebアプリケーションの挙動を確認しています。
＜例＞
sex=1’
sex=1”
sex=1<>
なお、これらのインジェクション系の脆弱性はツールで検出することができるため、攻撃者もツールを使用してスキャンを実施し、脆弱性のあたりをつけています。逆に考えると、守る側としてもツールを使用したチェックをすることで事前に脆弱性を把握し、修正することが可能です[2]。しかし、次に説明する脆弱性はツールでは見つけることが難しい脆弱性であり、かつ影響も高いものになります。
ツールでは見つけることが難しい脆弱性として、「アクセス制御の不備」があります。簡単に言ってしまうと、本来閲覧できない画面を閲覧できる、不正に管理者権限でアクセスできてしまうといった、権限を飛び越えて操作ができてしまう脆弱性になります。この脆弱性はOWASP TOP10の順位で1位として報告されています。
これにも様々な種類がありますが、リクエストパラメータに「role=user」というものがあれば、「user」という値を「admin」という値に変更することで管理者権限になった例があります。ここまで顕著ではなくても、「sid=50006」というものが送信されている場合、「50006」という値を「10001」という値に変更してリクエストしてみたら管理者権限で操作することができた例もあります。
＜例＞
role=user
role=admin ※adminに変更
＜例＞
sid=50006
sid=10001 ※10001に変更
上記は縦方向の権限チェック（ユーザ権限と管理者権限）の不備です。しかし、これが適切にチェックされていたとしても、横方向の権限チェック（ユーザ権限とユーザ権限）をしていなかったため、他ユーザの情報を操作されてしまったなどの脆弱性が時々見つかります。
＜例＞
uid=50006
uid=50007 ※他ユーザのID、50007に変更
uid=50008 ※他ユーザのID、50008に変更
uid=50009 ※他ユーザのID、50009に変更
特にユーザIDが連番で割り当てられていると、上記のように他ユーザのIDも推測し易くなり、アクセス制限に不備があると攻撃が成功する可能性がさらに高まります。上記はわかりやすい権限の例になりますが、その他にもアップロードした他人のファイルに付与されているIDが推測可能だったため、不正に閲覧できてしまったなどもあります。
＜例＞
file=202207310001
file=202207310002 ※ファイルのIDを202207310002に変更
その他、簡単な例としては、管理者のみが閲覧可能なページのリクエストをそのまま送信したら、ユーザ権限でも閲覧できてしまったなどがあり、影響が大きい脆弱性です。
これらのアクセス制御の不備は、パラメータの値だけで権限をチェックするなどしており、セッション管理を適切に実施していないために発生するものになります。セッションIDなど、ユーザが変更できない仕組みを使用して実装することが必要になります。
費用対効果を考えた脆弱性のチェック
上記のような攻撃を受けないように、Webアプリケーション脆弱性診断などを使用し、脆弱性が確認できた場合は早急に修正する必要があります。
各組織が持っているWebアプリケーションすべてに対して脆弱性診断を実施するのが理想的ではありますが、現実的には予算も決まっており、すべてに対して脆弱性診断を実施することは現実的ではない場合もあります。そのため優先順位をつけて、攻撃を受けやすいサイト、重要情報をもっているサイトなどから脆弱性診断を実施する必要が出てきます。
一般的に、以下のようなサイトは優先度を高くして脆弱性診断を実施する必要があります。
- ● インターネット上に公開されているサイト
- ● 重要情報を取り扱っているサイト
- ● 誰でもアカウントを作成しログインできるサイト
逆に社内ネットワーク内でしかアクセスできないサイト、インターネット上に公開はしているがアクセス制限をしている、特定のユーザのみログインできるなどのサイトは、優先度を落とす、ログイン画面のみ脆弱性診断を実施するなどして、1つでも多く重要なサイトの画面を診断する方が効果的と考えられます。
もちろん、各組織によって何を重要とみているか、どのような脅威を想定しているのかは違います。あくまでも一般的な話とはなりますが、方針が決まっていない場合は、このような考えで実施するのが良いと思われます。
おわりに
今回はWebアプリケーションを狙った攻撃という観点で説明いたしましたが、実際にはメールでマルウェアを送信させて感染させる、脆弱性が存在するVPN経由で侵入する、リモートログインサービス（RDP等）を使用してログインする等、様々な手法を使って攻撃してきます。また、最近ではクラウドサービスが普及していることもあり、シークレットキーが漏えいし、クラウドサービス側に侵入されるケースなども増えてきました。
今回ご紹介した内容はごく一部ですが、少しでもセキュリティ向上の一助になれば幸いです。
[1]例えば、攻撃者は強度の低いパスワードを狙ってパスワード辞書攻撃などを行います。もちろん、許可されたユーザに悪意を持ったユーザがいれば攻撃される可能性が高くなります。ログイン後の画面はセキュリティを考慮されずに構築されていることもあり、その場合は容易に攻撃を受けてしまうことがあります。
[2]インジェクション系の脆弱性でも、ツールだけでは検出が難しいものもあります。