Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
もしWebセキュリティのエンジ
ニアがRFC7540の「HTTP/2ア
プリ」をWeb診断したら
略して「もしR」
自己紹介
Twitter: abend@number3to4
Webセキュリティエンジニア
宣伝
7/26(日) に開催されるJULY TECH FESTAにて、
「フリーでできるセキュリティチェック」という
タイトルにて、プレゼンをさせていただきます。
”無料”のツールを利用して、ラクにセキュリティ
チェックを行うためのノウハウをご...
HTTP/2って
HTTP(HyperperText Transfer Protocol)の最新バージョンにあたり、HTTP/1.1
から16年ぶりのアップデート。HTTP/2についてはRFC7540、関連するHPACKは
RFC7541でリリ...
nghttp2って
HTTP/2に対応したWebサーバ、Webクライアント、Proxy機能を有する。
通信内容の確認は、hexdumpオプションを指定することで確認することが可能。
https://nghttp2.org/
① 多重化
HTTP/1.Xでは、1つのTCPコネクションで1つのリクエストおよびレスポンスを
やりとりしていた。HTTP/2では、streamという概念により1つのTCPコネクション
で複数のリクエストおよびレスポンスをやりとりできるようなっ...
② バイナリメッセージ
HTTPフレームが新たに定義され、stream上でやりとりをする。
フレームタイプによってFrame Payloadのフォーマットが変わる。フレームヘッダ
は9byte。
フレームヘッダ
HEADERSフレーム
② バイナリメッセージ
リクエスト、レスポンスヘッダがバイナリベースとなっている。
Nghttpでアクセスした際のdump結果。赤枠箇所がリクエストのHEADERSフレーム。
② バイナリメッセージ
リクエストの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 5...
② バイナリメッセージ
リクエストの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 7...
③ ヘッダ圧縮(HPACK)
HTTP/2はヘッダ圧縮のためにHPACK(RFC7541)を採用しています。
ハフマン符号や静的テーブルと動的テーブルを用いて、圧縮しています。
Indexの場合、7bitの値がリクエスト・レスポンスヘッダのヘッ...
③ ヘッダ圧縮(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 ...
③ ヘッダ圧縮(HPACK)
bitにより、どういう意味なのか変わってくる。
Indexは事前に定義されたヘッダ名の
値をセットする。0x41の場合、Index
が1である:authorityを指す。
2byte目(緑箇所)は、上位bitがハフ...
③ ヘッダ圧縮(HPACK)
:authority:ヘッダの値は、赤箇所のbyte列(11byte分)になる。
このbyte列はハフマンエンコーディングされているため、このままでは
可視できるものではないので、ハフマンでコーディングを行う必要が...
③ ヘッダ圧縮(HPACK)
まずは、11byteを2進数に変換し、結合する。
RFC7541で定義されているテーブルから
戻してあげればいい。赤箇所の
「00001」は1を意味しており、白は9、
青は2を意味する。
これを繰り返すと「 192...
④ フロー制御
HTTP/2では1つのコネクションで複数のstreamが通信できる。複数のstreamが
一斉に大量の通信をはじめたら・・・。
俺、通信するっ!! じゃ、俺も俺も。 じゃ、俺も俺も。
誰も「どうぞ、どうぞ」を言わないと、重要な通...
④ フロー制御
ウィンドウサイズによるフロー制御が存在しており、優先度にも応じて通信
を行う。ただし、フロー制御の対象となるのは、DATAフレームのみ。
コネクションの使用可能なウィンドウサイズ:65535
Streamごとの使用可能なウィンド...
④ フロー制御
たとえば、237byteのデータをStreamIDが1のウィンドウサイズ127byteの設定
で通信した場合・・・
2. サーバが237byteのデータのうち、127byteをsend
クライアント
サーバ
コネクション ウィン...
④ フロー制御
4. サーバが残りの110byteをsend
クライアント
サーバ
コネクション ウィンドウサイズ:65408
StreamID:1 ウィンドウサイズ:127
3. クライアントがWINDOW_UPDATE(StreamID:1...
④ フロー制御
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はフレ...
④ フロー制御
WINDOW_UPDATEは、WINDOW_UPDATEフレームで実行されます。
00 00 04 08 00 00 00 00 0d 00 00 00 1f
WINDOW_UPDATEは、「コネクションに対して」と「Strea...
⑤ 優先度
各StreamがWindow Sizeの上限まで使い切ることがないように、Streamに対して
優先度(Wight)をつけて、その割合に応じて通信を行う。
値は1から256の整数で指定することが可能です。Defaultは16です。
...
⑤ 優先度
優先度の指定は、PRIORITYフレームを用いて行うことが可能です。
00 00 05 02 00 00 00 00 03 00 00 00 00 c8
赤箇所はフレームヘッダ。
青箇所は依存するStreamIDを指定し、この場合は...
⑥ 依存関係
各Streamは、他のStreamと依存関係を持ちます。
ルートにはStreamID:0がセットされ、依存されるStreamIDのほうが優先して
リソースの割り当てを行われます。
StreamID:0
StreamID:1 Str...
⑦ Server Push
通常、クライアントからリクエストを送信し、それに対してレスポンスを
返すが、Server Pushはクライアントからのリクエストを受けずにサーバが
レスポンスを返す。
クライアント サーバ
リクエスト
レスポンス
S...
⑦ Server Push
Server Pushするために、サーバからクライアントにPUSH_PROMISEフレームで
通知しておく必要があります。
Promissed Stream IDは、Server PushされStreamIDがセット...
⑦ Server Push
Server Pushするために、サーバからクライアントにPUSH_PROMISEフレームで
通知しておく必要があります。
00 00 18 05 04 00 00 00 0d 00 00 00 02 82 04 8...
Web診断って
Webアプリケーションの脆弱性の有無を検査することをWeb診断としています。
Web診断では、基本的にProxyツールを用いて行います。
Proxyツールで検査パターンを付加してリクエストし、そのレスポンスの内容
によって脆弱性...
Web診断って
Proxyツールを使う理由は、ブラウザで操作できる内容が限られているためです。
都道府県:
性別: 男 女
東京都 (ブラウザ上で)入力形式が固定化されている
場合にProxyツールを用いて、入力値を変更します。
Web診断って
ProxyツールのひとつにBurp Suiteがあります。
Javaで動作し、一部の機能は有償版のみとなりますが、基本的にフリーで使える
ツールです。
リクエストをInterceptして
変更することで、ブラウザ
では変更できな...
結論
HTTP/2のアプリに対して、Burp Suiteでアクセスしてみた。
Burp Suiteは、HTTP/2に対応していないのでできなかった。
じゃあ、どうすんの
ソースとか見てたら、nghttpxというProxy機能があることに気づいたので
これを活用することに。
クライアント Proxyツール
HTTP/1.1 HTTP/2
nghttpx
HTTP/1.1
こうすれば既存の仕組み...
試してみた
Nghttp2をProxyとして動作させることで、Burp Suiteでもアクセスできるよう
になった。
nghttpx --client -f0.0.0.0,8080 –b[HTTP2サーバのIP],443 -k -o -LINFO
これで脆弱性見つけられる
nghttp2には、アプリケーションサーバとしての機能がないため、以下、構成で
診断が行えるか確認することに。
クライアント Proxyツール
HTTP/1.1
HTTP/2
nghttpx
HTTP/1.1
Webア...
当然見つかる
HTTP/1.Xと同様に何も変わることなく、XSSを見つけることができた。
じゃあ、すべての脆弱性も?
HTTPヘッダインジェクションはどうなるのだろうか。
脆弱なサイト一般利用者
Proxy Server
攻撃者
キャッシュが
汚染される
メールやページ
書込みによるリンク
XSSと同じ被害
なぜ、HTTPヘッダインジェクションなのか
HTTP/2だとレスポンスヘッダ(リクエストヘッダもだけど)はバイナリになる
ため、以下の行為ができないのではないかと考えた。
① 任意のヘッダ挿入
勝手にSet-Cookieとセットされる可能性があ...
なぜ、HTTPヘッダインジェクションなのか
検証するにあたり、脆弱なソースを用意した。
※オープンリダイレクタも存在します。
#!/usr/bin/perl
use utf8;
use strict;
use CGI;
my $cgi = ne...
① 任意のヘッダ挿入
HTTP/2の場合、HPACKを用いてヘッダの圧縮を行っているため、脆弱性を悪用
してヘッダにインジェクトしようとしても、ただの文字列として処理されて
しまうのではないかと推測した。
<レスポンス>
HTTP/1.1 30...
① 任意のヘッダ挿入
なぜこうなったのか。
<推測です>
今回の構成の場合、バックエンドサーバである脆弱サーバで改行が評価され
ヘッダに挿入されたレスポンスをそのままHTTP/2へ返すために、HTTP/2には
まったく関係がなく、とめることはで...
② レスポンススプリッティング
HTTP/2では、レスポンスヘッダとレスポンスボディはそれぞれ違うフレーム
として送信されるため、レスポンスを分割したとしてもキャッシュされない
のではないかと推測。
<リクエスト>
GET http://192...
② レスポンススプリッティング
結果は・・・。
HTTP/1.0 302 Moved Temporarily
Date: Thu, 25 Jun 2015 16:57:28 GMT
Location: http://www.yahoo.co.j...
② レスポンススプリッティング
※20015/6/27に内容を追加してます。
意図した通りのレスポンスになっていないため、pythonで強制的にレスポンス
スプリッティングした結果がHTTP/2(nghttpx)ではどのように評価されるか検証
...
② レスポンススプリッティング
Pythonサーバにアクセスすると以下のレスポンスが常に返される。
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: http...
② レスポンススプリッティング
ブラウザ → Burp Suite → フォワードプロキシ(nghttpx) →
リバースプロキシ(nghttpx) → Pythonサーバという順でアクセスした結果。
HTTP/1.1 302 Found
Da...
② レスポンススプリッティング
リバースプロキシ(nghttpx)のログは、大きく4つのポイントがあります。
1. フォワードプロキシ(nghttpx)からのHTTP/2のGETリクエスト
2. PythonサーバへのHTTP/1.1のGETリ...
② レスポンススプリッティング
1.フォワードプロキシ(nghttpx)からのHTTP/2のGETリクエスト
:method: GET
:scheme: http
:authority: リバースプロキシのIP
:path: /
user-ag...
② レスポンススプリッティング
2. PythonサーバへのHTTP/1.1のGETリクエスト
GET http://リバースプロキシのIP/ HTTP/1.1
Host:リバースプロキシのIP
User-Agent: Mozilla/5.0 ...
② レスポンススプリッティング
3. PythonサーバからのHTTP/1.1のレスポンス
:status: 302
content-type: text/html; charset=utf-8
location: http://www.yah...
② レスポンススプリッティング
4.フォワードプロキシ(nghttpx)へのHTTP/2のレスポンス
[2805.766] send HEADERS frame <length=27, flags=0x04, stream_id=5>
; EN...
② レスポンススプリッティング
レスポンススプリッティングした「HTTP/1.1 200 OK」のレスポンス自体は
認識されずに、破棄されていると思われる。
※20015/6/27に内容を追加してます。
Nghttpxを介すことで、レスポンスス...
まとめ
大事なことなので2度言います。
宣伝
7/26(日) に開催されるJULY TECH FESTAにて、
「フリーでできるセキュリティチェック」という
タイトルにて、プレゼンをさせていただきます。
”無料”のツールを利用して、ラクにセキュリティ
チェックを行うためのノウハウをご...
・HTTP/2は以前のバージョンと比較すると複雑になり、telnetとかで試すことが
できなくなった。
まとめ
・HTTP/2を使えば安全というわけではなく、Webアプリケーションはこれまで
通りセキュリティ対策はとる必要はある。
・hexdu...
ちなみに
前から疑問だったのだが・・・。
HTTP/2コネクションの初期設定確立のために、24byteの固定されたコネクション
プリフェイスをサーバが送信する。
「HTTP/2.0」だと!?
正式名称は「HTTP/2」or「HTTP2」じゃない...
参考資料
RFC7540
https://http2.github.io/http2-spec/
http://summerwind.jp/docs/rfc7540/ (日本語訳)
RFC7541
http://www.rfc-editor.o...
Upcoming SlideShare
Loading in …5
×

もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら

6,904 views

Published on

もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら

Published in: Engineering
  • Be the first to comment

もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら

  1. 1. もしWebセキュリティのエンジ ニアがRFC7540の「HTTP/2ア プリ」をWeb診断したら 略して「もしR」
  2. 2. 自己紹介 Twitter: abend@number3to4 Webセキュリティエンジニア
  3. 3. 宣伝 7/26(日) に開催されるJULY TECH FESTAにて、 「フリーでできるセキュリティチェック」という タイトルにて、プレゼンをさせていただきます。 ”無料”のツールを利用して、ラクにセキュリティ チェックを行うためのノウハウをご紹介いたし ます。 インフラエンジニア、運用を担当されている エンジニア向けの内容となっています。 http://2015.techfesta.jp/
  4. 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
  5. 5. nghttp2って HTTP/2に対応したWebサーバ、Webクライアント、Proxy機能を有する。 通信内容の確認は、hexdumpオプションを指定することで確認することが可能。 https://nghttp2.org/
  6. 6. ① 多重化 HTTP/1.Xでは、1つのTCPコネクションで1つのリクエストおよびレスポンスを やりとりしていた。HTTP/2では、streamという概念により1つのTCPコネクション で複数のリクエストおよびレスポンスをやりとりできるようなった。 stream Stream_id:偶数 Stream_id:奇数 Stream_id:0 クライアント サーバ StreamID 0:コネクション制御用 奇数:クライアントが開始 偶数:サーバが開始 コネクション
  7. 7. ② バイナリメッセージ HTTPフレームが新たに定義され、stream上でやりとりをする。 フレームタイプによってFrame Payloadのフォーマットが変わる。フレームヘッダ は9byte。 フレームヘッダ HEADERSフレーム
  8. 8. ② バイナリメッセージ リクエスト、レスポンスヘッダがバイナリベースとなっている。 Nghttpでアクセスした際のdump結果。赤枠箇所がリクエストのHEADERSフレーム。
  9. 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. 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となる。
  11. 11. ③ ヘッダ圧縮(HPACK) HTTP/2はヘッダ圧縮のためにHPACK(RFC7541)を採用しています。 ハフマン符号や静的テーブルと動的テーブルを用いて、圧縮しています。 Indexの場合、7bitの値がリクエスト・レスポンスヘッダのヘッダ名、値を 指している。「:」から始まるヘッダ名はHTTP/2のために作られた疑似 ヘッダフィールドです。
  12. 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. 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. 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. 15. ③ ヘッダ圧縮(HPACK) まずは、11byteを2進数に変換し、結合する。 RFC7541で定義されているテーブルから 戻してあげればいい。赤箇所の 「00001」は1を意味しており、白は9、 青は2を意味する。 これを繰り返すと「 192.168.159.133 」 となる。緑箇所は余りで1でpaddingされ ている。 00001011111000100101110000101110001111001011100001011011011111010111000010 11001011001111
  16. 16. ④ フロー制御 HTTP/2では1つのコネクションで複数のstreamが通信できる。複数のstreamが 一斉に大量の通信をはじめたら・・・。 俺、通信するっ!! じゃ、俺も俺も。 じゃ、俺も俺も。 誰も「どうぞ、どうぞ」を言わないと、重要な通信が行えなくなってしまう。 どうぞ、そうぞ どうぞ、そうぞ えっ!?
  17. 17. ④ フロー制御 ウィンドウサイズによるフロー制御が存在しており、優先度にも応じて通信 を行う。ただし、フロー制御の対象となるのは、DATAフレームのみ。 コネクションの使用可能なウィンドウサイズ:65535 Streamごとの使用可能なウィンドウサイズ:65535 使用可能な量を使い切ってしまった場合、受信者側からWINDOW_UPDATE を受け取ることで、使用可能な量を追加することができる。 クライアント サーバ
  18. 18. ④ フロー制御 たとえば、237byteのデータをStreamIDが1のウィンドウサイズ127byteの設定 で通信した場合・・・ 2. サーバが237byteのデータのうち、127byteをsend クライアント サーバ コネクション ウィンドウサイズ:65535 StreamID:1 ウィンドウサイズ:127 1. クライアントがInitial Window Sizeを127byteへ変更をsend コネクション ウィンドウサイズ:65535 StreamID :1 ウィンドウサイズ:127 クライアント サーバ
  19. 19. ④ フロー制御 4. サーバが残りの110byteをsend クライアント サーバ コネクション ウィンドウサイズ:65408 StreamID:1 ウィンドウサイズ:127 3. クライアントがWINDOW_UPDATE(StreamID:1)127byteをsend コネクション ウィンドウサイズ: 65408 StreamID:1 ウィンドウサイズ:0 クライアント サーバ
  20. 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. 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. 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. 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が優先度となる。
  24. 24. ⑥ 依存関係 各Streamは、他のStreamと依存関係を持ちます。 ルートにはStreamID:0がセットされ、依存されるStreamIDのほうが優先して リソースの割り当てを行われます。 StreamID:0 StreamID:1 StreamID:3 StreamID:5 StreamID:7
  25. 25. ⑦ Server Push 通常、クライアントからリクエストを送信し、それに対してレスポンスを 返すが、Server Pushはクライアントからのリクエストを受けずにサーバが レスポンスを返す。 クライアント サーバ リクエスト レスポンス Server Pushのレスポンスは、クライアントが送信すると予定されるリクエスト とデータを返します。データはクライアントでキャッシュされます。
  26. 26. ⑦ Server Push Server Pushするために、サーバからクライアントにPUSH_PROMISEフレームで 通知しておく必要があります。 Promissed Stream IDは、Server PushされStreamIDがセットされる。サーバが 起点となるため、この値は偶数となる。また、Header Block Fragmentには 予定されるリクエストをセットされます。
  27. 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フレーム と同様にデコード可能。
  28. 28. Web診断って Webアプリケーションの脆弱性の有無を検査することをWeb診断としています。 Web診断では、基本的にProxyツールを用いて行います。 Proxyツールで検査パターンを付加してリクエストし、そのレスポンスの内容 によって脆弱性の有無を判断します。 リクエスト Webサーバクライアント 検査パターンを 付加する。 Proxyツール レスポンス
  29. 29. Web診断って Proxyツールを使う理由は、ブラウザで操作できる内容が限られているためです。 都道府県: 性別: 男 女 東京都 (ブラウザ上で)入力形式が固定化されている 場合にProxyツールを用いて、入力値を変更します。
  30. 30. Web診断って ProxyツールのひとつにBurp Suiteがあります。 Javaで動作し、一部の機能は有償版のみとなりますが、基本的にフリーで使える ツールです。 リクエストをInterceptして 変更することで、ブラウザ では変更できないパラメー タも変更可能となります。
  31. 31. 結論 HTTP/2のアプリに対して、Burp Suiteでアクセスしてみた。 Burp Suiteは、HTTP/2に対応していないのでできなかった。
  32. 32. じゃあ、どうすんの ソースとか見てたら、nghttpxというProxy機能があることに気づいたので これを活用することに。 クライアント Proxyツール HTTP/1.1 HTTP/2 nghttpx HTTP/1.1 こうすれば既存の仕組みのまま、HTTP/2アプリにも接続可能。 HTTP/2アプリ
  33. 33. 試してみた Nghttp2をProxyとして動作させることで、Burp Suiteでもアクセスできるよう になった。 nghttpx --client -f0.0.0.0,8080 –b[HTTP2サーバのIP],443 -k -o -LINFO
  34. 34. これで脆弱性見つけられる nghttp2には、アプリケーションサーバとしての機能がないため、以下、構成で 診断が行えるか確認することに。 クライアント Proxyツール HTTP/1.1 HTTP/2 nghttpx HTTP/1.1 Webアプリ HTTP/1.1 nghttpx
  35. 35. 当然見つかる HTTP/1.Xと同様に何も変わることなく、XSSを見つけることができた。
  36. 36. じゃあ、すべての脆弱性も? HTTPヘッダインジェクションはどうなるのだろうか。 脆弱なサイト一般利用者 Proxy Server 攻撃者 キャッシュが 汚染される メールやページ 書込みによるリンク XSSと同じ被害
  37. 37. なぜ、HTTPヘッダインジェクションなのか HTTP/2だとレスポンスヘッダ(リクエストヘッダもだけど)はバイナリになる ため、以下の行為ができないのではないかと考えた。 ① 任意のヘッダ挿入 勝手にSet-Cookieとセットされる可能性がある。 ② レスポンススプリッティング Proxyサーバに不正な内容をキャッシュさせられる可能性がある。
  38. 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. 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 以下略 脆弱だった。。。
  40. 40. ① 任意のヘッダ挿入 なぜこうなったのか。 <推測です> 今回の構成の場合、バックエンドサーバである脆弱サーバで改行が評価され ヘッダに挿入されたレスポンスをそのままHTTP/2へ返すために、HTTP/2には まったく関係がなく、とめることはできないのではないかと推測しています。
  41. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 51. ② レスポンススプリッティング レスポンススプリッティングした「HTTP/1.1 200 OK」のレスポンス自体は 認識されずに、破棄されていると思われる。 ※20015/6/27に内容を追加してます。 Nghttpxを介すことで、レスポンススプリッティングされる可能性は減る と思うが、実装状況にも依存すると思われるため、HTTP/2だからセキュア になるということではないと思う。
  52. 52. まとめ
  53. 53. 大事なことなので2度言います。
  54. 54. 宣伝 7/26(日) に開催されるJULY TECH FESTAにて、 「フリーでできるセキュリティチェック」という タイトルにて、プレゼンをさせていただきます。 ”無料”のツールを利用して、ラクにセキュリティ チェックを行うためのノウハウをご紹介いたし ます。 インフラエンジニア、運用を担当されている エンジニア向けの内容となっています。 http://2015.techfesta.jp/
  55. 55. ・HTTP/2は以前のバージョンと比較すると複雑になり、telnetとかで試すことが できなくなった。 まとめ ・HTTP/2を使えば安全というわけではなく、Webアプリケーションはこれまで 通りセキュリティ対策はとる必要はある。 ・hexdumpした結果を何度も見ていると、だんだんフレームが見えてくる。
  56. 56. ちなみに 前から疑問だったのだが・・・。 HTTP/2コネクションの初期設定確立のために、24byteの固定されたコネクション プリフェイスをサーバが送信する。 「HTTP/2.0」だと!? 正式名称は「HTTP/2」or「HTTP2」じゃないのか。って、前から??でした。
  57. 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

×