企業サイトのセキュリティ対策とカスタムヘッダーの活用

不正アクセス、情報漏洩、改ざん、マルウェア感染、なりすまし…、Webサイトの脆弱性やセキュリティのリスクに対して、実際にSTUDIOではどのような対策を行えばいいのでしょうか？

この記事では、5月23日にリリースされたアドオン機能がビジネス現場のどんなユースケースに適用できるかを実際の例も引き合いに出しながらご紹介します。

本記事は、ある程度の人数やサイト規模でSTUDIOを運用しており、公開に伴うセキュリティリスクに関心や課題を持つ事業会社さまや制作会社さま向けの内容となります。

アドオン機能の詳細についてはSTUDIOのヘルプ記事も併せてご参照ください。

サイバーセキュリティの重要性

企業の経営課題としてのサイバーセキュリティ

組織のシステムが老朽化する中で、技術的負債とセキュリティリスクは増える一方で、Webサイトや新しいサービスを利用する企業としてもセキュリティ対策を行うことが重要であることは言うまでもありません。

重大な情報漏洩やセキュリティインシデントが発生した場合、機会損失の拡大、レピュテーションの毀損、財務的影響にも及びます。

昨今のサイバー攻撃による企業活動への影響を最小化するには、IT部門だけでなく事業部門等も交え対策を推進することが必要とされています。

経産省でも大企業や中小企業に向けて、サイバーセキュリティ経営ガイドラインを策定しています。

STUDIOのセキュリティ対策

公開サイトにおける外部からの攻撃についてはSTUDIOでも基盤レベルであらゆるセキュリティ対策を標準提供しています。

たとえば、以下のようなことが担保されています。

• ネットワークレベルで不要なポートやプロトコルをファイヤーフォールでブロックする

• IPS/IDSで不正アクセスや悪意のある侵入を常時モニタリングしてブロックする（DoS/DDoS対策など）

• WAFでSQLインジェクションやXSS（クロスサイトスクリプティング）といった悪意あるスクリプト実行をブロックする

• 常時SSL化で公開サイトへの通信を暗号化する

より詳しい内容については、IPAが公開している「安全なウェブサイトの作り方」が参考になります。届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料として公開されています。

また、外部からの攻撃のみならず、STUDIOのダッシュボードやエディタにアクセスできる人を安易に増やしてしまうと、内部不正による情報流出などのトラブルのリスクが上昇します。プロジェクト数やメンバーが増えると、退職者が出た場合のアカウント削除など対応に追えなくなるリスクが生じたりもするでしょう。

その場合に必要な対策は以下のようなことです。

• 監査ログでサービス利用者の認証ログ、アクセスログ、操作ログをいつでも追跡できるようにする

• メンバー管理や権限管理の定期的な棚卸しを行う

本記事では、公開サイトにおける外部からの攻撃リスクに焦点を当てて、より詳細な内容をご説明します。

セキュリティ対策に必要なレスポンスヘッダー

外部からの攻撃に対して、STUDIOの個別プロジェクトで必要に応じてセキュリティヘッダーをカスタマイズすることで対策することができます。

以下に、STUDIOでサポート可能な主要なレスポンスヘッダーの概要をいくつか説明します。

X-XSS-Protection

• 目的：反射型XSS攻撃を防ぐ

• 概要：ブラウザの組み込みXSS防御を有効にする

X-XSS-Protectionは、OWASP Top 10（最も重大なウェブアプリケーションのセキュリティリスク）にも常にランクインしているXSSに対策に必要です。

IPAの「安全なウェブサイトの作り方」からの引用です。

「X-XSS-Protection」は、ブラウザの「XSS フィルタ」の設定を有効にするパラメータです。ブラウザで明示的に無効になっている場合でも、このパラメータを受信することで有効になります。 HTTP レスポンスヘッダに「X-XSS-Protection: 1; mode=block」のように設定することで、クロスサイト・スクリプティング攻撃のブロックを試みる機能が有効になります。

X-Content-Type-Options

• 目的：MIMEタイプスニッフィング攻撃を防ぐ

• 概要：ブラウザにContent-Typeヘッダーを厳格に解釈するよう指示

X-Content-Type-Optionsは、Content-Typeを指定することにより送信するデータの種類や形式を指定します。

例えばContent-Typeヘッダにtext/html以外が指定されている場合でも、攻撃者が用意したHTMLとして解釈できるファイルを開くとHTMLとして処理され、JavaScriptが実行されクロスサイトスクリプティング攻撃につながる可能性があります。

「X-Content-Type-Options: nosniff」を指定することで攻撃を軽減することが可能となります。

X-Frame-Options

• 目的：クリックジャッキング攻撃を防ぐ

• 概要：自サイトのページを他サイトでiframeに埋め込むことを制御する

X-Frame-Optionsは、iframe要素内でのコンテンツの読み込みを制限することができる仕組みです。

フレーム内でコンテンツが表示されないようにすることで、クリックジャッキングと呼ばれる攻撃手法を使って機密情報を盗みとられるリスクを防ぐことができます。

IPAの「安全なウェブサイトの作り方」からの引用です。

X-Frame-Optionsは、ウェブアプリケーションをクリックジャッキング攻撃から防御するためのヘッダです（*1）。HTTPのレスポンスヘッダに「X-Frame-Options: DENY」のように出力することで、X-Frame-Optionsに対応したブラウザにおいて、frame要素やiframe要素によるページ読み込みの制限ができます。なお、Internet Explorer 7は、X-Frame-Options ヘッダに対応していないため、本対策を実施したとしても、当該ブラウザにおいてはクリックジャッキング攻撃を防げません。

X-Frame-Optionsで指定する設定値により、制限の範囲が変わります。設定値の挙動は下記表の通りです。なお、ALLOW-FROMはブラウザによって適切に動作しない場合があります。開発しているウェブアプリケーションがサポート予定のブラウザの対応状況を調査した上で、当該設定値の使用を検討してください。

Content-Security-Policy

• 目的：XSSや他のコード注入攻撃を防ぐ

• 概要：ページで許可するリソース（スクリプト、スタイル、画像など）の出所を指定

content-security-policyは、同様に悪意のあるスクリプト実行（XSS、クリックジャッキングなど）に対するリスクを軽減する仕組みです。

Webサイト上で動作してもよいスクリプトを指定することができ、これによりクロスサイトスクリプティングなどの脆弱性があったとしても指定されたURL以外からのスクリプトは実行されないため、攻撃範囲を限定的にすることが可能となります。

IPAの「安全なウェブサイトの作り方」からの引用です。

「Content Security Policy (CSP)（脚注9）」は、ブラウザで起こりうる問題を緩和するセキュリティの追加レイヤーです。その機能の一つに、反射型クロスサイト・スクリプティング攻撃を防止する「reflected-xss」があります。HTTP レスポンスヘッダに「Content-Security-Policy: reflected-xss block」のように設定することで、クロスサイト・スクリプティング攻撃のブロックを試みる機能が有効になります。

Strict-Transport-Security

• 目的：中間者攻撃を防ぐ。

• 概要：ブラウザにHTTPSのみを使用するよう指示し、ダウングレード攻撃を防ぐ。

HSTSは、WebサイトにHSTSが設定されていることをWebブラウザが検知した場合、アクセス先として指定されたURLがhttp://で始まるURIだとしても HTTPSでアクセスが行われます。

HTTPSでアクセスした後にHTTPが使われないようにすることで、中間者攻撃と呼ばれる攻撃手法を使って悪意のあるサイトに誘導されるリスクを軽減することが可能となります。

レスポンスヘッダー仕様の詳細

各種レスポンスヘッダーの仕様について詳細はMDNの定義をご参照ください。

HTTP ヘッダー - HTTP | MDN Web Docs

最後に

STUDIOではスタートアップ、中小企業、大企業、行政、教育機関まで様々なユーザー様における導入と活用促進をサポートするEnterpriseプランを提供しております。

Webhookの応用、カスタムコードを利用した分析ツールとの連携、カスタムプロキシやカスタムヘッダーの実装支援などご要望の場合は、Enterpriseプランの窓口よりお問い合わせください。