【情報処理安全確保支援士】HTTPに関するセキュリティリスクについて（その３）：HTTPメッセージのレスポンスヘッダによるセキュリティ対策

 HTTPに関するセキュリティリスクについて（その３）

前回の記事「GETとPOSTの違いとセキュリティ上の注意点」

HTTPメッセージのレスポンスヘッダにはサーバから返信したページの表示や挙動を制御できるものがありブラウザが対応しているヘッダであればユーザーに対してセキュリティ機能を強化することができます。

セキュリティを強化するレスポンスヘッダ一覧

レスポンスヘッダはWebサーバソフトのApatchやnginxなどで常に出力するように設定できます。

システムに影響がないことを確認できればWebサーバソフト側で出力することで抜けがなく対応することができます。

 

上記のヘッダだけ簡単に説明します。

・X-Frame-Options

ブラウザがframeやiframeでページを表示することの可否を指定します。

 

DENY（拒否）：

ページをフレーム内に表示することはできません

SAMEORIGIN（同一生成元のみ）：

ページ自体と同じオリジンのフレーム内でのみ表示される。

 

他社のWebプラットフォーム上で自社のコンテンツを表示させる場合などは、プラットフォーム側が安全な表示ができるAPIを用意していることがあります。

 

攻撃者が用意したフレーム内でページを表示させることでクリックジャッキングなどの手口で利用者が意図しない操作を行わせることが可能になってしまうので、入力フォームや確定処理のあるページではX-Frame-Optionsを指定したほうが良いでしょう。

・X-Content-Type-Options

レスポンスデータを作成する際、Content-TypeヘッダにMIMEタイプを必ず指定していると思いますが、Content-Typeヘッダが欠落しているか、Content-Typeヘッダに指定されたMIMEタイプと送信されたデータのMIMEタイプが違う場合にブラウザはMIMEスニッフィングを行います。

例えばSafariのMIMEスニッフィングではURLのファイルの拡張子をみてMIMEタイプを判断し実行します。これにより悪意のあるJavaScriptがPNGなどの画像に偽装された場合、JavaScriptファイルが実行される可能性があります。

ここで、MIMEスニッフィングによる脆弱性をついた攻撃方法について簡単に説明します。

①     攻撃者が悪意のあるJavaScriptを含んだPDFや画像を用意しサイトAの公開ディレクトリにアップロードする

②     サイトAではPDFや画像のContent-typeには「application/pdf」「image/png」を指定しているが、「X-Content-Type-Options」は指定していない

③     攻撃者がアップロードしたファイルのダウンロードURLをコピーする

（例：https//~/download.php?file=1234.pdf）※1234は乱数

④     攻撃者がURLに細工をする

（例：https//~/download.php/a.html?file=1234.pdf）

⑤     攻撃者が工夫したURLを他サイトの掲示板に張り付けアクセスを誘導する

⑥     受信したdownload.phpは「/a.html」の部分をパラメータとして受け取るが通常通りPDFファイルを送信する

⑦     利用者が使用しているブラウザのMIMEスニッフィングがURLからファイルの拡張子を識別して実行するものだと、ダウンロードしたPDFをhtmlとして実行してしまい攻撃者が仕込んだJavaScriptが利用者のブラウザ上で起動してしまう

この問題を解決するために、「X-Content-Type-Options:nosniff」をレスポンスヘッダで出力することで、ブラウザはMIMEスニッフィングを行わずにレスポンスヘッダにあるContent-Typeを常に優先するようになります。

 

Content-Typeが指定されずにデフォルト値（PHPではhtml）を返していてMIMEスニッフィングにより画像などが表示されているページでは、「X-Content-Type-Options:nosniff」を返してしまうと表示されなくなってしまうのでWebアプリケーション側の対応を行った後に指定するようにした方が良いでしょう。

・X-XSS-Protection

XSS：クロスサイトスクリプティング

 

ブラウザによってはXSSフィルターという機能が実装されており、ブラウザが反射型XSS攻撃を検知するとページの読み込みを停止するものです。

この機能はデフォルトで有効ですが利用者によって無効化されていることもあり、X-XSS-Protectionヘッダを返すことで該当ページの設定を有効化することができます。

 

しかし、この機能を悪用する手口も出てきたことから、現時点ではXSSフィルター機能を廃止したブラウザもあります。

今後はContent-Security-Policyで保護されることになります。

・Content-Security-Policy（CSP）

Content Security Policyは画像、動画、JavaScript、CSSなどのアセットの読み込みや、<iframe>読み込み、XML-HttpRequestやFetchによるリソースの読み込みをポリシーの宣言によって制限できるものです。インラインのCSSやJavaScriptの実行も制限できます。

 

これらの指定はディレクティブと呼ばれるキーバリュー形式のセット（値＝ソースという）を使ってホワイトリストとして開発者が設定することになります。

指定が無い項目については基本的に「default-src」ディレクティブの設定が参照されるので「default-src ‘self’」であれば同一オリジンのみ許可、「default-src ‘none‘」であれば全て拒否になります。

 HTTPS接続に限定したい場合は「default-src https://*:443」などのように指定します。

 

設定できるディレクティブ表（一部）

Content-Security-Policy をHTTPレスポンスヘッダまたは <meta> 要素で設定すると、ポリシーに抵触したリソースの読み込みや実行がすべてブロックされます。ポリシーの宣言が間違っていると、最低限必要なCSSやJavaScriptが実行されず、ウェブサイトそのものが利用できないということになりかねません。

 

Content-Security-Policyを使用することでクロスサイトスクリプティングなどの攻撃に対する問題を大幅に軽減することができます。

その反面、システムにあったポリシーを設定するための難易度が高くデバッグ作業などのコストも多くかかるため導入しているサイトはまだ少ないのが現状です。

XSS攻撃による被害が多くなっていることから、XSSへの効果が大きいCSPの設定を導入していくことが安全なWebアプリケーションを作るために推奨されています。

 

とはいえ、すでに運用中のWebサービスに適用するのはリスクが高いので、Content-Security-Policyの代わりにContent-Security-Policy -Report-Onlyを利用することでポリシーに違反した際にはブロックは行わず、指定されたURLに内容を送信することもできます。

既存システムなどに導入する際はこちらを活用して設定を調整することにも利用できます。

 

今後、個人情報を多く扱うようなWebアプリケーションをリリースする際には脆弱性検査で必須の項目となる可能性もあるため要件定義でクライアントとセキュリティポリシーについて確認しておくことが大事になります。

・Strict-Transport-Security（HSTS）

レスポンスヘッダにHSTSが指定されたHTTPのサイトへアクセスすると次回以降の一定期間はWebブラウザによりHTTPS接続を強制されます。

HSTSを使わずにサイトへのアクセスをHTTPSに限定するための実装方法として、HTTPアクセスをHTTPSにリダイレクト（301や307）することが行われますが、この際、中間者攻撃によりHTTPSアクセスをHTTPにダウングレードされるリスクがあります。

HSTSではWebブラウザが強制的にHTTPSでの接続に置き換えてアクセスすることでこの問題を解決します。

Strict-Transport-Security（HSTS）で指定できるパラメータ表

開発にあたって下記内容に注意する必要があります。

 

u  max-age で指定された期間はHSTSの指定を解除することができない

u  HSTSヘッダを受け取るたびに期間は再設定される

u  サブドメインにもHSTSポリシーを適用した場合はSSL化していないHTTPページにはアクセスできなくなる

u  HSTS Preloadリストへの登録・削除の反映は数か月かかることがある

 

HSTSの期限を最初は数分にして設定内容が正しいことを確認しながら段階的に伸ばしていくことが推奨されています。

 

HSTSの設定をしていても、最初の１回目はHTTPで通信がおこなわれるため安全ではありません。そこで、最初の１回目からHTTPS通信を行えるようにHSTS Preloadという仕組みをGoogle が推進し提供しています。

 

HSTS Preload は主要なWebブラウザ（IE11、Edge、chrome、safari、Firefox）で対応されています。

https://caniuse.com/stricttransportsecurity（対応表リンク）

◇      HSTS Preload リストが使用されるまでの流れ

①      WebサービスをHSTS Preloadリストへの登録条件を満たすように設定する（条件は別途）

②      ドメインの管理者がWebサイト上でHSTS Preload リストへの登録申請をする

（https://hstspreload.org/）

③      数週間～１か月ぐらいでドメインのステータスが「preloaded」になる

④      Webブラウザを最新版に更新してアクセスすると最初の１回目もHTTPSで接続される

 

 

HSTS PreloadリストはWebブラウザのソースにハードコーディングされます。

そのためリストから削除することは簡単ではなくchromeアップデートでユーザーに届くまでに数か月かかり、他のブラウザについては保証されていません。ただし、削除をリクエストする削除フォームは用意されています。

 

 

HSTS Preloadリスト登録条件

◆      有効な証明書を提供する

◆      同じホストでHTTPからHTTPSにリダイレクトする

◆      全てのサブドメインにHTTPS経由でサービスを提供する

◆      基本ドメインのHSTSヘッダは下記条件を満たしている事

・max-age は１年以上（31536000秒）

・includeSubDomainsディレクティブを指定する

・preloadディレクティブを指定する

・HTTPSサイトから追加のリダイレクトを提供する場合，そのリダイレクトにもHSTSヘッダーが含まれていること

 

サイバー攻撃の増加を背景にWebサイトの全ての通信をSSLに対応させる「常時SSL化」が推奨されています。ChromeなどではHTTPサイトへのアクセス時に表示される注意表記がだんだんと強化されてきており、HTTPアクセスだとユーザーに不安を与えつつあります。

 

また、Google透明性レポート（https://transparencyreport.google.com/https/overview?hl=ja）によると、ChromeユーザーからのアクセスはLinuxを除く他のプラットフォームでは90%以上がHTTPSでのアクセスになっています。

2021年10月時点ではGoogle以外のトップ100サイト（世界のあらゆるWebサイトのトラフィックのおよそ25%）のうちデフォルトでHTTPSを使用しているのは97サイトという概算が出ています。

 

そのため今後はWebブラウザのアドレスバーにドメインだけ入力した際のデフォルトプロトコルがHTTPからHTTPSになる可能性もでてきました。

会社の公式ページをHTTPアクセスしか用意していなければ、会社のドメイン入力だけではアクセスできなくなり影響がでてしまうかもしれません。HTTPのページが残っている場合はHTTPSへの対応を検討しておいたほうが良いかもしれません。

次回：「Cookieに対するセキュリティについて」