ホワイトハッカーの手を借りてバグを修正!BugBounty のススメ #Zaim
見出し画像

ホワイトハッカーの手を借りてバグを修正!BugBounty のススメ #Zaim

どうもこんにちは。Zaim でユーザー事業部のマネージャーをしております高山です。どうも。えっとついこのまえ記事を書いた時と部署名が変わってますね。するどいですね(誰も気づかなそう)。そうなんです、なにやらいろいろ組織図が変わるという出来事があったのでした。あんまり関係ないですね。

今日は、半年くらい前から利用している BugBounty というサービスがめちゃくちゃいいんで紹介しにきました。

世界中の凄腕ハッカーが脆弱性を発見してくれる

BugBounty は、サイバーセキュリティに関する事業を中心に展開しているスプラウト社が提供しています。サービス内容を端的にいうと「世界中の凄腕ハッカーに自社サービスの脆弱性を探してもらう」です。

自社サービスにセキュリティ上の欠陥は少ないに越したことはありません。しかし、社内のメンバーのみで対応するとしてもなかなか多くのリソースを割けないことや、そもそもいわゆる攻撃のスペシャリストであるスーパーハッカーの技術と知識に対抗しようとしても、自社内だけでやるには限界があると言わざるを得ません。

そうした我々のようなサービスプロバイダーが BugBounty サービス上で告知すると、あらかじめ BugBounty に登録しているホワイトハッカーの方たちがそれぞれ調査をしてくれます。問題が見つかればどしどし報告してくれて、それをスプラウト社の方が整理して我々にレポートしてくれます。

レポートには脆弱性の内容や再現手順などの情報とともに、報奨金の目安が記載されいてるので、内容を見て適宜報奨金の認定をしていくという流れです。もちろん脆弱性の修正も忘れてはなりません。

スプラウト社は日本の会社なのでホワイトハッカーも日本の人が多いかなと思ったのですが、意外と海外のハッカーも多く、日英展開しているサービスの場合は英語での脆弱性報告のほうが多い傾向にありました。

BugBounty を選んだ理由

この手のサービスはいくつかありそうですけど、とりあえず検索して見つけた BugBounty に軽い気持ちで問い合わせしてみました。そうして打ち合わせに来てくださった代表の方の印象が良くて、信頼できそうと思ったことが一番大きな理由ですね。

それと、脆弱性に対する報奨金はこちらが任意で決められることや、報奨金の目安も充実していること、あらかじめ決めておいた上限を超えそうならストップしてくれることなど、気軽に試すことができそうな仕組みになっていてとても安心感がありました。

BugBounty 開始の手続きは想像以上に簡単だった

こういうのって最初は右も左もわからない感じで戸惑うものかと思うんですが…、ですよね? いや実際「認定対象の脆弱性を選択してください」って言われても種類が多すぎて「どうしたらいいんだ?」って気持ちになると思いますよ…。

しかしそこは我らが BugBounty 。そういうのちゃんと考慮されていて、募集要項をまるっと作ってくれました。「いい感じにお願い」って言っていい感じにしてくれるの最高です…。日英作ってくれたのでほんとありがたすぎて涙が止まりません。

と言った具合に、ざっくり予算感や調査対象を伝えるといい感じにしてくれるわけです。

・全体の予算
・調査期間
・Web サービスの場合は調査対象のホスト名
 (開発環境があればそちらにしましょう)
・アプリの場合は調査対象アプリのストアの URL

あたりを伝えていざ募集開始です。うっかりエスケープ処理を忘れた XSS とかがあると速攻で見つかります。(弊社の募集要項

募集開始後のコミュニケーションの流れとしては大雑把に次のようになります。

・ホワイトハッカーの人が脆弱性を発見・再現手順を報告
・スプラウト社の中の人が内容を確認・再現できるか改めてチェック
・脆弱性の分類情報や手順をわかりやすくまとめなおして Zaim へ報告
・報告件数がたまってきたら概要と報奨金目安や対応可否の指針をレポート

例えば「込み入った再現手順にも関わらず脆弱性が再現しない」+「英語」のような場合、確認するためのコストはそれなりにかかると思いますが、スプラウト社が間に入ってコミニュケーションしてくれるので、ものすごい楽です。基本的にこちらから直接コミュニケーションする必要がありません。

最終的なまとめのレポートを見て、念のため再現するかを確認し、必要に応じて報奨金を支払うと終了です。

半年で 13 件の脆弱性を修正

この半年で Web サービスと iOS/Android アプリをやってもらい、結果として 13 件の修正を完了しました。また、重複を除いて実際に支払いに至った脆弱性は 20 数件ほどです。この中の 3 割くらいは「対応を実施しない場合は支払い対象外としてもよい」という内容で、例えば「ログイン履歴が即座に更新されない(*)」といった感じの項目です。が、それぞれ納得できる内容だったのでなるべく支払いをして修正するようにしています。(*この問題は修正済みです)

また XSS がめちゃくちゃすぐに見つかるのが印象的でした。残念ながら何箇所かエスケープ漏れが残っていて、例えば家計簿の分類カテゴリの名前を特定の内容にした上で「バランス診断」というサービスを利用して最後まで進むと発動するとか…こうした脆弱性は self-XSS と言ってそもそも発動条件が限定的なので影響範囲は狭いのですけど、放置しておくのはまずいので見つかったのは本当に良かったです。

幸いにも重篤な脆弱性は見つかりませんでしたが、普段あまり意識しないような部分での指摘があったりと、見つかった脆弱性の内容と件数を考えると破格としか思えなくて非常に満足しています。

引き続き利用していこうと思っています。


この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
うれしい!!
気ままに書いてます