yamory Blog

アプリケーション外でも発生する脆弱性 パストラバーサル

パストラバーサル(Path Traversal、以下パストラバーサルで統一) は、本来アクセスできないディレクトリに存在するファイルに対して、脆弱性を悪用してアクセスする攻撃手法・脆弱性です。
この脆弱性はディレクトリトラバーサル(Directory Traversal)とも呼称されています。

本記事では、パストラバーサルの脆弱性についてを説明した後、対策方法と、発展的な「nginxで発生してしまうパストラバーサル」についても触れていきます。

パストラバーサルとは?

説明のため、1つのアプリケーション例を題材として話を進めていきます。
以下のような構成のWebサーバがあったとしましょう。

... --- /www/ --- /public/ --- index.html
          |
           -- /secret/ --- secret.key

ユーザーはインターネットを通じて、公開ディレクトリとして指定されている public ディレクトリへアクセスが行えるものとします。
また secret のディレクトリに対しては、ユーザがアクセスできないように制御を行っています。

仮にパストラバーサルの脆弱性が存在した場合、
本来アクセスできない領域である secret のディレクトリに対して、脆弱性を悪用することでアクセスできる場合があります。

secret ディレクトリに機密データが存在した場合には、パストラバーサルが原因で漏洩事故などにつながります。

パストラバーサルの影響

Webサーバにパストラバーサルの脆弱性が存在すると、どのような被害が考えられるでしょうか?
影響としては、以下が考えられます。

個人情報や企業データといった機微情報の漏洩・流出

ファイルの読み込み箇所などでパストラバーサルが発生した場合、「アプリケーションサーバー内」に存在するファイルを読み込まれる可能性があります。
これらのファイルの中に個人情報を含むデータが存在した場合、大きな問題となります。

通常のアプリケーションであれば、データベースなどに個人情報はまとまっていますが、中にはエラーログやアクセスログなどに個人情報が入ってくるケースがあります。
そのため「このサーバでは機微な情報を扱ってない」と言った考え方で対策を怠るのは、非常に危険です。

サーバ上のデータの書き換え

パストラバーサルは、ファイルの読み込みだけで発生する問題ではありません。
この問題は、書き込み箇所でも発生することがあります。
書き込みで問題が発生した場合、データを不正に書き換えることによる完全性の侵害が考えられます。

また発展的な内容としては、スクリプトなどを書き換えることによる不正なコード実行などが挙げられます。
例えばサーバ上にアップロードされたPHPなどのスクリプトを書き換え、本来と違う挙動にした上で実行させ、更なる攻撃につなげる可能性があります。

クレデンシャル情報の漏洩による横展開

何かしらの認証情報となるクレデンシャルがパストラバーサルによって漏洩した場合、更なる改ざんや漏洩といった問題につながることがあります。

例えばAWSやGCPといったプラットフォームのクレデンシャル情報が漏洩すると、そこを足がかりに更なる侵害・被害を受けてしまいます。

開発中であれば「そんなファイルはサーバーに上げていない」と思われるかもしれません。
しかし、本当にサーバーにアップロードしていないでしょうか?
開発者にとって、 .ssh .git といった隠しディレクトリや隠しファイルは盲点かもしれません。

ディレクトリトラバーサルのメカニズム

パストラバーサルにおける影響を知ることで、この脆弱性の危険度を認識していただけたと思います。
ここからは、この脆弱性の発生メカニズムについて見ていきます。

通常、ディレクトリトラバーサルの発生原因は非常にシンプルです。
この問題の多くは、プログラムによって何かしらのファイルを読み込んだり、書き込む際のロジックに不備があることで発生します。

外部パラメータ、つまりユーザからの入力によって「読み込み・書き込みを行うファイル」を決定する処理があった場合、パラメータに「パス文字」などが入り込むことで、この脆弱性は発現します。

例えば、以下のようにファイルを開く処理があったとします。

String fileName = getRequestParameter("fileName") // ユーザからの入力を取得するようなコード
FileOutputStream fos = new FileOutputStream(new File("./public/" + fileName));
// ...

このコードでは、 ユーザのリクエスト内容によって ./public/ ディレクトリにあるファイルを読み込む処理が記述されています。

しかし、 fileName に対して ../secrets/secret.key といった相対パス文字( ../ )を含んだリクエストを送った場合、パスは ./public/../secrets/secret.key となります。
すると、対象の ./public/ ディレクトリより上層の親ディレクトリ移動した後、 secrets ディレクトリへのアクセスとなります。

このように、パス文字などによってパストラバーサルの問題は発生します。

Windowsにおけるパストラバーサル

先ほどのパス文字 ../ は、Linux, OS Xにおけるパストラバーサルの説明でした。
Windowsサーバの場合は、先述したUNIX系のOSではないため、パス指定の仕方が変わってきます。
例えば、Windowsの場合は ..\WINDOWS\win.ini といった形式のパス記述方式となるため、攻撃パラメータとなる相対パスの文字もそれに合わせて ..\ などに変わってきます。

これらのアクセスがあった場合、殆どのケースが攻撃であるため、WAF などを使い、アプリをセキュアにしていくことが大切です。
また、後述する対策方法を行い、根本的な問題解決をすることが重要です。

ディレクトリトラバーサルの対策方法

ディレクトリトラバーサルの対策は、一般的に以下の方法が実施されます。

  • .. といった相対パスや、ショートカットの特殊ファイル名などを削除し、対象ファイルへのパスを計算する
  • ファイル操作の際は、計算後のパスが、想定していたパス・ディレクトリ内であるかを検査する

先ほどの脆弱なコードでは、これらの対応がなされていませんでした。
つまり「ユーザから受け取ったパラメータをそのままパス計算に使い」、「計算結果が意図したパスとなっているかチェックしていない」ということです。
そのため、パストラバーサルの脆弱性が発生するコードとなっていました。

nginxで発生するパストラバーサル(エイリアストラバーサル)

ここまで基本的にはアプリケーションにおけるパストラバーサルについて解説を進めてきました。
暗黙的に「パストラバーサルはアプリケーションが原因でしか発生しない脆弱性」といったイメージを持たれているかたも居ると思います。
しかし、「nginx」というWebサーバのミドルウェアでも「nginxの設定ファイルの書き方を誤る」という条件下でこの脆弱性は発生します。

※この問題はパストラバーサルではなく、Alias Traversal・エイリアス・トラバーサルと呼ばれたりもします。

次のnginxの設定では、 example.com/static というURLのリクエストを受け取った場合、 alias によって指定されたパス /var/www/app/static/ 上のファイル参照が発生します。

location /static {
    alias /var/www/app/static/;
}

このように、「ロケーションのパスの割り当て」を行うのがnginxの alias というディレクティブです。
ただ上記の設定を行なっている場合、次のリクエストを送ることで、パストラバーサルが発生します。

http://example.com/static..%2fsecrets/secret.key

このURLをリクエストした場合、ドメインの後の /static ファイルパスがnginxの設定ファイルにマッチすることで、 alias ディレクティブが適用されます。
これにより、ファイル参照の起点が /var/www/app/static になります。
しかし、後続文字である ..%2f という ../ をURLエンコードした文字をそのまま処理してしまうため、1つ親のディレクトリである /var/www/app/ へのファイル参照が発生します。
これにより /var/www/app/secrets/secret.key という、開発者の意図しないディレクトリへの参照が発生します。
これが、nginxにおけるパストラバーサルの脆弱性です。

この問題は、1行目の location のパラメータを修正することで修復できます。

// 脆弱性がある設定
location /static {

// 脆弱性がない設定。staticの後に / が存在する。
location /static/ {

問題となっているのは location でURLパスを選別する際の末尾の / です。
ここが無いと、攻撃者はnginxの仕様を悪用することで、制御文字となる ../ をnginxに解釈させることができます。

(nginxの設定による脆弱性を防ぐツールとして、 gixy というnginxの設定ファイル用静的コード解析ツールがあります)

このようにパストラバーサルの脆弱性は、アプリケーション固有の脆弱性ではないことがわかります。

さいごに

本記事では、パストラバーサルの脆弱性から、発展的な内容としてミドルウェア「nginx」で発生するパストラバーサルについて扱いました。
「脆弱性を防ぐ」という行為はとても難しく、知識だけではなく、多くの努力が必要です。
本記事を通して「アプリケーションだけ直しておけば安全」と言った誤った考え方は、非常に危険であることを理解いただけたと思います。
そのため、安全なアプリケーションを作っていくためには、様々なアプローチで多層的に守って行かなければなりません。

脆弱性とは、意図しない書き方や問題が起こりえない部分でも発生します。
そのため、脆弱性情報を収集したり、問題となる箇所を理解していくということが非常に重要です。

yamoryでは、脆弱性診断ではカバーできない継続的な開発をサポートするためにセキュリティ向上のためのモニタリングを支援しております。

是非一度お試しいただけると幸いです。

オープンソース脆弱性管理ツール yamory

  • 利用中のOSSを抽出し
    脆弱性を自動スキャン
  • 脆弱性への対応優先度を自動で分類
  • 組織規模に合わせたプランを選択可能

フリー

¥0

個人向け

1チームまでの開発チーム作成

yamory を使いはじめる

プロ

有料料金はお問い合わせください

中〜大規模組織向け

無制限の開発チーム作成

開発チームを俯瞰できるセキュリティチーム機能

危険な脆弱性の Slack 連携通知機能

Jira Cloud と連携

シングル・サインオン(SSO)連携*

* SSO 連携は無料トライアルではご利用できません。プロプラン契約後からご利用できます。

30日間の無料トライアルを開始