Top Trends in Cybersecurity for 2024 | 
セキュリティヘッダーの実装は、侵害やデータ盗難の数が日々急速に増加しているため、非常に重要になっている。 セキュリティヘッダーはソリューションの実装が簡単な部分を提供する: XSS、コードインジェクション、クリックジャックなどの一般的な攻撃からウェブサイトを保護するために、特定のHTTPヘッダーを渡すだけ。
セキュリティヘッダーとは
Webアプリケーションは、セキュリティヘッダーと呼ばれる侵害やクライアント側の脆弱性からWebサイトを保護するために、ブラウザに特別なコマンドを送信することができる。
ユーザーがブラウザでウェブサイトを訪問すると、サーバーはHTTPレスポンスヘッダで応答する。 メタデータで構成されるこれらのヘッダは、クライアントとサーバと情報を共有する。 この共有情報はブラウザがウェブサイトとどのように相互作用するかを定義する。 セキュリティヘッダーは、さまざまなWebアプリケーションの脆弱性や脅威から強力な保護を提供する。
このブログでは、次の重要なセキュリティヘッダーを分解する。
- コンテンツセキュリティポリシー（CSP）
- Xコンテンツタイプオプション
- Xフレーム-オプション
- クロスオリジンリソースポリシー（CORP）
- クロスオリジン埋め込みポリシー（COEP）
- クロスオリジンオープナーポリシー（COOP）
- Referrer -ポリシー
- 権限-ポリシー
- HTTP Strict Transport Security（HSTS; HTTP厳密トランスポートセキュリティ）
セキュリティヘッダーの重要性
HTTPセキュリティヘッダはウェブサイトのセキュリティの基本的な部分であるが、上位100万のウェブサイトの1.6%のみがコンテンツセキュリティポリシー(CSP)を実装しており、CSP-Report-Onlyを実装しているサイトはわずか0.2%である。
衝撃的、右か! CSP HTTPヘッダがないことで、クロスサイトスクリプティング(XSS)や他のクライアント側インジェクション攻撃に対する防御機構が破壊される。 ブリティッシュ・エアウェイズのデータ漏洩は、クライアント側のセキュリティの欠如により、38万人の顧客の氏名、住所、電子メールアドレス、クレジットカード番号、有効期限、カードセキュリティコードが漏洩し、15日間検出されなかったことを示すインシデントの1つである。
Layer0のEdgeJSによるセキュリティの追加
Layer0のデプロイメントプラットフォームでは、TLSのようなものがデプロイリンクごとに自動的に設定されるため、開発者はデフォルトで安全に出荷できる。 このブログでは、重要なセキュリティヘッダーと、Layer0上のroutes configを使用してWebサイトをどれだけ迅速に保護できるかを示す例を詳しく見ていく。
Edgioでセキュリティヘッダーを使用する前に
コンテンツセキュリティポリシー（CSP）
CSPが許可されていないオリジンからのリソースのロードを防止する方法
Content-Security-Policyは、スクリプト、スタイル、画像、フォント、メディアが特定の許可されたオリジンからロード(および実行)されるのを制限することで、クロスサイトスクリプティング(XSS)攻撃を防ぐ追加レイヤーを提供する。 バックエンドの安全性に関係なく、サーバー上ではなくブラウザー上で実行されるコードを攻撃できる場合、ユーザーセッションデータが侵害され、機密情報が漏洩する。 多くの例の一つ（例えばブリティッシュ・エアウェイズのデータ侵害）は、Ticketmasterの支払いモジュールに対するMageCart攻撃である。Ticketmasterの侵害は、クレジットカードの盗難の40,000の犠牲者をもたらし、逮捕される前に5ヶ月間活動を続けた! ブラウザ内にフォームスキミングスクリプトを挿入するだけですべて。
const {Router}= require(‘@layer0/core/router’) const ContentSecurityPolicy =`default-src ‘self’; script-src ‘self”unsafe-inline’*.layer0.co; style-src ‘self”’unsafe-inline’*.googleapis.com img-src*blob: data:; media-src ‘none’; connect-src’;.gstatic.comnew Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“Content-Security-Policy”,ContentSecurityPolicy.replace(/\n/g,”)})>
Content-Security-Policyを使用すると、次のことが可能になる。
- XSS（クロスサイトスクリプティング）攻撃を克服する
- クリックジャッキングを防止する
- 違反をCSPルールに報告する
Xコンテンツタイプオプション
X-Content-Type-Optionsの設定でMIMEタイプスニフィングを防止する方法
X-Content-Type-Optionsヘッダは、Content-Typeヘッダで指定されたMIME (Multipurpose Internet Mail Extensions,ファイル形式の識別子)型に厳密に従うことを示す。 MIMEタイプスニフィングでは、画像のアップロードなどの操作によって、X-Content-Type-Optionsヘッダが関与する悪意のある実行可能ファイルが実行される可能性がある。
const {Router}= require(‘@layer0/core/router’) new Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“X-Content-Type-Options”,”nosniff”)})>
Xフレーム-オプション
X-Frame-Optionsヘッダー
X-Frame-Optionsヘッダーは、ブラウザがフレーム、iframe、embed、またはobjectタグでページをレンダリングすることを許可するかどうかを示す クリックジャッキング攻撃。DENYまたはSAMEORIGINのどちらに設定しても、コンテンツが他のサイトに埋め込まれていないか、同じオリジンを持つサイトにのみ埋め込まれていることを保証する。
const{Router}= require(‘@layer0/core/router’) new Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“X-Frame-Options”,”SAMEORIGIN”)})>
X-Frame-Optionsを使用すると、次のことが可能になる。
- クリックジャッキ攻撃を防ぐ
- ブラウザでページをレンダリングすることを許可するかどうかを指定する <フレーム>、 <iframe>、 <埋め込み> または <オブジェクト>
クロスオリジンリソースポリシー（CORP）
CORPは、サーバが要求されたリソースの特定のクロスオリジンやクロスサイト埋め込み（例えばAPIレスポンス）から保護することを可能にする。また、Spectreのような投機的なサイドチャネル攻撃も防ぐ。
const {Router}= require(‘@layer0/core/router’) new Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“Cross-Origin-Resource-Policy”,”same-origin”)})>
Cross-Origin Resource Policyは、任意のリソースを保護できるopt-inレスポンスヘッダーであり、ブラウザがMIMEタイプをスニフする必要はない。 —MDNドキュメント
クロスオリジン埋め込みポリシー（COEP）
COEPヘッダーは、（CORSまたはCORP経由で）許可されていないクロスオリジンリソースのロードを防止する。 ヘッダを強制するには「require-corp」を使用し、クロスオリジンドキュメントの取得を許可するには「unsafe-none」を使用する。
const {Router}= require(‘@layer0/core/router’) new Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“Cross-Origin-Embedder-Policy”,”require-corp”)})>
クロスオリジンオープナーポリシー（COOP）
COOPヘッダーを適用することで、トップレベルのドキュメントの閲覧コンテキストグループがオリジン間のドキュメント間で共有されないようにする。 「same-origin」はOAuthやPaymentのようなウィンドウ間の相互作用を必要とする統合を打ち切るが、「same-origin-allow-popups」はSAMEORIGINからのポップアップのみとコンテキストを共有することを目的としている。
const {Router}= require(‘@layer0/core/router’) new Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“Cross-Origin-opener-Policy”,”same-origin-allow-popups”)})>
リファラーポリシー
ユーザーがあるサイト（オリジン）から別のサイト（宛先）に移動（リンクをクリック）すると、後者はユーザーの発信元に関する情報を受け取る。 Referrer-Policyヘッダは、この情報のうち宛先がどれだけ利用できるかを制御する。 Referrer-Policyのすべてのディレクティブについては、Referrer-Policy—HTTP | MDN ( mozilla.org )を参照。
const{Router}= require(“@layer0/core/router”) module.exports = new Router().get(“/”,({setResponseHeader})={setResponseHeader(“Referrer-Policy”,”origin-when-cross-origin”)})>
権限ポリシー
独自のフレームおよびドキュメント内の任意のiframeでブラウザ機能を許可/拒否する機能を提供する実験的なHTTPヘッダー。 Referrer-Policyのすべてのディレクティブについては、Feature-Policy—HTTP | MDN ( mozilla.org )を参照
const{Router}= require(“@layer0/core/router”) module.exports = new Router().get(“/”,({setResponseHeader})={setResponseHeader(“Permissions-Policy”,”camera=(), microphone=(),> geolocation=()”)”);})
HTTP Strict Transport Security（HSTS; HTTP厳密トランスポートセキュリティ）
HSTS厳密なトランスポートセキュリティヘッダー
HTTP Strict-Transport-Security (HSTS)は、HTTPプロトコルを使用するのではなく、HTTPSのみを使用してWebサイトをロードするようブラウザに通知する。
const{Router}= require(‘@layer0/core/router’) new Router().get(“/:route”,({setResponseHeader})={setResponseHeader(“Strict-Transport-Security”,”max-age=31536000;includeSubDomains”)})>
HSTSの機能：
- HTTPダウングレード攻撃（SSLストリッピング攻撃）から保護する
- 混合コンテンツ防御はデフォルトでHTTPSに切り替わる
例
Layer0を使用すると、セキュリティヘッダーの実装がこれまで以上に簡単になる。 Layer0のEdgeJSを使用することで、使用されているフレームワークに関係なく、任意のWebサイトにセキュリティヘッダーを追加できる。 以下では、関連するセキュリティヘッダをLayer0を介してSapperで構築されたウェブサイトに実装しようとしている。
例：https://rishi-raj-jain-security-headers-example-default.layer0-limelight.link
GitHub: Rishi-Raj-Jain /security-headers-example
レポート:セキュリティヘッダーレポートのリンク
