皆さんBugBountyはご存知ですか。
アプリケーションの脆弱性に繋がるバグを発見して、企業に報告してお金をいただくという制度です。
日本では実施されている企業はほぼありませんが、
海外のプラットフォームでは HakcerOneやbugcrowdなどが存在します。
登録したリサーチャーと企業とがお互い合意の上で、アプリケーションの問題を探すプログラムです。
隙間時間を見つけては参加していますが、
世界中のつよセキュリティエンジニアが四六時中バグハントしているのでもうたいていの脆弱性は掘り尽くされていて、非常にセキュアなアプリばかりです。
なのでXSSとかSQLiとか滅多に検出されない。本当に。
報告しても
「それはもう他のリサーチャーに報告されているよ!お金は払えないね！」
と言われてしまうのです。
なので、もう簡単に見つかるBugは諦めて、
少しトリッキーなやつの報告を狙っていたりします。
と、電車で隣に座っていたJKが話していました。
ここからもJKに聞いた話です。
もう試し尽くしてしまいましたので
そんな観点をいくつか展開するのだとか
なお、この内容がセキュリティに携わる方の知見に繋がり、
本記事が、読者自身のセキュリティ対策への理解と、各企業・組織の研修やセキュリティ教育等に活用されることにより、セキュリティ対策の普及の一助となることを期待して、記事を書きます
常識をあえて文字に起こしていますが、BugBountyプログラムを実施していないサイトに脆弱性の検査をしてはいけませんよ。
sqlmap使いの正義のホワイトハッカーの方、qiitaでXSS見つけました報告している方。 お願いしますね。
1. SSRF
身内の勉強会ではよく話すネタですが、
HTTPは問題になる場面が多いです。
サーバから外部リソースが行えるサイトの場合、SSRFの脆弱性を探したりしますが
サーバから送信されるリクエストを指定できる場合、以下のことに利用できたりします。
とJKが話していました。
リダイレクトループ
Slackに代表されるリンクプレビュー機能はURLを貼り付けると、その宛先のアイキャッチを取得します。
あの宛先がさらにリダイレクトしてループするとDoS攻撃に繋がる恐れがあります。
もちろん、wgetコマンドやPHPのcurl_exec()はリダイレクト上限が存在しますが、HTTPの性質上、仕様によってはループが止まらなくなったりそもそもリダイレクト上限がない言語も存在する様です。
なお、SlackはHackerOneのBugBountyプログラムに登録があります。
さらに言うと、リダイレクト上限も考慮された実装でした。
halkichi-web.hatenablog.com
SSRFの調査
Webサーバ限定ですが、
SSRFが可能か調査する際に長いパスを送信してみる、という手法があります。
パス、もしくはパラメータの上限値にチェックがされておらず、490文字、990文字、とか変な文字長でエラーになる場合、アプリの裏側でリソースの呼び出しを行っている場合があるのだとか。
XS-Leaksとも呼ばれるそうです。
Hostヘッダ
HTTPのHostヘッダを宛先のFQDNから変更して送信し、レスポンスのBaseURLが変化する様なアプリケーションがある場合。
変更したFQDNを別のシステムに渡しているアプリをよく見かけます。
パスワードリマインダー機能でメールを送信する際に、TOKENつきURLに反映している場合は注意が必要かもしれません。
クラウドやレンタルサーバを利用している場合は、Hostヘッダの改ざんが403応答になるのでそれだけでオンプレとの差別化になるかもですが、本質から逸れるのでまたいつか記事にしたいと思います。
終わりに
最近のJKはセキュリティの話ばかりしているので助かりますね、セキュリティに携わる身としてはサイバー技術者取締り強化月間が怖いところですが
セキュリティエンジニアの皆様も
JKからセキュリティの知見を聞いた場合は是非共有してもらえませんか
どうぞご検討ください。
開発者の方は、上記の様な実装にはご注意ください。
決してBugBounty以外の用途で使用されることがなきようにお願いします。
???「こんなのサイト固有のロジックの不備じゃん、そんな実装あるわけないよ!」
私もそう思っていますが、人聞きの話なので。でもよく見つかるのだとか?
