先日、複数人で同時に同じプロジェクトでクロールできる機能をリリースしました。
それを実現するまでに出た課題、検討事項、解決策が一般的なWeb開発とは異なる背景が多くて面白そうなので書きたいと思います。
前提
クロールはブラウザや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が付与されないリクエストの例として、ブラウザが自動で発行する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開発では見られない開発もしていますので、今後もこのブログで発信していく予定です。
