セキュリティの現場から from バラクーダラボ(194) Googleの「HTTPS Everywhere」がWebアプリケーションセキュリティに与える影響

Googleは先日、HTTPSサイトの検索順位を優遇する方針を発表しました。これによって、インターネット全体のセキュリティ向上が期待されており、たとえば、人気サイトでは平文のパスワードを送信できなくなります。ご存知の通り、HTTPSは中間者（MITM）攻撃への有効な対策です。

例えて言うと、HTTPSは武装車両のようなものであり、A地点からB地点まで乗客を安全に輸送します。また、乗客を正しい目的地へと確実に送り届けることもできます。ただし、車両の積み荷が何かという点については保証がありません。つまり、積み荷が実爆弾や変装した敵である可能性もあるわけです。

敵は、この点を悪用して攻撃を仕掛けてきます。

従来型の境界セキュリティの弱点を突くHTTPS

映画『イングロリアス・バスターズ』では、重装備のドイツ軍基地を突破するために、ブラッド・ピットと彼が率いる部隊はドイツ兵に変装します。

敵の正体を見破ることができなければ、セキュリティ対策は役に立ちません。HTTPSも、境界セキュリティにおいてこれと同様の難問に直面しているといえます。データが完全に暗号化されていると、ファイアウォールやIDS/IPSといった従来型の境界セキュリティソリューションでは不正を見破ることができません。その結果、敵（攻撃者）は、サーバやアプリケーションを標的とした攻撃をHTTPS内に簡単に紛れ込ませることができます。

これは、両方向の攻撃に悪用されます。つまり、データセンター内のサーバからの応答にデータ流出を引き起こす攻撃を仕掛け、さらには、ユーザや境界セキュリティを標的にした攻撃を外部から気付かれないように実行できるわけです。HTTPSを使用するとブラウザのアドレスバーに鍵マークが表示されますが、これはサーバのID認証の確認に過ぎず、水飲み場型攻撃を防御することはできません。

しかしこの鍵マークは、エンドポイント、Webサーバ、サイトにアクセスするユーザに誤った認識を与えてしまうことがあります。WebマスターがHTTPからHTTPSに移行する場合に非プロキシ型のソリューションを導入すると、セキュリティの保護レベルが低下してしまう可能性があります。

HTTPSのセキュリティ強化と拡張に役立つアプリケーションプロキシ

上記はチェックポイントセキュリティの例ですが、チェックポイントセキュリティにブラックリスト（アクセスを拒否する対象）と、可能であればホワイトリスト（写真付きの従業員リストなど）を設定する必要があります。

この方法は、Barracuda Web Application Firewallのようなアプリケーションプロキシが実行する操作と類似しています。Webアプリケーションのセキュリティを確保したいのであれば、HTTPSの内部をチェックして悪意のあるデータの侵入を防ぐ必要があり、この機能を備えたアプリケーションプロキシベースのソリューションが必要になります。これを可能にするのがSSLオフロードです。プロキシがHTTPSトラフィックの復号化と検査を行い、保護サーバとHTTPを介して通信します（必要に応じて、データストリームの再暗号化が可能です）。

これにより、暗号化されたトラフィックに悪意のある攻撃やデータ流出が含まれていないか、完全にチェックすることができます。

Barracuda Web Application Firewallのように、アプリケーションプロキシを使用してSSLオフロードを行うソリューションは、他にも多数あります。

コンテンツの再書き込み：最新のアプリケーションセキュリティは、レガシーのWebアプリケーションの再書き込みをその場で要求するものが数多く存在します。たとえば、HTTP Strict Transport Security（HSTS）ポリシーとクリックジャック攻撃回避に使用する応答ヘッダのインジェクション、CSRF攻撃向けのランダムトークンのインジェクション、Cookieの暗号化などがあります。

脆弱なSSLスタックのセキュリティ強化：往々にして、古いWebサーバは最新のSSL拡張機能をサポートしません。また、古いSSLスタックには脆弱性が無数に存在する可能性があります。マルチベンダサーバでSSLをアップグレードする作業は時間がかかり、それだけ脅威にさらされる危険性も高くなります。詳細については、こちらをご覧ください。

アプリケーションデリバリにかかる時間を短縮：セキュリティだけでなく、アプリケーションデリバリ機能でもアプリケーションプロキシのSSLオフロードが効果を発揮します。たとえば、コンテンツのキャッシングと圧縮では、キャッシングや圧縮の前にプロキシがHTTPS内部をチェックする必要があります。

保護サーバの負荷軽減：HTTPSでは、特に2048ビット鍵を使用する場合、これまでよりも高い処理能力が必要とされます。ハードウェア仕様が不十分な古いサーバの場合、HTTPでは問題がなくても、HTTPSの負荷に対応しきれないケースがあります。アプリケーションプロキシへのSSLオフロードは、すべての演算処理をプロキシ自体にオフロードすることが可能になります。

将来もセキュリティを実現できるHTTPS：PFS（Perfect Forward Secrecy）暗号化に対応していない環境では、もしも鍵が盗まれた場合、今日キャプチャされたHTTPSトラフィックスが、将来復号化されてしまう危険があります。PFSはこのような問題を未然に防ぐことができます。ただし、PFSを使用する環境では、IPS／IDSのようなスニッファデバイスをベースにしたセキュリティやスパンポートをベースにしたアプリケーションプロキシは、PFS通信を復号化できないので役に立ちません。

このように、サーバでセキュリティ侵害のスニッフィングを行う場合、HTTPはその効果を発揮できなくなります。検索順位の下落（「このサイトはマルウェアに感染しています」という警告メッセージ）は、ビジネスに壊滅的な影響を与えるおそれがあるので、十分な注意が必要です。

※本内容はBarracuda Product Blog 2014年9月3日What does Google’s “HTTPS Everywhere” mean for Web Application Securityを翻訳したものです