クラウド型脆弱性診断ツール VAddyブログ

- 継続的セキュリティテストへの道 -

VAddyで同時クロールを実現した技術的な背景

先日、複数人で同時に同じプロジェクトでクロールできる機能をリリースしました。
それを実現するまでに出た課題、検討事項、解決策が一般的なWeb開発とは異なる背景が多くて面白そうなので書きたいと思います。

 

blog-ja.vaddy.net

 

前提

クロールはブラウザやcurlなど、HTTP通信するクライアントのProxyを設定して、VAddyのProxyサーバを経由してオリジンサーバにアクセスします。その際にVAddy Proxyサーバ側にアクセスしたURLやパラメータが記録され、それが脆弱性診断に利用されます。
これはVAddy特有の機能ではなく、他の脆弱性診断ツールも同じような仕組みになっています。

クロール中はProxyサーバがユーザを識別できるものとして、HTTPリクエストに含まれるHostヘッダのFQDN、接続元クライアントIP、Cookie程度です。この情報だけでクロールのセッションをユーザごとに管理しなければならないのが特徴です。

VAddyはSaaSですので、複数のユーザがProxyサーバに接続してクロールデータを作成しますので、それぞれにセッションを持ってデータが混ざらないように管理しなくてはいけません。ここがインストール型の脆弱性診断ツールとは異なる課題になります。

 

課題

VAddyでは、複数FQDNを横断して一つのクロールにして検査できます。例えばシングルページアプリの場合はフロントとバックエンドでFQDNが異なることが多いと思いますので、それらを一括でクロールできます。
この時に、VAddyのProxyサーバ側で独自にCookieを発行して複数FQDNのまとまりを管理できるようにしていました。

ここで出た問題が2つありました

  1. Cookieが付与されないHTTPリクエストがある
  2. プロジェクトで1つのcookieしか発行していないため複数人のクロールができない

上記1.のCookieが付与されないリクエストの例として、ブラウザが自動で発行するPreflight requestがあります。そのほかには、JavaScriptが非同期にリクエストする時に、JavaScriptフレームワークがデフォルトではCookieを付けないものがあります。

上記2.はVAddyのプロジェクト単位にCookieを発行していたため、同じプロジェクトだとCookieが重複してしまう問題があります。

 

解決策の検討

今回は、1と2の課題を両方解決することにしました。2だけ解決するのであれば、Cookieの発行単位をプロジェクト単位からクロールするユーザID単位に変えるだけのため簡単に解決できるのですが、将来的に1も解決しなければクロールできないサイトが増えてしまうためCookieを使わない大きな方針を決めました。

Cookieを使わずに、一人のユーザが複数のFQDNにアクセスして、それを1つのクロールとして管理する課題を解決しないといけなくなりました。

使える要素として、最初に述べたアクセス先のFQDN、クライアントの接続元IPでユーザを識別すればまずは解決できそうに感じました。
しかし、同じ会社から複数人が使う場合は、接続元IPが同じになる可能性が高く、これではすぐに問題がでると予想できます。


解決策 

今回VAddyで採用した方法は、アクセス先のFQDN、クライアントの接続元IPのほかに、VAddyのProxyポートを複数用意してそれを使って識別することにしました。

今までは、28888ポートのみで提供していましたが、今後は28888, 28889, 28890というようにたくさんのポートをlistenして同じProxyとして動作するようにし、同じIPからの接続であればユーザごとにポートを分けるようにしました。

今回の方法により2つの課題が解決できました。listenポートがたくさんあるため、今までよりはProxyサーバのスレッド数が増加してリソースを消費しますが、大幅にリソース消費すわけではないので、今回の方法でリリースとなりました。

 

さいごに

VAddyは、チーム機能のほかに、2019年にエンタープライズプランで組織管理機能をリリースしました。今後も複数人で使うチームや組織管理に力をいれていくため、今回のリリースをしました。

Proxyを開発運用して、それをSaaSの形で提供してセッションを管理していくという、他の会社ではなかなか見られないようなことをVAddyではしています。ほかにも一般的なWeb開発では見られない開発もしていますので、今後もこのブログで発信していく予定です。