2021/12/21

脆弱性管理、診断｜知る×学ぶ

Webアプリとは｜脆弱性が生じやすい理由とは

　企業活動に欠かせないものになっているWebサイト。

　Webサイトのほとんどは、単純に静的な情報を表示するものではなく、ユーザー操作に応じて動的に情報の表示や操作を行う、Webアプリケーション（以下、Webアプリ）としての機能を有しています。

　ユーザーにとって、Webアプリは非常に便利である反面、開発の過程で脆弱性が生じやすく、サイバー攻撃の標的になりやすいことも事実です。

　何故、Webアプリは脆弱性が生じやすいのでしょうか

　そこで本記事では、セキュリティ担当者やWebアプリ開発者に向けて、Webアプリに脆弱性が生じる理由を紐解きつつ、脆弱性への対処方法について解説します。

▼ 目次
・Webアプリとは
・Webアプリに脆弱性が生じる理由
・Webアプリを狙うサイバー攻撃
・開発サイクルに追従しつつ、脆弱性に対処する方法

1. Webアプリとは

　ビジネスや生活の中で、私たちは下記のアプリケーションを使っています。

PC上で動くアプリケーション
スマホアプリのようなネイティブアプリ
フォームやショッピングカートなどを実装したWebサイトが提供するWebアプリ

　このうち、今回フォーカスするのはWebアプリですが、これは2000年代に登場した「Web 2.0」というコンセプトによって、飛躍的な進化を遂げました。

　いまではコンテンツを動的に生成して提供するのは当たり前になっており、表面的にはネイティブアプリと区別がつかないものも珍しくありません。

　しかしネイティブアプリとWebアプリの間には、大きな違いがあります。

ネイティブアプリ

クライアント側とサーバー側の独立性が高く、連携する場合にもその窓口が限られている

Webアプリは

クライアント（Webブラウザ）とサーバー（Webサーバー）が一体となって動作する

　ここでおさらいを兼ねて、Webアプリの構成や動作について、簡単に説明しておきましょう。

ユーザーのWebブラウザから、Webアプリを提供するサーバーにHTTPリクエストが送信
HTTPリクエストを受けたWebサーバーは、ユーザへHTMLで構成されたコンテンツを送信
ユーザーのWebブラウザで、コンテンツを画面表示（レンダリング）
コンテンツにJavaScriptなどで作成されたスクリプトが含まれている場合、Webブラウザでスクリプトが実行

　フォームやショッピングカートのようなWebアプリを実装したWebサイトでは、クライアント側のブラウザとサーバー側のWebアプリとの間で通信がやり取りされます。

　Webサーバー側のプログラムは、PHPなどのスクリプト言語で作成されることが一般的です。

　WebサーバーはこれらのプログラムとCGI（Common Gateway Interface）などで連携し、その実行結果をWebブラウザに返します。

　さらにWebサーバー側で動くプログラムの裏側には、データを格納するデータベースが存在します。

2. Webアプリに脆弱性が生じる理由

　何故、Webアプリに脆弱性が生じてしまうのでしょうか？

　主要な理由を3つ取り上げます。

アプリ開発の人的ミス
Webサーバーの脆弱性
Webサーバーの設定

2-1. アプリ開発の人的ミス

　ネイティブアプリの場合には、アプリ開発の専門業者が開発し、徹底的にテストを行った上で販売・配布されることが一般的です。

　これに対してWebアプリの場合には、開発や実装がサイト毎に行われており、それらの担当者の中には十分なセキュリティの知識がないケースも少なくありません。

　スクリプト言語によって手軽に開発・実装できる点はWebアプリの大きなメリットですが、これがセキュリティ面では弱点につながっているのです。

　徹底的にテストされたネイティブアプリでも、脆弱性をゼロにすることは不可能であり、テストが十分でないWebアプリでは、より脆弱性が残りやすくなります。

2-2. Webサーバーの脆弱性

　Webアプリは、Webブラウザ、Webサーバー、データベースが緊密に連携しています。

　これが、Webサーバーが脆弱性を持ちやすい1つの理由になっています。

　クライアントからサーバーへの侵入がネイティブアプリに比べて行いやすい上、サーバーを攻略することでその影響を広めることも容易なのです。

2-3. Webサーバーの設定

　Webアプリの基盤となるWebサーバー製品の設定によっても、脆弱性が生まれてしまう可能性があります。

　しかも、Webサーバー製品自体に脆弱性が存在することもあり、脆弱性が解消されたバージョンを慎重に選択する必要があります。

　当然ながらサイバー攻撃を仕掛ける側も、Webアプリのこのような特性を十分に理解しています。

3. Webアプリを狙うサイバー攻撃

　Webアプリを狙うサイバー攻撃には、どのようなものがあるのでしょうか。代表的なものを簡単に紹介していきましょう。

SQLインジェクション
OSコマンドインジェクション
ディレクトリトラバーサル
セッションIDの不正取得となりすまし
バッファオーバーフロー
バックドアとデバックオプションの悪用
XSS（クロスサイト・スクリプティング）
強制ブラウジング
URLパラメーターの改ざん
HTTPヘッダインジェクション
HTTPレスポンス分割
エラーコードによる情報収集
Hiddenフィールドの不正操作
Cookieの濫用
HTMLコンテンツからの情報収集

3-1. SQLインジェクション

　アプリ設計者が想定していないSQL文を実行させ、データベースを不正操作する攻撃方法です。

　この攻撃のターゲットになるのは、入力フォームに検索キーワードを入力し、それをSQL文に組み込んで検索を行うWebアプリです。

　SQLインジェクションを防ぐには、Webアプリの入力フォームに入力された文字列を、きちんとサニタイズしする必要があります。

　サニタイズとは、SQL文に組み込まれる特殊文字のエスケープ処理や、入力内容をチェックして危険な記述を無効化する処理のことです。

　これによって設計者が意図していないSQL文の実行を防止できます。

3-2. OSコマンドインジェクション

　SQLインジェクションと同様に、設計者が意図していないOSコマンドを実行させる攻撃方法です。

　これもWebアプリの入力フォームなどに、OSコマンドを紛れ込ませることで実行されます。

　入力された文字列を引数にしてOSコマンドを実行する機能をWebアプリに実装した場合や、OS側に脆弱性が残っている場合に、この攻撃を受ける危険性があります。

　被害の実例としては、2016年4月に発生したテレビ局の情報漏えい事件や、同じ時期に発生したラジオ局の情報漏えい事件などがあります。

3-3. ディレクトリトラバーサル

　これはWebサーバーの非公開ファイルにアクセスを行う攻撃方法です。

　トラバーサルとは「横断する」という意味であり、Webサーバーが公開しているディレクトリの親ディレクトリからのパスを指定することで、公開ディレクトリの横にあるディレクトリにアクセスすることから名付けられています。

　代表的な手法としては、GETメソッドなどでファイルを指定する際に「../」を付加し、上位ディレクトリからのパスを指定する方法があります。

　この攻撃が行われると、本来は非公開である情報が不正に閲覧され、情報漏えいする危険性があります。その中にIDやパスワードの情報が含まれていれば、不正ログインされる危険性もあります。

　攻撃防止方法は意外と難しく、複数の手法を組み合わせて対処する必要があります。

　最近では2020年に、あるECサイト構築製品でこの脆弱性が見つかっています。

3-4. セッションIDの不正取得となりすまし

　Webアプリの中にはセッションIDを発行してユーザーを識別するものがあります。

　このセッションIDの発行や管理に不備がある場合、攻撃者にセッションIDが不正に取得され、正規ユーザーになりすまされる危険性があります。

　セッションIDの不正取得方法としては以下のものがあります。

セッションIDの推測

セッションIDの発行パターンが明確な場合（例えばシーケンシャルな数字など）、攻撃者はまずそのサイトにアクセス
セッションIDを取得し、そこから正規ユーザーの有効なセッションIDを推測

ネットワーク盗聴によるセッションIDの取得

フリーWi-Fiのアクセスポイントを公開
そこを経由したセッションのIDを盗聴する

　このように不正に取得したセッションIDを悪用した攻撃は、セッションハイジャックと呼ばれています。

　この攻撃の防止方法も複数存在し、これらを組み合わせて利用する必要があります。

3-5. バッファオーバーフロー

　プログラムが確保したメモリ領域を超える量のデータを送り込み、領域外のメモリを上書きすることで、設計者が意図しないコードを実行させる攻撃です。

　CやC++、アセンブラなど、メモリを直接操作できる言語を使用したプログラムで発生する可能性があります。

　WebアプリのほとんどはPHPやPerlといったスクリプト言語を使用しており、これらは直接メモリ操作ができないため、バッファオーバーフローの危険性は低いと言えます。

　しかしこれらのライブラリの中にはバッファオーバーフローの脆弱性が報告されていたものもあるため、脆弱性が修正されたものを使用する必要があります。

3-6. バックドアとデバックオプションの悪用

　Webアプリを開発する際に、開発者がバグ発見や修正のため、開発途中のコードにバックドアやデバックオプションを組み込むケースは珍しくありません。

　例えばHTTPリクエストの中に「debug=on」と記述することで、一般ユーザーであれば実行できない処理がテスト的に実行される、といったコードが組み込まれることがあるのです。

　これは特権的な操作が可能な「裏口」であり、残ったままの状態で公開されると、攻撃者に狙われる危険性があります。

3-7. XSS（クロスサイト・スクリプティング）

　Webアプリの中には、ユーザーによる入力内容を保存し、その内容に応じたWebページを生成するものがあります。

　例えばSNSやブログのように、ユーザーからの投稿が可能なWebアプリは、ユーザーからの投稿をデータベースに保存し、その内容を表示できるようになっています。

　このようなWebアプリの投稿フォームにスクリプト付きの文字列を入力し、そのスクリプトを不正実行させるのがXSSです。

　このスクリプトによって不正サイトへ誘導する、といったことが可能になります。

　対策としてはSQLインジェクションなどのように、サニタイズ（スクリプトの無効化）が有効です。

　しかしXSSの被害報告は現在でも多く、IPAが2021年10月に発表した「ソフトウェア等の脆弱性関連情報に関する届出状況[2021年第3四半期（7月～9月）]」でも、数多くのXSSに関する脆弱性が報告されています。

3-8. 強制ブラウジング

　攻撃者がWebサイトにアクセスする際に、公開されたページからリンクを辿っていくのではなく、アドレスバーに直接URLを入力することで、公開するつもりがなかったページに直接アクセスする攻撃手法です。

　ディレクトリトラバーサルと同様に、意図しない情報漏えいが発生する危険性があります。

3-9. URLパラメーターの改ざん

　HTTPリクエストのGETメソッドでは、URLの末尾に「?」を付加し、その後にパラメーターを記述できます。

　Webアプリが他のページに遷移する際にGETメソッドを使用した場合には、その内容がアドレスバーに表示されます。

　ここに表示されたパラメーターをアドレスバーの中で直接改ざんし、不正なアクセスを行うのが、URLパラメーターの改ざんです。

　例えばユーザー情報を表示するページに遷移するGETリクエストの中に「?user=（ユーザー名）」というパラメーターがあり、このパラメーターがSQL文に組み込まれて実行される場合には、このパラメーターを「?user=*」とすることで、全ユーザーの情報が表示されることになります。

　対処方法としてはSQLインジェクションと同様に、パラメーターのサニタイズが有効です。しかしそれ以前に、パラメーターがアドレスバーに表示されるGETメソッドではなく、POSTメソッドを使うべきだと言えるでしょう。

3-10. HTTPヘッダ・インジェクション / HTTPレスポンス分割

　Webアプリの中には、WebブラウザからのHTTPリクエストの内容に応じて、Webブラウザに返すHTTPレスポンスヘッダの値を動的に生成するものがあります。

　このようなWebアプリでHTTPリクエストの内容をきちんとチェックしていない場合、HTTPレスポンスヘッダが改ざんされ、設計者が意図していないCookieの発行や偽ページの表示、悪意のあるスクリプトの実行が行われる危険性があります。

　このような脆弱性を利用した攻撃がHTTPヘッダインジェクションであり、XSSと同様の危険性があります。

　またHTTPヘッダ・インジェクションによってHTTPレスポンスを複数のレスポンスに分割し、分割したレスポンスの中に偽ページに誘導する内容を格納してキャッシュさせ、継続的にユーザーを偽ページに誘導する方法もあります。

　これはHTTPレスポンス分割やキャッシュ汚染と言われています。

3-11. エラーコードによる情報収集

　Webアプリに不備があった場合、Webブラウザにエラーコードやエラーメッセージが返されることがあります。

　その一例が、GETリクエストのパラメーター値やフォームへの入力値が正しくなかった場合に「Internal Server Error」が表示されるケースです。

　このような情報は一般ユーザーには単なるエラーに過ぎませんが、攻撃者にとっては攻撃の糸口を発見するための重要な情報です。

　わずか2～3のエラーメッセージによって、攻撃のための十分な情報が得られるという指摘もあります。

　この問題を回避するには、Webアプリのテスト段階で不正な入力値を徹底的にチェックし、エラーメッセージが表示されないようにしておく必要があります。

3-12. Hiddenフィールドの不正操作

　Webアプリの画面に表示されないHTMLフォーム項目を、Hiddenフィールドと言います。

　これはWebページを遷移する際に、前のページから次のページへデータを引き渡す際によく使われていた手法ですが、その利用には危険が伴います。

　Hiddenフォームは画面には表示されていないものの、HTTPレスポンスのソースにはその内容が明確に記述されているからです。

　この部分を改ざんすることで、設計者が意図しない動作を行わせることが可能になります。

　Hiddenフィールドのユースケースとして多いのが、継続的なユーザー識別です。

　HTTPは基本的に「状態を維持しない」「ステートレスなもの」であり、リクエストは毎回独立しています。

　そのためそのままでは、アクセスしているユーザーの同一性を判断できないのです。

　しかしセッション機能を利用すれば、この問題を解決でき、ステートフルなWebアプリを実現できます。

　現在もHiddenフィールドを使っているのであれば、すぐにでもセッションIDに置き換えるべきです。

3-13. Cookieの濫用

　Cookieの内容を改ざんする攻撃です。Cookie内にセッションIDを格納している場合には、なりすまし攻撃が行われる危険性もあります。

3-14. HTMLコンテンツからの情報収集

　開発時にはHTMLやJavaScriptのコードにコメントを記述し、他の開発者への情報共有や、後々のメンテナンスで利用することが一般的です。

　しかしこれが残ったまま公開されると、それを手がかりに攻撃が行われる危険性があります。

　公開する際にはコメントを削除しておくべきです。

4. 開発サイクルに追従しつつ脆弱性に対処する方法

　Webアプリへの攻撃は、様々なものが存在することがわかります。

　これら全ての脆弱性を事前に潰しておくことは、決して簡単ではありません。

　さらにWebアプリは、開発のPDCAサイクルを繰り返して機能追加や改修を行い、ユーザーた体験を高める傾向がありますが、その反面で新たな脆弱性が生まれることも多いのです。

　そこで重要になるのが、開発のPDCAサイクルに追従し、定期的にWebアプリの脆弱性を診断し、ユーザーやビジネスにとっての脅威に対して、迅速に対処することです。

　ここで具体的に何をすべきかについては、IPA（情報処理推進機構）が公開している「企業ウェブサイトのための脆弱性対応ガイド」が参考になります。

実施しているセキュリティ対策を把握する
脆弱性への対処をより詳しく検討する
ウェブサイトの構築時にセキュリティに配慮する
セキュリティ対策を外部に任せる
セキュリティの担当者と作業を決めておく
脆弱性の報告やトラブルには適切に対処する
難しければ専門家に支援を頼む

　引用. 情報処理推進機構「企業ウェブサイトのための脆弱性対応ガイド」
　（https://www.ipa.go.jp/security/fy2020/reports/vuln_handling/index.html）

　多くの企業にとって、Webアプリの脆弱性に精通した人材を採用・育成することは簡単ではありません。

　従って上記にも記載されているとおり、Webアプリの脆弱性に精通した外部の専門家の支援が不可欠です。

　この課題を解決するために有効なのが、Webアプリの脆弱性に精通した専門家が提供するWebアプリの脆弱性診断サービスです。

　Webアプリの脆弱性診断サービスとは、Webアプリにセキュリティ的な問題が潜んでいるのかについて第三者の視点から診断するサービスで、様々な事業者から提供されています。

　脆弱性診断によって、企業はWebアプリ上のセキュリティの「死角」を発見し、適切な対処が可能です。

　しかし、Webアプリの脆弱性診断を利用する上では、いくつか注意が必要です。

　注意点については、以下よりご欄いただけます。