指定すべきHTTPセキュリティヘッダーTop7と、そのデプロイ方法

HTTPレスポンスヘッダーはWebアプリケーションのセキュリティ改善の目的で使用されることがある。一般的には、数行のコードを追加することで完了する。

HTPヘッダーはテキストにエンコードされた、HTTPリクエストとレスポンスメッセージヘッダーの一部のフィールドである。HTTPクライTアントとサーバー両者に、コネクションの確立などのmetaデータをするようになっている。ここ数年で発表されたHTTPヘッダーがいくつかあり、これらのヘッダーを使用することでいくつかの攻撃を防ぐ助けになる。以下にそれらがどんなヘッダーで、どのようにアプリケーションに実装するか挙げる。

Content Security Policy

コンテンツセキュリティポリシー(CSP)は、Webアプリケーションに対する、XSS防止、クリックジャッキング、その他のコードインジェクション攻撃を防ぐことができる。CSPの実装の例としては、Websiteがロードする先のURL、信頼するソースからのプラグインコンテンツ、そして自分の管理配下にあるスクリプトのみの指定をすること。

Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com

詳細の設定として、CSPをDJangoで設定する場合はこちら、Rubyで実装する場合はこちらを参考になる。

CSPの設定や特徴についてはこちら。

Strict-Transport-Security

ストリクト・トランスポート・セキュリティ(HSTS)は、webアプリケーション上で、ブラウザに対して、アクセスがHTTPではなくHTTPSでされるべきと指示できる。 例えば、HTTPSにリダイレクトする前に、HTTPでえ接続されることを許可している場合、閲覧者は暗号化されていないサイトの方ににリダイレクトする前に操作することができる。これが、中間者攻撃(MTM attack)の可能性につながってしまう。 閲覧者のサイトとの最初のインタラクション際、ブラウザはそのホストのHSTS ポリシーの情報を持っていない、故に、最初はHTTPSではなく、HTTPSで起こってしまう。 解決するには、STSのための設定がされた、ブラウザがサイトのプレロードリストを持たせる。HSTSにはmax-ageという値を設定でき、通常websiteをHSTSリストにキャッシュされるよう十分に高い値が設定される。

HSTSヘッダーがドメインをHSTSリストに1年キャッシュしている例:

Strict-Transport-Security: max-age=31536000; 

メジャーなブラウザはHSTSヘッダーを現在サポートしている。ただし、オペラ Mini、IE11以前のもの以外。

ストリクト・トランスポート・セキュリティ(HSTS)についての詳細を知りたい方はこちら。

X-Frame-Options

HTTPのX-Frame-Option レスポンスヘッダーは、ブラウザーがページを<frame> <iframe>、<object>の中に表示することを許すかを示すために使用される。 サイトやアプリケーションはこれを使用して、コンテンツが他のサイトに埋め込まれないよう保証することで、クリックジャッキング攻撃を防ぐことができる。 X-Frame-Options をサポートしているブラウザーをユーザーが使用しているときのみに有効。

ヘッダーに”SAMEORIGIN” もしくは、”DENY”とセットするのがコモンプラクティスだ。

“SAMEORIGIN” は、ページは同じオリジンのページに含まれるページのフレーム内でのみ表示される。 ”DENY”は、サイト側の意図に関わらず、ページをフレーム内に表示することはできない。

下が1例である

X-Frame-Options: SAMEORIGIN 

X-XSS-Protection

HTTP X-XSS-Protection 応答ヘッダーは、IE/Chrome/Safari においてXSS攻撃を検知してした際に読み込むことを防止するものだ。最も適正な設定は以下だ。

X-XSS-Protection: 1; mode=block. 

これにより、XSS防御をOnにでき、ブラウザに対して、ユーザーのinputから怪しいスクリプトが挿入されることを防ぐように支持ができる。

IEとChromeはX-XSS-Protection ヘッダーが送られなかった場合、怪しいデータをデフォルトで検知す。なので、このヘッダーはCSP古いCSPをサポートしないブラウザに対して重要な設定になる。

X-Frame-Optionsヘッダーと同様、X-XSS Protection ヘッダーも非推奨になっていて、CSPの中のReflected-XSSとして将来実装される。しかし、X-XSS Protection ヘッダーも幅広くサポートできるので、今は設定する価値がある。

X-XSS Protectionについての詳細はこちら。

X-Content-Type-Options

X-Content-Type-Optionsヘッダーは、Content-Typeヘッダーの内容からファイルの種類を決定できないようにするもの。

サーバーによって使用され、Content-Type headersで指定されたMIMEに必ず沿うように指定できます。これにより、HTTPレスポンス全体を検査（sniffing）を防ぐことができる。 MIME sniffingはheader’s content type の値ではなく、サーバーのレスポンスがどのcontent typeになるか予想した値を信用していしまうことが原因で、スクリプトが実行されてしまう可能性がある。

これは、X-Content-Type-Optionsを、 以下のように、”nosniff” を設定することで回避できる。

X-Content-Type-Options: nosniff 

現在はIE, Chrome, Safariがこのヘッダーをサポートしている。 X-Content-Type-Optionsの詳細はこちら.

Cross-Origin Resource Sharing (CORS)

オリジン間リソース共有 (CORS)は、 追加の HTTP ヘッダーを使用し、ある1つのロケーションにて動作しているウェブアプリケーションに、異なるロケーションのサーバーにあるリソースへのアクセスを許可できる仕組み。 ウェブアプリケーションは、cross-origin HTTP リクエストを自分とは異なるオリジンにリソースをリクエストするときに発行する。

最近のブラウザでは、cross-origin HTTPリクエストのリスクの減少ため、 XMLHttpRequest や Fetch などの API コンテナーで CORS を使用します。

例えば、 https://www.templarbit.com があなたのサイトのデータやコンテンツに対するリクエストを許可するには以下のように設定する

Access-Control-Allow-Origin: https://www.templarbit.com

自分の管理下にない他サイトの許可を意図的に許したいということがない限り、ヘッダー関連のCORSの設定は何もしないことをおすすめする。何もCORSヘッダが設定されていないサイトは他のサイトからのリクエストは受け付けない。 Cross-Origin Resource Sharing (CORS)の詳細はこちら。

HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) は、ウェブクライアントに公開鍵暗号を特定のウェブサーバーに関連付ける。これにより、偽造された証明書による中間者攻撃を防ぐことができる。

ルート証明書もしくは、中間証明書解説をピンすることができる。 以下はfacebook.comのHPKPヘッダー例:

public-key-pins-report-only:max-age=500; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="q4PO2G2cbkZhZ82+JgmRUyGMoAeozA+BSXVXQWB8XWQ="; report-uri=http://reports.fb.com/hpkp/

現在、HPKPはFirefoxとChromeにのみ対応している。 HTTP Public Key Pinning (HPKP)の詳細はこちら。

HTTPセキュリティヘッダーへの理解が深まったと思う。 もしよかったら、Templarbitの[無料デモ]((https://www.templarbit.com/)に申し込んで、一緒にHTTPセキュリティヘッダー対応を始めてみてはいかがだろうか。