Node.js における http モジュールでの Unicode の扱いと SSRF について

ここで書く内容は blackhat USA 2017 で Orange Tsai 氏が発表した 「A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!」 で取り上げられていた内容を自分が改めて理解するために書き残したメモです。 概要 var base = "https://example.com/article/"; var path = req.query.path; if (path.indexOf("..") == -1) { http.get(base + path, callback); } 上記のようなコードのとき、 /?path=../passwd のようにアクセスして http.get() の処理に入り、 /article/../passwd を取得することはできるだろうか。 一見 if 文は false になるため不可能そうに見えるが、実は true になることがある。 true とするには /?path=ĮĮ/passwd というURIにアクセスすることで可能となる。 ここでは、なぜこれでバイパスできてしまうのか、ということを書いていく。 ちなみに今回検証で確認できたのは Node.js 4.9.1 Argon ( ubuntu 16.04 LTS で未だに入る ) 。

SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例

電気が送電されました!万歳!! 9/8が誕生日なのでお待ちしております。 http://amzn.asia/azuF53V 先日、以下のような記事を見た。 EC2上のAWS CLIで使われている169.254について EC2では、インスタンス内から http://169.254.169.254/ にアクセスすると、そのインスタンスに関する情報が取得できるようになっている。 そのため、SSRF脆弱性が存在し、レスポンスをユーザーに表示しているような場合には、http://169.254.169.254/latest/meta-data/iam/security-credentials/ にアクセスされることで、AWSのクレデンシャルを不正に取得される。 SSRFについてはここでは解説しない。以下の記事などを参照してほしい。 What is Server Side Request Forgery (SSRF)? HOW TO: SERVER-SIDE REQUEST FORGERY (SSRF) SSRFは WebHook などを実装する際に作り込みやすく、過去には GitLab や Slack などのサービスでも報告がある。 SSRF vulnerability in gitlab.com via project import SSRF vulnerability in gitlab.com webhook Internal SSRF bypass using slash commands at api.slack.com さて、インスタンス情報やクレデンシャルを取得できるのは EC2 に限った話ではなく、このようなメタデータサービス(という呼び方でいいのだろうか)を提供しているクラウドサービス全般で(GCPやAzureでも)発生する可能性がある。 ここでは、GCPを例に挙げてみる。 GCE GCEでは http://metadata.google.internal/computeMetadata/v1/project/ というエンドポイントにインスタンス内にアクセスすることでプロジェクトの情報を取得できる。 ただし、Metadata-Flavor ヘッダーを付与しなければいけない。そのため、Webアプリケーション上にSSRF脆弱性が存在していても情報が漏れる可能性は低い。