WAFの機能とOPENSSLの脆弱性
WAFも調べてみると、種類があり、物によってできることに差異があったので、ざっくりまとめておく。
WAFの歴史
WAFは従来のレイヤー２，３を守るファイアウォールとは異なり、レイヤー７（アプリケーション層）を守るために作られた。2008年当初はブラックリスト型が多く、以前に攻撃のあった内容しか防がれなかったが、近年はホワイトリスト型のWAFも登場し、HTTPS通信もチェックできるようになった。
WAFは何するもの？
HTTP通信の中身をチェックするレイヤー７を監視する機器。また、WAFにも種類があり、ブリッジ型のWAFはネットワークに透過的に作用するため、 SSLで暗号化された通信は見ることができず、HTTPSの内容をチェックすることができません。
対してプロキシ型のWAFはいわゆるリバースプロキシとして働くため、やや設置環境に影響を与えます。自身がSSLでのリクエストを 待ち受けた後に内容のチェックを行い、結果としてHTTPSにも対応できます。 このため、通常、WAFではプロキシ型が採用されています。
WAFの検査項目
HTTPリクエストの検査項目
HTTPレスポンスの検査項目
apacheにもフィルタリング機能はある
mod_securityを有効にして、下記のようなURLにアクセスしようとすると、きちんとブロックしてくれます。（Forbiddenの画面に飛ぶ）
https://centos7.co.jp/?a=\<script\>alert(0)\</script\>
apacheのモジュールmod_securityには下記機能がある。
- hiddenやCookieなど個々の特定のパラメータおよび値に対してフィルタリングを行うことができる
- 通常のWebサーバでは記録されないPOSTのログを含め、詳細なログを取得することができます。
- HTTPSのリクエストもフィルタリングできます。
OPENSSLの脆弱性
opensslはapacheやnginxで採用されているオープンソースツールです。2014年に見つかった脆弱性では、heartbeatパケットを送信することで、ペイロードのレスポンスに.htacessやhttpd.confの内容が返されてしまうという事態が起こりました。
heartbeatパケットは64KBだと偽って1KBのデータをサーバに送ります。サーバは64KB要求されたと勘違いして、64KBクライアントに返してしまいます。ちなみに不足分の63KB分は適当にメモリから取って返してしまうので、もしSession Keyとかを返してしまってそれが露見したら、
TSL/SSLで暗号化した内容が筒抜けになるので、あるユーザの情報はすべて盗まれてしまいます。
この話の怖い所は2014年に問題になるまで、その信頼性の高さからAMAZONやYAHOOや銀行業務でずっとTLS/SSLが使われていてずっと情報が漏れ続けていたであろうこと。
Heartbleedによる脆弱性があるのは、OpenSSLのバージョン「1.0.1」から「1.0.1f」までとなっており、サイト管理者はこれをバージョン「1.0.1g」にアップデートすることなどで脆弱性を修正できる。
ちなみにSSL通信に利用するメモリにはユーザのセッションIDや公開鍵、サーバのSSL証明書の秘密鍵など危ないデータが含まれている。
