ウェブのセキュリティ

ウェブサイトには、さまざまな種類の異なる情報が含まれています。中には、例えば一般公開ページに表示させるコピーのように、機密性の低い情報もあります。また、例えば顧客のユーザー名やパスワード、銀行情報、あるいは内部アルゴリズムや非公開の製品情報など、機密性の高い情報もあります。

機密情報は保護する必要があり、それがウェブセキュリティの焦点となっています。その情報が悪用された場合、以下のようなことに使用されている可能性があります。

競合他社に情報を漏洩することで、企業を競争上不利な立場に置きます。
彼らのサービスワーカースクリプトを無効にしたり乗っ取ったりして、彼らの運営にも深刻な問題を引き起こします。
顧客のプライバシーを危険にさらし、プロファイリング、対象とする、データの損失、個人情報の盗難、さらには金銭的な損失のリスクにさらすことになります。

現行のブラウザーはすでにウェブ上のユーザーのセキュリティを保護するいくつかの機能を備えていますが、開発者も最善の手法を使用し、コードを慎重に記述して、ウェブサイトが安全であることを確保する必要があります。コードに単純なバグがあるだけでも、悪意のあるユーザーがデータを盗んだり、サービスを不正に制御したりするために悪用できる脆弱性が生じる可能性があります。

この記事では、ウェブセキュリティの概要を説明し、ウェブサイトの脆弱性を理解するのに役立つ概念的な情報や、ウェブサイトを保護する方法についての実践的なガイドを提供します。

セキュリティとプライバシーの関係

セキュリティとプライバシーは、それぞれ独立したトピックですが、密接に関連しています。この 2 つの違いと関連性を理解しておくことは価値があります。

セキュリティとは、許可されていないアクセスから機密データやシステムを保護する行為です。これには、社内（内部）データとユーザーおよびパートナー（外部）データのどちらも含まれます。
プライバシーとは、ユーザーが自身のデータの収集、保存、利用方法について制御できることを指し、同時に、無責任な利用が行われないよう保証する意味します。例えば、ユーザーに対して、どのようなデータを収集しているか、そのデータが共有される相手は誰か、どのように利用されるかなどを知らせる必要があります。ユーザーには、プライバシーポリシーに同意する機会が与えられ、自身のデータにアクセスし、必要に応じて削除できる必要があります。

良いセキュリティは、良いプライバシーにとって不可欠です。ウェブ上のプライバシーに関するガイドに掲載されているすべてのアドバイスに従うことはできますが、サイトが安全でなく、攻撃者がデータを盗むことができるのであれば、誠実に行動し、堅牢なプライバシーポリシーを持っていてもまったく無意味です。

ブラウザーが提供するセキュリティ機能

ウェブブラウザーは、コンテンツ、ブラウザーとサーバー間の接続、データ転送に対して強力なセキュリティを適用する厳格なセキュリティモデルに従っています。この節では、このモデルを支える機能を見ていきます。

同一オリジンポリシーと CORS

同一オリジンポリシーは、ウェブの基本的なセキュリティメカニズムであり、あるオリジンから読み込まれた文書やスクリプトが、別のオリジンからのリソースを操作する方法を制限します。これにより、潜在的に悪意のある文書を隔離し、実現可能な攻撃ベクトルを減らすことができます。

一般的に、あるオリジンの文書から、他のオリジンにリクエストを送信することはできません。これには意味があります。サイト同士が干渉し合ったり、許可されていないデータにアクセスしたりすることを防ぐためです。

しかし、状況によってはこの制限を緩和したい場合もあるでしょう。例えば、相互に操作する複数のウェブサイトがある場合、それらのサイト間で fetch() を使用してリソースをリクエストできるようにすることができます。これは、オリジン間リソース共有 (CORS) を使用して許可することができます。 CORS は、 HTTP ヘッダーベースのメカニズムで、ブラウザーがリソースの読み取りを許可すべき、自分自身以外のオリジン（ドメイン、スキーム、ポート）をサーバーが示すことを可能にします。

通信のための HTTP モデル

HTTP プロトコルは、ウェブブラウザーとサーバーが互いに通信し、リソースをリクエストし、レスポンス（例えば、リクエストされたリソースを提供したり、リクエストが失敗した理由を詳細に説明したり）を提供し、その通信のセキュリティ機能を提供するために使用されます。

トランスポート層セキュリティ (TLS) は、ネットワーク上での転送中にデータを暗号化することでセキュリティとプライバシーを提供し、 HTTPS プロトコルの背後にある技術です。 TLS はプライバシーの保護に有益な技術です。なぜなら、サードパーティーが送信データを介入し、悪意を持って使用することを阻止するからです。

すべてのブラウザーが HTTPS を既定で要求するように移行しつつあります。これはすでに事実上、このプロトコルなしではウェブ上で多くのことができないためです。

保護されたコンテキストと機能の許可

ブラウザーは「強力な機能」の使用をさまざまな方法で制御します。これらの「強力な機能」には、ウェブサイト上でシステム通知を生成すること、ユーザーのウェブカメラを使用してメディアストリームにアクセスすること、システム GPU を操作すること、ウェブ決済を使用することなどが含めることができます。サイトがこのような機能を制御する API を制限なく使用できる場合、悪意のある開発者は以下のようなことを試みることができます。

不要な通知や他にも UI 機能でユーザーを悩ませる。
警告することなくウェブカメラをオンにして、彼らを監視する。
ブラウザー/システムをクラッシュさせてサービス拒否 (DoS) 攻撃を作成する。
データやお金を盗み取る。

これらの「強力な機能」は、次の方法で制御されています。

このような機能の使用は、保護されたコンテキストでのみ許可されます。保護されたコンテキストとは、コンテンツが安全に配信された（HTTPS/TLS経由）という合理的な信頼性を持つウィンドウまたはワーカーです。保護されたコンテキストでは、保護されていないコンテキストとの通信の可能性は制限されます。保護されたコンテキストは、強力な機能にアクセスしようとする中間者攻撃者からのアクセスを防ぐのにも役立ちます。

保護されたコンテキストでのみ利用できるウェブプラットフォーム機能の一覧は、「保護されたコンテキストでのみ利用可能な機能」をご覧ください。
これらの機能の使用は、ユーザー権限のシステムによって制限されています。ユーザーは、そのような機能へのアクセスを明示的にオプトインする必要があり、自動的に使用できるということではありません。ユーザー権限のリクエストは自動的に行われ、権限 API を使用して API 権限の状態をクエリすることができます。
他にも、ボタンをクリックするなどユーザーのアクションに対するレスポンスとしてのみ使用できるブラウザー機能がいくつかあります。つまり、それらの機能は適切なイベントハンドラー内から呼び出す必要があるということです。これらは一時的な活性化と呼ばれます。詳細については、「ユーザーによる有効化によって制御される機能」を参照してください。

高水準のセキュリティの認識

ウェブセキュリティには、サーバー側とクライアント側で考慮すべき多くの側面があります。この章では、主にクライアント側のセキュリティに関する考慮事項に焦点を当てます。サーバー側の視点位置からのセキュリティに関する概要は、ウェブサイトセキュリティ（サーバー側ウェブサイトプログラミング学習モジュールの一部）で確認することができます。この概要には、注意すべき一般的な攻撃に関する説明も記載されています。

クライアント側にデータを格納することの責任

データを責任を持って取り扱うということは、サードパーティクッキーの使用を削減し、保存および共有するデータに注意を払うことに大きく関わっています。従来、ウェブ開発者はあらゆる種類のデータを保存するためにクッキーを使用してきましたが、この傾向を悪用することは攻撃者にとって容易でした。その結果、ブラウザーはサイトをまたいだクッキーでできることを制限し始め、将来的にはまったくアクセスできないようにすることを目指しています。

サイトをまたいだクッキーが除去されることを想定して、信頼しているトラッキング活動の量を制限したり、あるいは他にも希望する情報の維持を実装したりするなどの準備をしておくべきです。詳細については、「サードパーティークッキーからの移行」および「サードパーティークッキーの置き換え」をご覧ください。

ユーザーの識別の保護とログインの管理

データ収集を伴う保護されたソリューションを実装する場合、特にデータがログイン資格情報などの機密データである場合は、信頼性の高いソリューションを使用するのが賢明です。例えば、信頼できるサーバーサイドのフレームワークであれば、一般的な脆弱性から保護する機能が組み込まれているはずです。また、例えば ID プロバイダーソリューションや保護されたオンラインアンケートプロバイダーなど、目的に特化した製品を使用することも考えることができます。

ユーザーデータの収集について自分自身でソリューションを構築したい場合は、すべての側面と要求事項を理解していることを確認してください。システムの実装には、経験豊富なサーバーサイド開発者やセキュリティエンジニアを雇用し、徹底的な検査が確保されていることを確認してください。より強固な保護を実現するために、多要素認証 (MFA) を使用してください。ウェブ認証や連合資格情報管理などの専用 API を使用して、アプリのクライアント側を合理化することを検討してください。

安全なログインを提供するための、他にもいくつかのヒントがあります。

ユーザーのログイン情報を収集する際には、ユーザーのアカウント情報が簡単に推測されないように強力なパスワードを使用するように徹底してください。弱いパスワードは、セキュリティ侵害の主な原因の 1 つです。さらに、ユーザーにパスワード管理ツールを使用するように促し、より複雑なパスワードを使用できるようにしてください。そうすれば、パスワードを覚えておく必要がなくなり、書き留めることによるセキュリティリスクを生み出することもなくなります。安全でないパスワードの記事もお読みください。
また、フィッシングについてユーザーを教育する必要があります。フィッシングとは、ユーザーにメッセージ（例えば、電子メールや SMS）を送信し、そのメッセージに、ユーザーが日常的に使用しているサイトのように見えるが実際にはそうではないサイトのリンクを含める行為です。リンクには、ユーザーを騙してそのサイトのユーザー名とパスワードを入力させ、それを盗み、攻撃者が悪意のある目的で使用できるようにするメッセージが添えられています。

メモ: フィッシングサイトの中には、非常に巧妙に作られており、本物のウェブサイトと判別するのが難しいものもあります。そのため、ユーザーに、メールや SMS メッセージ内のランダムなリンクを信用しないよう教育する必要があります。「緊急です。これで課題を解決するには今すぐログインする必要があります」というようなメッセージを受け取った場合、メッセージ内のリンクをクリックするのではなく、新しいタブで直接サイトに移動し、直接ログインを試みるべきです。または、受け取ったメッセージについて問い合わせるために、電話またはメールで連絡することもできます。
ログインページに対するブルートフォース攻撃を、レート制限、一定回数以上のログイン失敗後にアカウントをロックアウトする機能、および CAPTCHA 認証により防御しましょう。
固有のセッション ID でユーザーのログインセッションを管理し、一定期間操作がない場合は自動的にログアウトするようにしましょう。

URL クエリー文字列に機密データを入れない

一般的に、 URL のクエリー文字列に機密データを含めることは避けるべきです。なぜなら、第三者が URL を傍受した場合（例えば、 HTTP の Referer ヘッダー経由で）、その情報を盗むことができるからです。さらに深刻なのは、これらの URL がインターネットアーカイブなどの公開ウェブクローラ、 HTTP プロキシー、アーカイブツールによってインデックス化される可能性があるということです。つまり、機密データが公的にアクセス可能なリソース上に残存する可能性があるということです。

これらの問題を避けるには、 GET リクエストではなく POST リクエストを使用してください。記事 Referer ヘッダーのプライバシーとセキュリティの考慮事項では、 Referer ヘッダーに関連付けられたプライバシーとセキュリティのリスクについてより詳しく説明し、それらのリスクを軽減するためのアドバイスを提供しています。

メモ: GET リクエストで URL に機密データを送信しないようにすることで、クロスサイトリクエストフォージェリーやリプレイ攻撃から保護するのにも役に立ちます。

使用ポリシーの強制

コンテンツセキュリティポリシー (CSP) や権限ポリシーなどのウェブプラットフォームの機能を使用して、ウェブサイトに一連の機能やリソースの使用ルールを設定し、脆弱性を導入しにくくすることを検討してください。

CSP を使用すると、例えば、特定の信頼された元から読み込まれた画像やスクリプトのみを許可するなど、セキュリティのレイヤーを追加することができます。これにより、クロスサイトスクリプティング (XSS) やデータインジェクション攻撃など、特定の種類の攻撃を検知し、緩和するのに役立ちます。これらの攻撃には、データ盗難、サイト改ざん、マルウェアの配布など、さまざまな悪意のある活動が含まれます。

その権限ポリシーは、特定の「強力な機能」（前述の通り）にアクセスすることを許可またはブロックすることに重点を置いていることを除いては、同様の方法で機能します。

メモ: このようなポリシーは、特にサイトに多くのサードパーティー製コードを使用している場合に、サイトのセキュリティを維持する上でとても役立ちます。ただし、サードパーティー製スクリプトが動作するために信頼している関数の使用をブロックすると、サイトの機能が壊れてしまう可能性があることを念頭に置いてください。

データの完全性の保守

前述の節に続き、サイトで機能とリソースの使用を許可する場合、リソースが改ざんされていないことを確実に保持するようにしてください。

入力のサニタイジング

一般的に、ユーザーがフォームに入力する何らかの情報については信用しないようにしてください。オンラインフォームへの入力は複雑で面倒な作業であるため、ユーザーが誤ったデータや誤った形式のデータを入力してしまうことはよくあります。また、悪意のある人々は、特定の実行コードの文字列をフォームフィールドに入力する技術に長けています（例えば、SQL や JavaScript など）。このような入力の取り扱いに注意を払わないと、有害なコードがサイト上で実行されたり、データベースが削除されたりする可能性があります。この問題が起こり得る良くある例としては、SQL インジェクションを参照してください。

これに対抗するには、フォームに入力されたデータを徹底的に無害化する必要があります。

ユーザーが間違った形式でデータを入力した際に通知を行うために、クライアント側検証を実装する必要があります。これは、 HTML フォーム検証機能を使用して行うことができます。または、独自の検証コードを記述することもできます。詳しくは、「クライアント側フォーム検証」を参照してください。
アプリケーションの UI でユーザーが入力したものを表示する際には、出力エンコードを使用しましょう。そうすることで、ユーザーが入力したデータを正確に安全に表示し、コードとして実行されるのを避けることができます。詳細は、出力エンコードをご覧ください。

セキュリティに関しては、クライアントサイドの検証だけでは不十分であり、サーバーサイドの検証と結合させる必要があります。クライアントサイドの検証では、サーバーへの往復を待つことなく、即座に検証フィードバックを指定することで、ユーザーの使い勝手が向上します。しかし、クライアントサイドの検証は、悪意のある当事者にとっては回避が容易です（例えば、ブラウザーで JavaScript をオフにすることで、 JavaScript ベースの検証を回避できます）。

信頼できるサーバーサイドフレームワークであれば、フォーム投稿の検証機能が提供されています。さらに、一般的な最善の手法として、実行可能な構文の一部を形成する特殊文字をエスケープし、入力されたコードが実行できなくなり、プレーンテキストとして扱われるようにする方法があります。

クリックジャッキングからの保護

クリックジャッキング攻撃では、ユーザーが意図しない操作を行う UI の要素をクリックするように仕向けられ、ユーザーの機密情報が悪意のあるサードパーティーに渡されるという結果になることが多くあります。このリスクは組み込まれたサードパーティーのコンテンツに内在しているため、サイトに組み込まれるコンテンツが信頼できるものであることを確認してください。また、クリックジャッキングはフィッシングのテクニックと結合される可能性があることに注意してください。フィッシングについては、前回追加した部分「ユーザーの身元を保護し、ログインを管理する」で説明しています。

次の機能はクリックジャッキング対策として役立ちます。

HTTP X-Frame-Options: X-Frame-Options HTTP レスポンスヘッダーを使用して、ブラウザーがページを <frame>、<iframe>、<embed>、<object> でレンダリングすることを許可するかどうかを指定することができます。サイトは、このヘッダーを使用して、コンテンツが他のサイトに埋め込まれないように確保することで、クリックジャッキング攻撃を避けることができます。
CSP: frame-ancestors: HTTP の Content-Security-Policy (CSP) frame-ancestors ディレクティブは、 <frame>、<iframe>、<object>、<embed> を使用してページを埋め込むことができる有効な親を指定します。

実践的なセキュリティ実装ガイド

ウェブサイトにセキュリティ機能を効果的に実装するための包括的な指示を取得し、最善の手法に従っていることを確実に保持するには、実践的なセキュリティ実装ガイドを設定します。

これらのガイドの一部は、HTTP Observatory ツールに直接関連しています。Observatory はウェブサイトに対してセキュリティ監査を行い、セキュリティ上の問題点が見つかった場合には、その修正に関する推奨事項とともに、評価とスコアを提供します。これらのガイドでは、MDN Observatory テストで検出された問題の解決方法について説明しています。このツールは、各課題に関連するガイドにリンクしており、効果的な解決方法を手伝ってくれます。興味深いことに、Mozilla の内部開発者チームは、ウェブサイトを実装する際に、このガイドラインを使用して、セキュリティに関する最善の手法が確実に適用されるようにしています。