![試してみた
Nghttp2をProxyとして動作させることで、Burp Suiteでもアクセスできるよう
になった。
nghttpx --client -f0.0.0.0,8080 –b[HTTP2サーバのIP],443 -k -o -LINFO](https://image.slidesharecdn.com/http2-150627103300-lva1-app6892/75/Web-RFC7540-HTTP-2-Web-33-2048.jpg)
![② レスポンススプリッティング
4.フォワードプロキシ(nghttpx)へのHTTP/2のレスポンス
[2805.766] send HEADERS frame <length=27, flags=0x04, stream_id=5>
; END_HEADERS
(padlen=0)
; First response header
:status: 302
content-type: text/html; charset=utf-8
location: http://www.yahoo.co.jp
content-length: 0
via: 1.1 nghttpx
[2805.766] send DATA frame <length=0, flags=0x01, stream_id=5>
; END_STREAM
※20015/6/27に内容を追加してます。
レスポンスは、HEADERSフレームとDATAフレームのみで、DATAフレームの
サイズも0となっている。](https://image.slidesharecdn.com/http2-150627103300-lva1-app6892/75/Web-RFC7540-HTTP-2-Web-50-2048.jpg)
もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら
- 3. 宣伝 7/26（日） に開催されるJULY TECH FESTAにて、 「フリーでできるセキュリティチェック」という タイトルにて、プレゼンをさせていただきます。 ”無料”のツールを利用して、ラクにセキュリティ チェックを行うためのノウハウをご紹介いたし ます。 インフラエンジニア、運用を担当されている エンジニア向けの内容となっています。 http://2015.techfesta.jp/
- 4. HTTP/2って HTTP（HyperperText Transfer Protocol）の最新バージョンにあたり、HTTP/1.1 から16年ぶりのアップデート。HTTP/2についてはRFC7540、関連するHPACKは RFC7541でリリースされました。 HTTP/1.1と比較するとHTTP/2は複雑になっています。 HTTP/1.1との違いはこんな感じ。 ① 多重化 ② バイナリメッセージ ③ ヘッダ圧縮（HPACK） ④ フロー制御 ⑤ 優先度 ⑥ 依存関係 ⑦ Server Push
- 9. ② バイナリメッセージ リクエストのHEADERSフレーム。 00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 84 87 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 03 2a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0 緑箇所の3byte「00 00 26」がフレームサイズで38byte（0x26） 最初の9byte（固定長）は、フレームヘッダ。 青箇所の「01」がフレームタイプを表しており、0x01はHEADERSフレーム。 黄色箇所の「25」はFlagで詳細はRFC7540へ。 茶色箇所の4byte（正確には31bit分）はStream IDで、この場合は13。
- 10. ② バイナリメッセージ リクエストのHEADERSフレームペイロード（赤箇所） 00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 84 87 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 03 2a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0 青箇所は依存先のStream IDを指している。 白箇所でPriorityフラグ（0x20）がセットされた場合にのみ、青箇所と 緑箇所が出力される。 緑箇所はweightで、「0f」の場合、15+1=16となる。
- 12. ③ ヘッダ圧縮（HPACK） さっきのHeader Blockの場合 00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 84 87 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 03 2a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0 0x82（1000 0010）でIndexの2を指しており、「:method: GET」を意味します。 同様に0x84、0x87は、それぞれIndexが4、7を指しています。 Index 4 ・・・ :path: / Index 7 ・・・ :scheme: https
- 13. ③ ヘッダ圧縮（HPACK） bitにより、どういう意味なのか変わってくる。 Indexは事前に定義されたヘッダ名の 値をセットする。0x41の場合、Index が1である:authorityを指す。 2byte目（緑箇所）は、上位bitがハフ マンエンコーディングの有無を指定 し、値長を指定している（11byte）。 00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 84 87 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 03 2a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0
- 14. ③ ヘッダ圧縮（HPACK） :authority:ヘッダの値は、赤箇所のbyte列（11byte分）になる。 このbyte列はハフマンエンコーディングされているため、このままでは 可視できるものではないので、ハフマンでコーディングを行う必要が ある。 00 00 26 01 25 00 00 00 0d 00 00 00 0b 0f 82 84 87 41 8b 0b e2 5c 2e 3c b8 5b 7d 70 b2 cf 53 03 2a 2f 2a 90 7a 89 aa 69 d2 9a c4 c0 57 02 e0
- 15. ③ ヘッダ圧縮（HPACK） まずは、11byteを2進数に変換し、結合する。 RFC7541で定義されているテーブルから 戻してあげればいい。赤箇所の 「00001」は1を意味しており、白は9、 青は2を意味する。 これを繰り返すと「 192.168.159.133 」 となる。緑箇所は余りで1でpaddingされ ている。 00001011111000100101110000101110001111001011100001011011011111010111000010 11001011001111
- 16. ④ フロー制御 HTTP/2では1つのコネクションで複数のstreamが通信できる。複数のstreamが 一斉に大量の通信をはじめたら・・・。 俺、通信するっ！！ じゃ、俺も俺も。 じゃ、俺も俺も。 誰も「どうぞ、どうぞ」を言わないと、重要な通信が行えなくなってしまう。 どうぞ、そうぞ どうぞ、そうぞ えっ！？
- 18. ④ フロー制御 たとえば、237byteのデータをStreamIDが1のウィンドウサイズ127byteの設定 で通信した場合・・・ 2. サーバが237byteのデータのうち、127byteをsend クライアント サーバ コネクション ウィンドウサイズ：65535 StreaｍID:1 ウィンドウサイズ：127 1. クライアントがInitial Window Sizeを127byteへ変更をsend コネクション ウィンドウサイズ：65535 StreamID :1 ウィンドウサイズ：127 クライアント サーバ
- 19. ④ フロー制御 4. サーバが残りの110byteをsend クライアント サーバ コネクション ウィンドウサイズ：65408 StreaｍID:1 ウィンドウサイズ：127 3. クライアントがWINDOW_UPDATE(StreamID:1)127byteをsend コネクション ウィンドウサイズ： 65408 StreaｍID:1 ウィンドウサイズ：0 クライアント サーバ
- 20. ④ フロー制御 Initial Window Sizeは、SETTINGフレームで指定します。 00 00 0c 04 00 00 00 00 00 00 03 00 00 00 64 00 04 00 00 00 7f 赤箇所9byteはフレームヘッダ。黄色箇所以降がSETTINGフレームのペイロード。 2byteの識別子と4byteの値の計6byte単位で構成される。 黄色箇所0x03は、SETTINGS_MAX_CONCURRENT_STREAMS を意味し、値は緑箇所 の0x64(100)。0x04がSETTINGS_INITIAL_WINDOW_SIZEで、0x07(127)。 ※ SETTINGS_INITIAL_WINDOW_SIZEはオプションで強制的に0x07に指定してます。
- 21. ④ フロー制御 WINDOW_UPDATEは、WINDOW_UPDATEフレームで実行されます。 00 00 04 08 00 00 00 00 0d 00 00 00 1f WINDOW_UPDATEは、「コネクションに対して」と「Streamに対して」行うこと が可能で、フレームヘッダで指定するStream IDが0の場合、「コネクションに 対して」、指定するWindow Sizeが追加される。「Streamに対して」行う場合は 該当するStream IDを指定する必要がある。両方に対して行う必要がある場合は それぞれのWINDOW_UPDATEフレームを送信する必要がある。
- 22. ⑤ 優先度 各StreamがWindow Sizeの上限まで使い切ることがないように、Streamに対して 優先度(Wight)をつけて、その割合に応じて通信を行う。 値は1から256の整数で指定することが可能です。Defaultは16です。 StreamID:1 Wight:12 StreamID:3 Wight:3 この場合、StreamID:1は全体の5分の4の割合で通信を行います。 非常に参考になりました。 HTTP/2 Deep Dive: Priority & Server Push by Moto Ishizawa https://speakerdeck.com/summerwind/2-deep-dive-priority-and-server-push
- 23. ⑤ 優先度 優先度の指定は、PRIORITYフレームを用いて行うことが可能です。 00 00 05 02 00 00 00 00 03 00 00 00 00 c8 赤箇所はフレームヘッダ。 青箇所は依存するStreamIDを指定し、この場合は0を指していている。 緑箇所が該当Stream(StreamID:3)の優先度で、0xc8(200)+1=201が優先度となる。
- 25. ⑦ Server Push 通常、クライアントからリクエストを送信し、それに対してレスポンスを 返すが、Server Pushはクライアントからのリクエストを受けずにサーバが レスポンスを返す。 クライアント サーバ リクエスト レスポンス Server Pushのレスポンスは、クライアントが送信すると予定されるリクエスト とデータを返します。データはクライアントでキャッシュされます。
- 26. ⑦ Server Push Server Pushするために、サーバからクライアントにPUSH_PROMISEフレームで 通知しておく必要があります。 Promissed Stream IDは、Server PushされStreamIDがセットされる。サーバが 起点となるため、この値は偶数となる。また、Header Block Fragmentには 予定されるリクエストをセットされます。
- 27. ⑦ Server Push Server Pushするために、サーバからクライアントにPUSH_PROMISEフレームで 通知しておく必要があります。 00 00 18 05 04 00 00 00 0d 00 00 00 02 82 04 87 61 09 f5 41 57 22 11 87 41 87 08 9d 5c 0b 81 70 ff 赤箇所はフレームヘッダ。緑箇所は、Server PushするStreamIDでID:2を指定。 水色箇所は、予定されるリクエストヘッダになっており、HEADERSフレーム と同様にデコード可能。
- 29. Web診断って Proxyツールを使う理由は、ブラウザで操作できる内容が限られているためです。 都道府県： 性別： 男 女 東京都 （ブラウザ上で）入力形式が固定化されている 場合にProxyツールを用いて、入力値を変更します。
- 33. 試してみた Nghttp2をProxyとして動作させることで、Burp Suiteでもアクセスできるよう になった。 nghttpx --client -f0.0.0.0,8080 –b[HTTP2サーバのIP],443 -k -o -LINFO
- 38. なぜ、HTTPヘッダインジェクションなのか 検証するにあたり、脆弱なソースを用意した。 ※オープンリダイレクタも存在します。 #!/usr/bin/perl use utf8; use strict; use CGI; my $cgi = new CGI; my $url = $cgi->param('url'); print "Status: 302 Movedn"; print "Content-Type: text/html; charset=UTF-8n"; print "Location: $urln"; print "n"; print "<hmtl>n"; print "<body>n"; print "redirect done!!n"; print "</body>n"; print "</hmtl>n"; exit;
- 39. ① 任意のヘッダ挿入 HTTP/2の場合、HPACKを用いてヘッダの圧縮を行っているため、脆弱性を悪用 してヘッダにインジェクトしようとしても、ただの文字列として処理されて しまうのではないかと推測した。 ＜レスポンス＞ HTTP/1.1 302 Found Date: Thu, 25 Jun 2015 00:17:28 GMT Set-Cookie: a=a Location: http://www.yahoo.co.jp 以下略 ＜リクエスト＞ GET http://192.168.159.152:8433/redirect.cgi?url=http://www.yahoo.co.jp%0a%0dSet- Cookie:a=a HTTP/1.1 以下略 脆弱だった。。。
- 41. ② レスポンススプリッティング HTTP/2では、レスポンスヘッダとレスポンスボディはそれぞれ違うフレーム として送信されるため、レスポンスを分割したとしてもキャッシュされない のではないかと推測。 ＜リクエスト＞ GET http://192.168.159.152:8433/redirect.cgi?url=http://www.yahoo.co.jp%0a%0dContent- Length:0%0a%0d%0a%0dHTTP/1.1%20200%20OK%0a%0d%0a%0d<html><body>inject</body></htm l> HTTP/1.1 Host: 192.168.159.152:8433 以下略 ＜赤字箇所のURLデコード結果＞ 改行 Content-Length:0 改行 改行 HTTP/1.1 200 OK <html><body>inject</body></html>
- 42. ② レスポンススプリッティング 結果は・・・。 HTTP/1.0 302 Moved Temporarily Date: Thu, 25 Jun 2015 16:57:28 GMT Location: http://www.yahoo.co.jp Content-Length: 100 Content-Type: text/html; charset=UTF-8 Connection: keep-alive HTTP/1.1 200 OK <html><body>inject</body></html> <hmtl> <body> redirect done!! </body> </hmtl> プログラムがそもそも意図した通りになっていなかった。。。
- 43. ② レスポンススプリッティング ※20015/6/27に内容を追加してます。 意図した通りのレスポンスになっていないため、pythonで強制的にレスポンス スプリッティングした結果がHTTP/2(nghttpx)ではどのように評価されるか検証 してみた。 参考 http://qiita.com/otoyo/items/98098e927797272d0a39 プログラムは一部抜粋 self.wfile.write("HTTP/1.1 302 Foundrn") self.wfile.write("Content-Type: text/html; charset=utf-8rn") self.wfile.write("Location: http://www.yahoo.co.jprn") self.wfile.write("Content-Length:0rn") self.wfile.write("rn") self.wfile.write("HTTP/1.1 200 OKrn") self.wfile.write("rn") self.wfile.write("<html><body>inject</body></html>rn")
- 44. ② レスポンススプリッティング Pythonサーバにアクセスすると以下のレスポンスが常に返される。 HTTP/1.1 302 Found Content-Type: text/html; charset=utf-8 Location: http://www.yahoo.co.jp Content-Length: 0 HTTP/1.1 200 OK <html><body>inject</body></html> ※20015/6/27に内容を追加してます。 青字箇所がレスポンススプリッティングされることを想定したレスポンス。
- 45. ② レスポンススプリッティング ブラウザ → Burp Suite → フォワードプロキシ(nghttpx) → リバースプロキシ(nghttpx) → Pythonサーバという順でアクセスした結果。 HTTP/1.1 302 Found Date: Sat, 27 Jun 2015 08:10:08 GMT Location: http://www.yahoo.co.jp Vary: Accept-Encoding Content-Length: 0 Content-Type: text/html; charset=UTF-8 Server: nghttpx nghttp2/1.0.4 Via: 1.1 nghttpx, 2 nghttpx 2つ目のレスポンスがなくなっている。 ※20015/6/27に内容を追加してます。
- 46. ② レスポンススプリッティング リバースプロキシ(nghttpx)のログは、大きく4つのポイントがあります。 1. フォワードプロキシ(nghttpx)からのHTTP/2のGETリクエスト 2. PythonサーバへのHTTP/1.1のGETリクエスト 3. PythonサーバからのHTTP/1.1のレスポンス 4. フォワードプロキシ(nghttpx)へのHTTP/2のレスポンス ※20015/6/27に内容を追加してます。
- 47. ② レスポンススプリッティング 1.フォワードプロキシ(nghttpx)からのHTTP/2のGETリクエスト :method: GET :scheme: http :authority: リバースプロキシのIP :path: / user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: ja,en-US;q=0.7,en;q=0.3 accept-encoding: gzip, deflate x-forwarded-proto: http via: 1.1 nghttpx ※20015/6/27に内容を追加してます。
- 48. ② レスポンススプリッティング 2. PythonサーバへのHTTP/1.1のGETリクエスト GET http://リバースプロキシのIP/ HTTP/1.1 Host:リバースプロキシのIP User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Via: 1.1 nghttpx, 2 nghttpx ※20015/6/27に内容を追加してます。
- 49. ② レスポンススプリッティング 3. PythonサーバからのHTTP/1.1のレスポンス :status: 302 content-type: text/html; charset=utf-8 location: http://www.yahoo.co.jp content-length: 0 via: 1.1 nghttpx ※20015/6/27に内容を追加してます。 ※疑似ヘッダフィールド「:status」が出力されている。理由は不明。
- 50. ② レスポンススプリッティング 4.フォワードプロキシ(nghttpx)へのHTTP/2のレスポンス [2805.766] send HEADERS frame <length=27, flags=0x04, stream_id=5> ; END_HEADERS (padlen=0) ; First response header :status: 302 content-type: text/html; charset=utf-8 location: http://www.yahoo.co.jp content-length: 0 via: 1.1 nghttpx [2805.766] send DATA frame <length=0, flags=0x01, stream_id=5> ; END_STREAM ※20015/6/27に内容を追加してます。 レスポンスは、HEADERSフレームとDATAフレームのみで、DATAフレームの サイズも0となっている。
- 51. ② レスポンススプリッティング レスポンススプリッティングした「HTTP/1.1 200 OK」のレスポンス自体は 認識されずに、破棄されていると思われる。 ※20015/6/27に内容を追加してます。 Nghttpxを介すことで、レスポンススプリッティングされる可能性は減る と思うが、実装状況にも依存すると思われるため、HTTP/2だからセキュア になるということではないと思う。
- 52. まとめ
- 53. 大事なことなので2度言います。
- 54. 宣伝 7/26（日） に開催されるJULY TECH FESTAにて、 「フリーでできるセキュリティチェック」という タイトルにて、プレゼンをさせていただきます。 ”無料”のツールを利用して、ラクにセキュリティ チェックを行うためのノウハウをご紹介いたし ます。 インフラエンジニア、運用を担当されている エンジニア向けの内容となっています。 http://2015.techfesta.jp/
- 57. 参考資料 RFC7540 https://http2.github.io/http2-spec/ http://summerwind.jp/docs/rfc7540/ （日本語訳） RFC7541 http://www.rfc-editor.org/rfc/rfc7541.txt http://syucream.github.io/hpack-spec-ja/rfc7541-ja.html （日本語訳） HTTP/2 Frequently Asked Questions http://http2.info/faq.html#why-is-http2-multiplexed HTTP2 Advent Calendar 2014 http://qiita.com/advent-calendar/2014/http2 HTTP/2.0のインパクト https://www.janog.gr.jp/meeting/janog32/doc/janog32-http2.0-shimizu-01.pdf HTTP/2 入門 http://www.slideshare.net/techblogyahoo/http2-35029629 HTTP/2 Deep Dive: Priority & Server Push https://speakerdeck.com/summerwind/2-deep-dive-priority-and-server-push