診断対象選定に関わるパス区切りパラメータについて

はじめに

こんにちは、診断員の秋本です。
「脆弱性診断の対象となるのはどんな機能か」とあらためて考えると、いろいろと見るべき観点が出てきます。
「パラメータを持つかどうか」を前提とすることである程度ふるいにかけられはしますが、「そもそもこれはパラメータなのか？」と判断に悩む場面は多々あります。そんな悩みを生んでしまうものの1つに、パス区切りパラメータがあります。今回は、そんなパス区切りパラメータについてお話していきます。 ※URLパスパラメータとも呼ばれますが、今回はパス区切りパラメータの表記で統一します。

診断対象について

まず、診断対象の立ち位置について軽くお話しします。
脆弱性診断では、Webアプリ内で発生するHTTPリクエストのうち、脆弱性診断の観点があるHTTPリクエストに絞って脆弱性診断を行います。この脆弱性診断の観点があるリクエストは、診断対象リクエストと呼称されます。
弊社では、診断対象リクエストになるかを判断する重要なポイントとして、リクエストパラメータが動的な処理が使われるかを見ています。

診断対象リクエストについてより詳しく知りたい方は、ぜひこちらのブログをご一読ください。

脆弱性診断の前に知っておきたい！～リクエストとは～

リクエストパラメータについて

（動的な処理のために）Webアプリへ値を渡すパラメータとしては、クエリパラメータやボディパラメータが広く使われています。
例えば、商品番号「10」の商品詳細ページへアクセスする際、GETメソッドを利用する場合とPOSTメソッドを利用する場合でそれぞれ以下のようなリクエストが発生します。名称は異なりますが、いずれもパラメータ名=値の形式で送信されています。

■ GETメソッドのクエリパラメータ

GET /item?id=10 HTTP/1.1  
Host: example.com

■ POSTメソッドのボディパラメータ

POST /item HTTP/1.1
Host: example.com  

id=10

これらのリクエストによって、商品番号「10」の商品詳細ページがWebブラウザに表示されます。

商品番号「10」の商品詳細ページ

また、値を10⇒11へ変えることで、同じページ構成のまま、商品の具体的な情報だけが商品番号「11」のものに書き換わったページがWebブラウザに表示されます。

商品番号「11」のものに書き換わったページ

このような動作が確認されれば、商品番号の値をもとにデータベース内のデータを呼び出すような動的な処理が行われていると判断できます。

パス区切りパラメータとは

本題のパス区切りパラメータですが、役割としては先ほどのクエリパラメータ・ボディパラメータと同じ、リクエストパラメータです。
パス区切りパラメータもWebアプリへ値を渡すパラメータとて機能しますが、パラメータ名=値の形式をとらずURLパスの一部として設定されます。パス区切りパラメータを利用して商品番号「10」の商品詳細ページへアクセスする際、以下のようにURLパス/itemの後に/10が設定されます。

GET /item/10 HTTP/1.1  
Host: example.com

/10の部分がパラメータとして処理されることで、以下のような商品詳細ページがWebブラウザに表示されます。

図は省略しますが、/item/11とすることで、商品番号「11」の商品詳細ページが表示されます。
今回の例のように、パス区切りパラメータにはデータごとに振られたIDが良く用いられます。URLパス中に数値やIDのようなものが含まれていれば、パス区切りパラメータとして扱われているかに注目してみてください。

パス区切りパラメータとして扱わないパターン

注意すべき点として、URLに数値やIDのようなものが含まれているからといって、必ずしもパス区切りパラメータになるとは限らないということです。パス区切りパラメータと勘違いされやすいものについて、いくつか例を紹介します。

IDではなくサーバ内のディレクトリ名である

お知らせのPDFファイルやニュース記事など、そのコンテンツのURLに特定のデータを指定している値が設定されていることがあります。

■ お知らせの例

GET /pdf/2020/01/oshirase.pdf HTTP/1.1  
Host: example.com

URLパスに数値の2020と01が含まれており、先ほどの商品番号の例を参考にするとパス区切りパラメータのように思えます。実際には、2020というディレクトリ（windowsで言うフォルダ）の中にさらに01~12というディレクトリがあり、その中に保存されているoshirase.pdfという静的コンテンツを指すURLの場合があります。
以下の図のようなイメージです。

イメージ図

このような場合は、「取得するデータごとにデータベースへのアクセスは発生しておらず、サーバ内に配置されたファイルを直接URLで指定している」⇒パス区切りパラメータではないと判断します。

機能ごとに数値が割り当てられている

Webアプリの実装によっては、機能名が数値で管理されていてその値がURLに含まれているケースがあります。
例えば、申込フォームが「入力画面・確認画面・完了画面」の3画面で構成されているWebアプリで、

■ 入力画面
http://example.com/form/1
■ 確認画面
http://example.com/form/2
■ 完了画面
http://example.com/form/3

のようなURLが割り当てられている場合は、「/form/の後に続く数値で画面（機能）が指定されている」⇒パス区切りパラメータではないと判断します。

入力画面

確認画面

完了画面

まとめ

ここまでの話をまとめます。

脆弱性診断では、動的な処理に使われるリクエストパラメータを持つリクエストを診断対象リクエストする
リクエストパラメータには、パス区切りパラメータと呼ばれるパラメータ形式がある
URLパス部分に設定された値が動的な処理に使われている場合にパス区切りパラメータと判断する
URLパス部分にIDのような値が含まれていても、それがパス区切りパラメータであるとは限らない

URLにパス区切りパラメータが含まれていたとしても、URLを目視しただけでそれを判断することは難しいです。実際の動作を確認したうえで、パス区切りパラメータかどうかを判断するのが適切です。
なお、これは他のパラメータ形式でも同様です。クエリパラメータに値が設定されていたとしても、キャッシュ対策のための値であり、そのパラメータ自体が動的な処理に関与しないケースもあります。

最後に

弊社の脆弱性診断サービスでは、事前調査という工程にて、パス区切りパラメータを含むかどうか・送信されているパラメータが動的な処理に利用されているかどうかなど、様々な観点から診断対象リクエスト選定をサポートします。お客様ご自身でどのリクエストが診断対象として適切かといったことをあらかじめ精査していただく必要はありません。
1つ注意点として、事前調査は脆弱性診断と同様にブラックボックスな作業になるため、本来のWebアプリの実装と弊社の判断にずれが発生してしまう可能性もあります。
もし弊社の事前調査結果にて、パス区切りパラメータなのに対象候補になっていない or パス区切りパラメータではないのに対象候補になっているといった場合があれば、お気軽にお問い合わせください。もちろん、それ以外のご不明点のお問い合わせもお待ちしております。
なお、事前調査を詳しく紹介できるコンテンツはまだないため、今後の投稿をお待ちいただければと思います。