理解していますか？ Webアプリケーションの脆弱性とそのリスク

2024年5月、ある事業者が、同社が運用する住宅購入者向けの会員制Webサイトについて「SQLインジェクション攻撃」を受け、メールアドレス、ログインID、パスワードなどの顧客情報が流出したと公表しました。フォトギャラリーのページが攻撃されたとのことです。報道によると、当該ページは2011年に運用を終了しており、動線がないことや検索エンジンに引っかからないため、URLを直接入力しないと接続できない状態であったためメンテナンスを行っていなかったとのことです。どうしてフォトギャラリーのページへの攻撃で、そのページとは無関係に思われるメールアドレス、ログインID、パスワードなどの顧客情報が流出したのでしょう。



目次

Webアプリケーションの脆弱性とは

Webサイトは以下のような構造になっています。
１．ハードウェア
物理的なサーバやネットワーク機器
２．OS（オペレーティングシステム）
ハードウェアの上で動作し、システム全体の管理を行います。WindowsやLinuxなどですが、WebサイトではLinuxがメジャーです。
３．ミドルウェア
OSの上で動作し、Webサーバ（リクエストを受け取ってレスポンスを返す）やデータベースの機能を提供します。代表的なミドルウェアとしてApache HTTP ServerやMySQLなどがあります。企業ホームページにおける「沿革」のような固定された内容のみのWebサイトであればミドルウェアまでで構築可能です。
４．Webアプリケーション
ミドルウェアの上で動作し、検索ページやログインを必要とするページ等のユーザ操作や条件に応じて内容が変わる機能を提供します。Webアプリケーションはサービス内容に直結するため、自社・自組織で開発することが多いです。

脆弱性というとOSやミドルウェアの脆弱性が思い浮かびます。これらは購入した製品のセキュリティ上の欠陥ですので、開発元から公表があったり対応版が提供されたりします。一方、Webアプリケーションもセキュリティ上の欠陥、つまり脆弱性が存在することがあります。Webアプリケーションは自社・自組織で開発したものですので、自社・自組織が能動的に対策を行う必要があります。
では、Webアプリケーションの脆弱性があった場合、どのような危険があるのでしょう。Webアプリケーションの脆弱性にはいくつかのタイプがありタイプ毎に影響は異なります。詳しくは情報処理推進機構（IPA）の『安全なウェブサイトの作り方』を見ていただきたいのですが、ここでは特に留意すべき脆弱性について説明します。

SQLインジェクション

Webアプリケーションの多くは、利用者からの入力情報を基にデータベースへの命令文 （SQL：Structured Query Language）を組み立てデータベースと連携（参照・更新・削除）しています。このSQL文の組み立て方に問題がある場合、外部からの不正なリクエストによってデータベースの不正利用をまねく可能性があります。このような問題を「SQLインジェクションの脆弱性」と呼び、この問題を悪用した攻撃を、「SQLインジェクション攻撃」と呼びます。SQLインジェクション攻撃によって以下のような被害が発生する可能性があります。

・データベースに保存されている全てのデータの漏えい（注：「全て」です）
・データベースに保存されているデータの改ざんや消去
・認証回避による不正ログイン
・OSコマンドの実行

特に、認識しておく必要があるのは、SQLインジェクション攻撃によってデータベース内の全てのデータにアクセスされてしまう可能性があることです。商品を検索し表示するページにSQLインジェクションの脆弱性があった場合、商品データだけでなく同じデータベース内の他のデータもアクセスされてしまう可能性があるのです。

OSコマンド・インジェクション

OSコマンド・インジェクションは、細工したリクエストによってサーバOSのコマンドが実行されてしまうものです。例えば、ユーザからファイルを受け取り、そのファイルをサーバ上の特定のディレクトリに保存する場合を考えます。この特定のディレクトリに保存する処理はOSのコマンドを実行しますが、仮にアップロードされたファイルのファイル名をそのままコマンドに渡していた場合、攻撃者が悪意のあるファイル名を入力することで、任意のOSコマンドが実行されてしまうのです。
OSコマンド・インジェクション攻撃によって以下のような被害が発生する可能性があります。

・不正なシステム操作
・不正なプログラムのダウンロードや実行
・サーバ上のデータの漏えい
・他のシステムへの攻撃の踏み台

ディレクトリ・トラバーサル

ディレクトリ・トラバーサルとは、細工したリクエストによってサーバの上の任意のファイルにアクセスされてしまうことです。例えば、表示するファイルをユーザからの入力を受け取り、その入力を元にサーバ上のファイルを表示する場合を考えます。例えば「https://example.com/cgi-bin/file.cgi?file=report2023.pdf」という処理があった場合、この「?file=report2023.pdf」を細工することでサーバ上の任意のディレクトリの任意のファイルにアクセスされる可能性があります。
ディレクトリ・トラバーサル攻撃によってサーバ上のデータが窃取されたり、改ざん・削除されたりする可能性があります。

セッション管理の不備

HTTP/HTTPSなどのTCPのプロトコルは、ユーザのリクエストとサーバからの応答の一往復で完結し、前後のやり取りとの関係性はサポートされていません。つまり、TCPのプロトコルそのままではログインした後のリクエストを受け取っても、サーバはログインしたユーザかどうかわからないのです。そのため、ユーザのログインがOKの場合、サーバはセッションIDという一意の識別子を発行しユーザに返します。次回以降のリクエストはこのセッションIDを含めることで、サーバはユーザを特定することができます。なお、セッションIDのやり取りは見えないため意識することは難しいですが、一定時間無操作だとログインからやり直す必要があるのは、セッションIDが無効になったからです。
このセッションIDの発行や管理に不備がある場合、例えばセッションIDが類推可能だった場合、悪意ある人にログイン中の利用者のセッションIDを類推され、その利用者になりすましてアクセスされる可能性があります。ちなみに、Webサービスにおいて他人のデータが表示されてしまう不具合が度々発生していますが、セッション管理周辺の問題であることが少なくありません。

Webアプリケーションの脆弱性に関する脅威状況と対策

近年のインターネットにおいては、Webアプリケーションの脆弱性を含め各種の脆弱性を探索する通信が飛び交っています。探索する通信も自動化・巧妙化が進んでおりWebサイトの構造を分析した上で探索しており、インターネットからアクセス可能であれば、漏れなく探索に晒されていると認識すべきです。これは、OS・ミドルウェアの脆弱性でも設定ミスの脆弱性もそうですが、攻撃可能な弱点は漏れなく見つけ出され攻撃を受ける時代です。
Webアプリケーションの脆弱性への対策としては、ユーザ入力値の検証や特定の文字（例：<、>、&など）の無効化等が基本になりますが、開発全体としては、コーディングルールの徹底やコードレビューやセキュリティテストの実施が必要です。加えて、リリース前にWebアプリケーション診断を行うことも有効です。特に、委託先への依存度が大きいケースでは、リリース前のWebアプリケーション診断は非常に重要です。また、WAF（Web Application Firewall）を導入することも効果的です。そもそも、Webアプリケーション診断やWAFの導入には相応の費用がかかりますのでWebアプリケーションの脆弱性に対する理解が不可欠です。ここまで読まれた方は、その必要性を理解していただけたのではないでしょうか。

＜参考URL＞
安全なウェブサイトの作り方（IPA）
https://www.ipa.go.jp/security/vuln/websecurity/about.html