From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../security/certificate_transparency/index.html | 62 +++++ files/ja/web/security/index.html | 237 ++++++++++++++++++ .../information_security_basics/index.html | 39 +++ .../ja/web/security/insecure_passwords/index.html | 31 +++ .../index.html | 31 +++ files/ja/web/security/mixed_content/index.html | 83 +++++++ .../ja/web/security/public_key_pinning/index.html | 163 ++++++++++++ .../index.html | 58 +++++ .../ja/web/security/same-origin_policy/index.html | 272 +++++++++++++++++++++ .../index.html | 236 ++++++++++++++++++ files/ja/web/security/secure_contexts/index.html | 77 ++++++ .../ja/web/security/securing_your_site/index.html | 54 ++++ .../turning_off_form_autocompletion/index.html | 74 ++++++ .../web/security/site_identity_button/index.html | 29 +++ .../ja/web/security/subdomain_takeovers/index.html | 60 +++++ .../web/security/subresource_integrity/index.html | 150 ++++++++++++ .../security/transport_layer_security/index.html | 124 ++++++++++ files/ja/web/security/types_of_attacks/index.html | 88 +++++++ .../security/weak_signature_algorithm/index.html | 29 +++ 19 files changed, 1897 insertions(+) create mode 100644 files/ja/web/security/certificate_transparency/index.html create mode 100644 files/ja/web/security/index.html create mode 100644 files/ja/web/security/information_security_basics/index.html create mode 100644 files/ja/web/security/insecure_passwords/index.html create mode 100644 files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html create mode 100644 files/ja/web/security/mixed_content/index.html create mode 100644 files/ja/web/security/public_key_pinning/index.html create mode 100644 files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html create mode 100644 files/ja/web/security/same-origin_policy/index.html create mode 100644 files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html create mode 100644 files/ja/web/security/secure_contexts/index.html create mode 100644 files/ja/web/security/securing_your_site/index.html create mode 100644 files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html create mode 100644 files/ja/web/security/site_identity_button/index.html create mode 100644 files/ja/web/security/subdomain_takeovers/index.html create mode 100644 files/ja/web/security/subresource_integrity/index.html create mode 100644 files/ja/web/security/transport_layer_security/index.html create mode 100644 files/ja/web/security/types_of_attacks/index.html create mode 100644 files/ja/web/security/weak_signature_algorithm/index.html (limited to 'files/ja/web/security') diff --git a/files/ja/web/security/certificate_transparency/index.html b/files/ja/web/security/certificate_transparency/index.html new file mode 100644 index 0000000000..a3efbd98a6 --- /dev/null +++ b/files/ja/web/security/certificate_transparency/index.html @@ -0,0 +1,62 @@ +--- +title: 証明書の透明性 +slug: Web/Security/Certificate_Transparency +tags: + - Security + - Web +translation_of: Web/Security/Certificate_Transparency +--- +

Certificate Transparency は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。

+ +

このようにして、証明書局 (CA) は、はるかに大きな監視と監督を受けることができます。CA/B フォーラムのベースライン要件に違反するような、潜在的に悪意のある証明書は、より迅速に検出され、失効される可能性があります。また、ブラウザベンダーやルートストアのメンテナは、不信に繋がるかもしれない問題がある CA について、より多くの情報に基づいた決定を下すことができるようになります。

+ +

背景

+ +

CT ログは Merkle ツリーのデータ構造をベースに構築されています。ノードには子ノードの暗号化ハッシュがラベル付けされています。リーフノードには実際のデータのハッシュが含まれています。したがって、ルートノードのラベルは、ツリー内の他のすべてのノードに依存します。

+ +

Certificate Transparency のコンテキストでは、リーフノードによってハッシュ化されたデータは、現在運営されている様々な異なる CA によって発行された証明書です。証明書の組み込みは、対数的な O(log n) 時間で効率的に生成・検証できる監査証明を介して検証することができます。

+ +

Certificate Transparency は、認証局の危殆化 (2011 年の DigiNotar の違反)、疑わしい決定 (2012 年の Trustwave の下位ルート事件)、技術的な発行問題 (マレーシアの Digicert Sdn Bhd による 512 ビットの脆弱な証明書の発行) を背景に、2013 年に初めて実現しました。

+ +

実装

+ +

証明書が CT ログに送信されると、署名付き証明書のタイムスタンプ (SCT) が生成されて返されます。これは、証明書が提出され、ログに追加されることを証明する役割を果たします。

+ +

仕様では、準拠サーバは接続時にこれらの SCT を TLS クライアントに提供しなければならないとされています。これは、いくつかの異なるメカニズムを介して実現することができます。

+ + + +

X.509 証明書の拡張では、含まれる SCT は発行 CA が決定します。このメカニズムを使用する場合、Web サーバを変更する必要はありません。

+ +

後者の方法では、必要なデータを送信するためにサーバを更新する必要があります。利点は、サーバオペレータが TLS 拡張/stapled OCSP レスポンスを介して送信される SCT を提供する CT ログソースをカスタマイズできることです。

+ +

ブラウザの要件

+ +

Google Chrome では、2018年4月30日以降の notBefore 日付を持つすべての証明書の問題に対して、CT ログのインクルードを要求しています。これにより、ユーザーは非準拠の TLS 証明書を使用したサイトを訪問できなくなります。これまで Chrome では、Extended Validation (EV) や Symantec が発行した証明書に対して CT のインクルードが義務付けられていました。

+ +

Apple は、Safari や他のサーバがサーバ証明書を信頼するために、さまざまな数の SCT を必要としています。

+ +

Firefox は現在、ユーザーが訪問したサイトの CT ログを確認したり、使用を義務付けたりしていません。

+ +

Expect-CT ヘッダを使用して、ブラウザが証明書の透過性の要件を常に実施するように要求することができます (Chrome などでは、証明書の発行日が4月以前の notBefore であっても)。

+ +

仕様

+ + + + + + + + + + + + + + +
仕様書ステータスコメント
Certificate TransparencyIETF RFC
diff --git a/files/ja/web/security/index.html b/files/ja/web/security/index.html new file mode 100644 index 0000000000..4db17fb313 --- /dev/null +++ b/files/ja/web/security/index.html @@ -0,0 +1,237 @@ +--- +title: Web セキュリティ +slug: Web/Security +tags: + - Landing + - Security + - Web + - セキュリティ +translation_of: Web/Security +--- +
+

Web サイトや公開 Web アプリケーションが安全であることを保証するのは重要なことです。コードの中の単純なバグが、個人情報の漏洩という結果を招くことがありますし、データを盗む方法を見つけようとしている悪い輩があちこちにいます。以下に紹介するセキュリティ方面の記事では、コードの安全性を確保する際に助けとなる情報を提供しています。

+
+ +

コンテンツセキュリティ

+ +
+
コンテンツセキュリティポリシー (CSP)
+
コンテンツセキュリティポリシー ({{Glossary("CSP")}}) は、クロスサイトスクリプティング ({{Glossary("XSS")}}) やデータインジェクション攻撃などのような、特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。これらの攻撃はデータの窃取からサイトの改ざん、マルウェアの拡散に至るまで、様々な目的に用いられます。
+
+ +

コネクションセキュリティ

+ +
+
Transport security layer (TLS)
+
Transport Layer Security ({{Glossary("TLS")}}) プロトコルは、ネットワークで結ばれた二つのアプリケーションや端末が、私的にかつ強固に情報交換するための標準です。 TLS を使用するアプリケーションは、セキュリティ引数を選択することができ、これは、データのセキュリティと信頼性に大きな影響を与える可能性があります。この記事では、 TLS の概要と、コンテンツを保護するために必要な決定の種類について説明します。
+
HTTPS
+
HTTPS (HyperText Transfer Protocol Secure) は、 {{Glossary("HTTP")}} プロトコルの暗号化バージョンです。 {{Glossary("SSL")}} または {{Glossary("TLS")}} を使用して、クライアントとサーバー間のすべての通信を暗号化します。この安全な接続により、クライアントは意図したサーバーに接続されていることを確認し、機密データを交換することができます。
+
HTTP Strict-Transport-Security
+
Strict-Transport-Security: は HTTP のヘッダーで、Web サイトを HTTPS を使用してのみアクセスできるようにするものです。
+
電子証明書の透明性
+
電子証明書の透明性は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。
+
混在コンテンツ
+
HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、混在コンテンツと呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。
+
混在コンテンツでブロックされるWeb サイトを修正するには
+
Web サイトを HTTPS で配信している場合、ページ上にある 能動的な混在コンテンツはすべて既定でブロックされます。結果として、ユーザーからはその Web サイトが壊れているように見えるかもしれません (iframe やプラグインが読み込まれないなど)。一方、受動的な混在コンテンツは既定で表示されますが、このようなコンテンツをブロックするようにユーザーが設定することも可能です。このページでは、Web 開発者として知っておくべきことを説明します。
+
安全なコンテキスト
+
安全なコンテキスト (Secure Context) とは、(HTTPS/TLS を介して) コンテンツが安全に配信され、安全ではないコンテキストとの通信の可能性が限られているという合理的な確信がある Window、または Worker のことです。多くの Web API が安全なコンテキストでのみ利用可能です。安全なコンテキストの主目的は、{{interwiki("wikipedia", "中間者攻撃", "中間者攻撃者")}}が被害者に更なる危険にさらす可能性がある強力な API にアクセスするのを防ぐことにあります。
+
安全なコンテキストに制限されている機能
+
このリファレンスは、安全なコンテキストでのみ使用できるWeb プラットフォーム機能の一覧です。
+
脆弱な署名アルゴリズム
+
{{Glossary("Digital certificate", "ディジタル証明書")}}の{{Glossary("Signature/Security", "電子署名")}}に用いられるハッシュアルゴリズムの強度は、証明書のセキュリティにおいて核心的な要素です。この記事では、脆弱になったため、可能であれば避けるものと知られている署名アルゴリズムについて、いくらかの情報を提供します。
+
301 および 302 レスポンスコードによるリダイレクト
+
執筆予定
+
+ +

データセキュリティ

+ +
+
HTTP Cookie の使用
+
HTTP Cookie (ウェブ Cookie、ブラウザ Cookie) は、サーバーがユーザーのWeb ブラウザに送信する小さなデータであり、ブラウザに保存されて次のリクエストと共に同じサーバーへ返送されます。一般的には、二つのリクエストが同じブラウザから送信されたものであるかを知るために使用されます。例えば、ユーザーのログイン状態を維持することができます。
+
ローカルストレージ
+
Window オブジェクトの {{domxref("Window.localStorage")}} プロパティは、サーバーがクライアントにセッションを通して存在するデータを格納する一つの手段です。
+
+ +

情報漏洩

+ +
+
Referer ヘッダーのプライバシーとセキュリティの考慮事項
+
HTTP の Referer ヘッダーにまつわるプライバシーとセキュリティのリスクがあります。この記事ではこれらを説明し、これらのリスクを回避するためのアドバイスを提案します。
+
Robots.txt
+
執筆予定
+
Site maps
+
執筆予定
+
+ +

完全性

+ +
+
同一オリジンポリシー
+
同一オリジンポリシーとは、あるオリジンから読み込まれた文書やスクリプトについて、そのリソースから他の{{Glossary("origin", "オリジン")}}のリソースにアクセスできないように制限するものです。同一オリジンポリシーは Web のセキュリティにおける重要な仕組みであり、悪意ある行動を起こしかねないリソースの分離を目的としています。
+
サブリソース完全性
+
サブリソース完全性 (Subresource Integrity) (SRI) は、 ({{Glossary("CDN")}} などから) 取得したリソースが意図せず改ざんされていないかをブラウザが検証するセキュリティ機能です。 SRI を利用する際には、取得したリソースのハッシュ値と一致すべきハッシュ値を指定します。
+
HTTP の Access-Control-Allow-Origin
+
Access-Control-Allow-Origin レスポンスヘッダーは、指定された{{glossary("origin", "オリジン")}}からのリクエストを行うコードでレスポンスが共有できるかどうかを示します。
+
HTTP X-Content-Type-Options
+
+

X-Content-Type-Options は HTTP のレスポンスヘッダーで、 {{HTTPHeader("Content-Type")}} ヘッダーで示された MIME タイプを変更せに従うべきであることを示すために、サーバーによって使用されるマーカーです。これにより、MIME タイプのスニッフィングを抑止することができます。すなわち、Web マスターが自分が何をしているかを分かっていると言う手段です。

+
+
+ +

クリックジャックからの保護

+ +

クリックジャッキングでは、ユーザーがだまされて、ユーザーが期待するもの以外のアクションを実行するUI要素をクリックします。 

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

ユーザー情報セキュリティ

+ +
+
安全でないパスワード
+
HTTP 経由でログインフォームを送信することは、ユーザのパスワードを抽出するために使用できる様々な攻撃があるため、特に危険です。ネットワーク盗聴者は、ネットワークを盗聴したり、転送中に提供されたページを変更したりすることで、ユーザのパスワードを盗むことができます。
+
プライバシーと :visited セレクタ
+
2010年頃までは、CSS {{cssxref(":visited")}} セレクタにより、Web サイトがユーザーの閲覧履歴を明らかにし、そのユーザーがどのサイトを訪問したかを把握することができました。この問題を軽減するために、ブラウザは訪問したリンクから取得できる情報量を制限しています。
+
+ + + +
+ + + +
+ +

関連情報

+ + + +

{{QuickLinksWithSubpages}}

diff --git a/files/ja/web/security/information_security_basics/index.html b/files/ja/web/security/information_security_basics/index.html new file mode 100644 index 0000000000..4eaeff0350 --- /dev/null +++ b/files/ja/web/security/information_security_basics/index.html @@ -0,0 +1,39 @@ +--- +title: 情報セキュリティの基本 +slug: Web/Security/Information_Security_Basics +tags: + - Beginner + - Landing + - Security + - セキュリティ +translation_of: Web/Security/Information_Security_Basics +--- +

情報セキュリティを基本的に理解しておくことは、ソフトウェアやサイトが危険で脆弱なままで、資産を奪ったりその他の悪意の理由のために弱点を悪用されるのを防ぐのに役立ちます。これらの記事は知るべきことを学ぶのに役立ちます。 この情報から、ウェブ開発を通じて、またそれ以外のコンテンツのデプロイにおいても、セキュリティの役割と重要性に気づくでしょう。

+ +
+
機密性、完全性、可用性
+
セキュリティを理解する上で絶対的な基礎となる、セキュリティの第一の目的を説明します。
+
セキュリティの制御
+
セキュリティ制御の主要なカテゴリを定義し、潜在的な欠点を議論します。
+
TCP/IP セキュリティ
+
SSL のセキュリティの考慮事項に焦点を当てた TCP/IP モデルの概要です。
+
脅威
+
主要な脅威の概念を簡単に案内します。
+
+ +
+
脆弱性
+
主要な分野の脆弱性を定義し、すべてのソフトウェアの脆弱性の存在を議論します。
+
+ +

関連情報

+ + + +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/insecure_passwords/index.html b/files/ja/web/security/insecure_passwords/index.html new file mode 100644 index 0000000000..ede48de515 --- /dev/null +++ b/files/ja/web/security/insecure_passwords/index.html @@ -0,0 +1,31 @@ +--- +title: 安全でないパスワード +slug: Web/Security/Insecure_passwords +tags: + - Insecure + - Intermediate + - Security + - Web + - password + - passwords +translation_of: Web/Security/Insecure_passwords +--- +

HTTP を通じてログインフォームを提供することは、ユーザーのパスワードを暴くための広範にわたる攻撃に対して特に危険です。ネットワークの盗聴者は、ネットワークを覗き見たり、転送によって提供されたページを変更したりしてユーザーのパスワードを盗むことができます。

+ +

{{glossary("HTTPS")}} プロトコルは、ネットワーク上での盗聴 (機密性) や改ざん (完全性) といった脅威から、ユーザーのデータを保護できるように設計されています。ユーザーのデータを扱うウェブサイトは、ユーザーを攻撃者から守るために HTTPS を使用してください。 HTTPS を使わなければ、ユーザーの情報 (ログインの資格情報など) が盗まれるのは当たり前になってしまいます。このことを Firesheep が証明したのは有名です。

+ +

この問題を修正するためには、 SSL/{{glossary("TLS")}} 証明書をサーバーにインストールし構成してください。様々なベンダーが無料または有料の証明書を提供しています。クラウドプラットフォームを使用しているのであれば、 HTTPS を有効にする方法を独自に持っているかもしれません。

+ +

パスワードの使い回しに関するメモ

+ +

ウェブサイトがユーザー名とパスワードを求めても、実際には微妙なデータを保存しないことがあります。例えば、あるニュースサイトがユーザーが読み返したい記事を保存しても、ユーザーに関する他のデータを保存しない場合などです。ニュースサイトのウェブ開発者は、サイトやユーザーの資格情報を安全にする必要があるとはあまり考えないかもしれません。

+ +

残念ながら、パスワードの使い回しは大きな問題です。ユーザーは複数のサイト (ニュースサイト、SNS、メールサービス、銀行) で同じパスワードを使用します。つまり、サイトが管理するユーザー名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行のウェブサイトでも同じパスワードでログインしているユーザーーにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザ名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。

+ +

関連情報

+ + + +

{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

diff --git a/files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html b/files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html new file mode 100644 index 0000000000..7a03322393 --- /dev/null +++ b/files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html @@ -0,0 +1,31 @@ +--- +title: 混在コンテンツでブロックされるウェブサイトを修正するには +slug: Web/Security/Mixed_content/How_to_fix_website_with_mixed_content +tags: + - HTTPS + - Security +translation_of: Web/Security/Mixed_content/How_to_fix_website_with_mixed_content +--- +

Firefox 23 より、 Firefox は能動的な混在コンテンツを既定でブロックします。この機能は Internet Explorer (バージョン 9 以降) や Chrome でも採用されています。

+ +

このページでは、ウェブ開発者として知っておくべきことを説明します。

+ +

ウェブサイトが壊れることも

+ +

ウェブサイトを HTTPS で配信している場合、ページ上にある 能動的な混在コンテンツはすべて既定でブロックされます。結果として、ユーザーからはそのウェブサイトが壊れているように見えるかもしれません (iframe やプラグインが読み込まれないなど)。一方、受動的な混在コンテンツは既定で表示されますが、このようなコンテンツをブロックするようにユーザーが設定することも可能です。

+ +

混在コンテンツは Chrome と Internet Explorer でもブロックされるため、ウェブサイトがこの２つのブラウザーで正常に動作していれば、混在コンテンツをブロックする Firefox でも正常に動作する可能性が高いと言えます。

+ +

いずれにしても、ウェブサイトが Firefox で動作しない原因を特定するには、最新の Firefox を利用すると良いでしょう。ウェブサイトを開いた上で、開発ツールのウェブコンソールを開き、「セキュリティ」のメッセージを有効にします。そうすると、混在コンテンツを引き起こしている原因が表示されます。また、 SSL-check や Missing Padlock などの無料のオンライン型クローラーや、 HTTPSChecker といったデスクトップ型のクローラー、または mcdetect などの CLI ツールを使用して、安全ではないコンテンツを指すリンクがないかどうか、ウェブサイトを再帰的に検索することが出来ます。もし混在コンテンツに関する警告が出なければ、ウェブサイトの品質は保たれていると言えます。今後も維持し続けてください。

+ +

ウェブサイトを修正する方法

+ +

混合コンテンツが原因でブロックされないためには、すべてのコンテンツを (HTTP ではなく) HTTPS で提供することが重要です。

+ +

自分が保有するドメインの場合、すべてのコンテンツが HTTPS で配信されるようにリンクを修正します。多くの場合、既にコンテンツは HTTPS として配信できるようになっているため、単に "s" を追加してリンクの http:// を https:// に変更するだけで対応できます。

+ +

しかし、場合によっては、問題のメディアに対してパスが正しくない可能性があります。 これを解決するためには、 linkchecker のようなオンラインツールとオフラインツール (オペレーティングシステムに依存します) があります。

+ +

他者が保有するドメインの場合、可能であれば HTTPS でウェブサイトに接続します。 HTTPS でアクセスできない場合は、 HTTPS を介してコンテンツを配信してもらえるよう、ドメインの管理者に連絡してみてください。

+ +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/mixed_content/index.html b/files/ja/web/security/mixed_content/index.html new file mode 100644 index 0000000000..02f276986b --- /dev/null +++ b/files/ja/web/security/mixed_content/index.html @@ -0,0 +1,83 @@ +--- +title: 混在コンテンツ +slug: Web/Security/Mixed_content +tags: + - HTTP + - HTTPS + - Security + - Web + - console +translation_of: Web/Security/Mixed_content +--- +

ユーザが {{Glossary("HTTPS")}} を通じてページにアクセスすると、ユーザとウェブサーバとの接続は {{Glossary("TLS")}} で暗号化され、盗聴や中間者攻撃から保護されます。HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、混在コンテンツと呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。つまり、ページは安全ではありません。

+ +

混在コンテンツの種類

+ +

混在コンテンツには 受動的な混在コンテンツ と 能動的な混在コンテンツ の 2 種類があります。この 2 つは、中間者攻撃によってコンテンツが改ざんされた場合に、最悪のケースとして脅威が影響を与える度合いで区別されます。受動的な混在コンテンツにおける脅威は低いものとなります (誤解を招くコンテンツが含まれているか、ユーザのクッキーが盗まれている可能性があります)。能動的な混在コンテンツの場合、その脅威としてフィッシングや機密情報の漏えい、悪意あるサイトへのリダイレクトなどが想定されます。

+ +

受動的な混在コンテンツ

+ +

受動的な混在コンテンツは、 HTTPS のウェブページの中で HTTP 経由で送信されるコンテンツです。しかし、そのウェブページの他の要素を混在コンテンツから変更することは出来ません。 例えば、HTTP で送信された画像に対して、攻撃者は別の不適切な画像やメッセージへと差し替えてユーザに表示させることが出来ます。 また、攻撃者はユーザへ送信される画像を盗聴することで、ユーザの行動に関する情報を推測することが可能です。 なぜなら、画像ファイルの置かれている場所がウェブサイト中のある特定のページに固定されていることがままあるからです。もし攻撃者が特定の画像に対する HTTP リクエストを覗き見れば、ユーザが閲覧しているウェブページを特定することが出来るでしょう。

+ +

受動的なコンテンツの一覧

+ +

受動的なコンテンツとされる HTTP リクエストは以下の通りです。

+ + + +

能動的な混在コンテンツ

+ +

能動的な混在コンテンツは、その HTTPS ページのすべて、ないしは DOM の一部にアクセスできるコンテンツです。このタイプの混在コンテンツは HTTPS ページの動作を変更することができ、ユーザから機密情報を窃取することも可能です。従って、先程説明した受動的な混在コンテンツによる脅威に加え、能動的な混在コンテンツには他の攻撃ベクタへ向けた脆弱性が存在します。

+ +

能動的な混在コンテンツの場合、中間者攻撃の攻撃者はまず HTTP のコンテンツへのリクエストを横取りすることが出来ます。 その後、攻撃者はレスポンスを改ざんして悪意ある JavaScript コードを含めることも可能です。悪意ある能動的なコンテンツは、ユーザーのログイン情報を窃取したり、ユーザーに関する機密情報を取得したり、ユーザのマシンにマルウェアのインストールを試みることが出来ます (例えば、ブラウザーやそのプラグインの脆弱性を利用することが考えられます)。

+ +

混在コンテンツに関係するリスクは、ユーザが閲覧しているウェブサイトの種類と、そのサイトにどれだけ機微な情報が含まれているかに依存します。そのウェブページには世界中に公開されているデータもあれば、認証された時のみアクセスできる機密情報もあるでしょう。 もしウェブページが公開されていて機微なデータは何もなかった場合でも、攻撃者は能動的な混在コンテンツを利用することにより、ユーザを他の HTTP ページへリダイレクトさせたり、 HTTP cookie をサイトから窃取したりできてしまうのです。

+ +

能動的な混在コンテンツの例

+ +

能動的なコンテンツとされる HTTP リクエストのうち、代表的なものは以下の通りです。

+ + + +

Chrome と同様に、ウェブフォントやワーカーのようなリソースタイプも能動的なコンテンツとみなされます。

+ +

ウェブコンソール内の警告

+ +

閲覧しているページに混在コンテンツが含まれていた場合、Firefox のウェブコンソールには警告が表示されます。 HTTP 経由で読み込まれた混在コンテンツのリソースは赤色で表示され、このページへのリンクである「混在コンテンツ」の文字列が併記されます。

+ +

Screen shot of the web console displaying a mixed content warning.

+ +

これらの警告をウェブコンソールで見つけるのと同様に、 Content Security Policy (CSP) を使用して問題を報告することができます。 SSL-check や Missing Padlock のようなオンラインクローラーと使用すると、ウェブサイトを再帰的にチェックし、安全ではないコンテンツのリンクを探すことができます。

+ +

Firefox 23 以降より、能動的な混在コンテンツはデフォルトでブロックされるようになりました (受動的な混在コンテンツは設定によりブロック可能です)。ウェブ開発者が混在コンテンツのエラーに気付きやすくなるよう、ブロックされた混在コンテンツへのリクエストはウェブコンソールのセキュリティペインにすべて記録されます。

+ +

A screenshot of blocked mixed content errors in the Security Pane of the Web Console

+ +

このエラーを修正するには、 HTTP コンテンツへのリクエストをすべて HTTPS コンテンツへのリクエストに差し替えてください。よくある混在コンテンツには JavaScript ファイルやスタイルシート、画像、動画、その他のメディアファイルなどがあります。

+ +
+

注: Firefox 55 以降、 http://127.0.0.1/ で混在コンテンツの読み込みが許可されました ({{bug(903966)}} を参照)。 Chrome は http://127.0.0.1/ 及び http://localhost/ で混在コンテンツを許可しています。 Safari は混在コンテンツを許可しません。

+
+ +

関連情報

+ + + +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/public_key_pinning/index.html b/files/ja/web/security/public_key_pinning/index.html new file mode 100644 index 0000000000..4741133a6b --- /dev/null +++ b/files/ja/web/security/public_key_pinning/index.html @@ -0,0 +1,163 @@ +--- +title: HTTP Public Key Pinning (HPKP) +slug: Web/Security/Public_Key_Pinning +tags: + - Deprecated + - Guide + - HPKP + - HTTP + - Obsolete + - Security +translation_of: Web/HTTP/Public_Key_Pinning +--- +

{{HTTPSidebar}}{{deprecated_header}}

+ +
注: Public Key Pinning の仕組みは Certificate Transparency および {{HTTPHeader("Expect-CT")}} ヘッダーに置き換えられ、非推奨になりました。
+ +

HTTP Public Key Pinning ({{Glossary("HPKP")}}) は、ウェブクライアントに特定の公開鍵をあるウェブサーバーに関連付けさせることで、偽造された証明書による{{Glossary("MITM", "中間者攻撃")}}のリスクを減少させるためのセキュリティ機能でした。これは最近のブラウザーでは削除され、対応がなくなりました。

+ +

{{Glossary("TLS")}} セッションで用いられるサーバーの公開鍵の真正性を担保するため、通常その公開鍵は認証局 ({{GLossary("CA")}}) の証明書でラップされます。ブラウザーなどのウェブクライアントがこれらの認証局を信頼することで、認証局は任意のドメイン名に対する証明書を作成できます。攻撃者が1つの認証局を危殆化させることができれば、様々な TLS コネクションで中間者攻撃を仕掛けることが可能になってしまいます。 HPKP はこの {{Glossary("HTTPS")}} プロトコルへの脅威を、そのウェブサーバーにどの公開鍵が所属するのかをクライアントに伝えることで回避することができます。

+ +

HPKP は Trust on First Use ({{Glossary("TOFU")}}) 技術の1つです。 HPKP の HTTP ヘッダーがウェブサーバーからクライアントへ最初に送信されて以降、そのウェブサーバーに紐付く公開鍵はクライアントで一定期間記憶されます。クライアントが再びそのサーバーを訪れた際は、既に HPKP で記憶したフィンガープリントと一致する公開鍵が、証明書チェインにおいて最低 1 つの証明書に含まれていることを確認します。そのサーバーから送信されてきた公開鍵が不明なものだった場合、クライアントはユーザーに警告を表示します。

+ +

Firefox および Chrome は、認証された証明書チェーンが (内蔵の証明書ではなく) ユーザー定義の証明書であった場合、ピン留めによる認証を無効化します。つまり、独自のルート証明書をインポートしたユーザーに対しては、ピン留めによる警告が表示されません。

+ +

HPKP の有効化

+ +

サイトでこの機能を有効化するには、サイトに HTTPS でアクセスされたとに、 HTTP の {{HTTPHeader("Public-Key-Pins")}} ヘッダーを返す必要があります。

+ +
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]
+ +
+
pin-sha256
+
二重引用符で囲まれた文字列で、 Base64 符号化された Subject Public Key Information ({{Glossary("SPKI")}}) のフィンガープリントです。異なる公開鍵に対する複数のピンを指定することが出来ます。将来のブラウザーでは SHA-256 以外のハッシュアルゴリズムが許容されるかもしれません。証明書や鍵ファイルからこの情報を抽出する方法は次の項で説明します。
+
max-age
+
このサイトへのアクセス時に必要となる（唯一ピン留めされた）鍵について、この鍵をブラウザーが記憶するべき時間を指定します。この値は秒単位で表現します。
+
includeSubDomains {{optional_inline}}
+
このパラメータは省略可能です。サイトにおけるすべてのサブドメインにもこのルールが適用されます。
+
report-uri {{optional_inline}}
+
このパラメータは省略可能です。ピンの検証に失敗した際に、失敗した旨を報告する URL を指定します。
+
+ +
+

注: 現在の仕様では、本番系で運用されていないバックアップ用の第2のピンを指定することが必須になっています。これにより、既にピンを持っているクライアントからのアクセス性を損なうことなく、サーバの公開鍵を変更することが可能になります。例えば、本番系の鍵が危殆化したときなどに重要となります。

+
+ +

Base64 エンコードされた公開鍵情報を抽出するには

+ +
+

注: 以下の例ではサーバ証明書をピン留めする方法を説明していますが、証明書の更新やローテーションを容易にするため、サーバ証明書を発行した CA の中間証明書もピン留めすることを推奨します。

+
+ +

まずは証明書や鍵ファイルから公開鍵情報を抽出し、それを Base64 でエンコードする必要があります。

+ +

次に示す便利なコマンドで、鍵ファイルや証明書署名要求 (CSR)、または証明書から Base64 エンコードされた情報を抽出できます。

+ +
openssl rsa -in my-rsa-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl ec -in my-ecc-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl req -in my-signing-request.csr -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl x509 -in my-certificate.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +

以下のコマンドを用いると、ウェブサイト向けに情報を抽出することができます。

+ +
openssl s_client -servername www.example.com -connect www.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +

HPKP ヘッダーの例

+ +
Public-Key-Pins:
+  pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=";
+  pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=";
+  max-age=5184000; includeSubDomains;
+  report-uri="https://www.example.org/hpkp-report"
+ +

この例では、 pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=" で本番系で使用されるサーバーの公開鍵をピン止めします。２番目のピン宣言である pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=" も、バックアップキーをピン止めします。 max-age=5184000 はクライアントにこの情報を２か月間保存するように伝え、これは IETF RFC によれば合理的な期間です。このキーのピン止めは、 includeSubDomains 宣言で指示されているように、すべてのサブドメインでも有効です。最後に、 report-uri="https://www.example.net/hpkp-report" はピンの検証の失敗を報告する場所を説明します。

+ +

Report-Only ヘッダー

+ +

{{HTTPHeader("Public-Key-Pins")}} ヘッダーを用いる代わりに、 {{HTTPHeader("Public-Key-Pins-Report-Only")}} ヘッダーを利用することも可能です。このヘッダーを用いた場合、ピン留めの認証に失敗した場合でも指定した report-uri にレポートが送信されるのみで、ブラウザーがウェブサーバーへ接続することは可能となります。

+ +

HPKP ヘッダーを送信するためのウェブサーバーの設定

+ +

HPKP ヘッダーを送信するのに必要な具体的な手順はウェブサーバーによって異なります。

+ +
+

注: 以下の例では、2か月間の max-age と includeSubDomains を指定しています。自身のサーバに合った適切な設定をしてください。

+
+ +
+

HPKP の設定を間違えると、ユーザーが長期間接続できなくなってしまう可能性があります！バックアップの証明書を用意したり、CA の証明書をピン留めすることを推奨します。

+
+ +

Apache

+ +

次のような行をウェブサーバーの config に追加すると Apache で HPKP が有効になります。 mod_headers モジュールがインストールされている必要があります。

+ +
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
+ +

Nginx

+ +

次のような行を追加し、適切な pin-sha256="..." の値を設定すると nginx で HPKP が有効になります。 ngx_http_headers_module がインストールされている必要があります。

+ +
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains' always;
+ +

Lighttpd

+ +

鍵に関する次のような情報 (pin-sha256="..." フィールド) を含む行を追加すると、 lighttpd で HPKP が有効になります。

+ +
setenv.add-response-header  = ( "Public-Key-Pins" => "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")
+ +

注: 以下のように server.module で mod_setenv をあらかじめ読み込んでおく必要があります。

+ +
server.modules += ( "mod_setenv" )
+ +

IIS

+ +

IIS から Public-Key-Pins ヘッダーを送信するには、以下のような数行を Web.config ファイルに追加してください。

+ +
<system.webServer>
+  ...
+
+  <httpProtocol>
+    <customHeaders>
+      <add name="Public-Key-Pins" value="pin-sha256=&quot;base64+primary==&quot;; pin-sha256=&quot;base64+backup==&quot;; max-age=5184000; includeSubDomains" />
+    </customHeaders>
+  </httpProtocol>
+
+  ...
+</system.webServer>
+
+ +

仕様書

+ + + + + + + + + + + + + + +
仕様書題名
{{RFC("7469", "Public-Key-Pins", "2.1")}}Public Key Pinning Extension for HTTP
+ +

ブラウザーの互換性

+ + + +

{{Compat("http.headers.Public-Key-Pins")}}

+ +

関連情報

+ + diff --git a/files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html b/files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html new file mode 100644 index 0000000000..051493d501 --- /dev/null +++ b/files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html @@ -0,0 +1,58 @@ +--- +title: Referer ヘッダーのプライバシーとセキュリティの考慮事項 +slug: 'Web/Security/Referer_header:_privacy_and_security_concerns' +tags: + - Privacy + - Referrer Policy + - Security + - referer + - referrer + - セキュリティ + - プライバシー +translation_of: 'Web/Security/Referer_header:_privacy_and_security_concerns' +--- +

HTTP の Referer ヘッダーにまつわるプライバシーとセキュリティのリスクがあります。この記事ではこれらを説明し、これらのリスクを回避するためのアドバイスを提案します。

+ +

リファラー問題

+ +

{{httpheader("Referer")}} (綴りに注意) ヘッダーには現在リクエストされているページへのリンクをたどる元のウェブページのアドレスが含まれています。これには、分析、ログ、キャッシュの最適化など、問題のない用途がかなりあります。しかし、情報の追跡や盗用など、もっと問題になる用途や、誤って機密情報を漏らすなどの副作用もあります。

+ +

例えば、フッターにソーシャルメディアへのリンクがある「パスワードリセット」ページを想像してみてください。リンクをクリックすると、情報を共有する方法によっては、ソーシャルメディアサイトがパスワードをリセットする URL を受け取り、共有された情報が使用されると、ユーザーのセキュリティを侵害する恐れがあります。

+ +

同じ論理で、サードパーティ側でホストされている画像がページに埋め込まれている場合、機密情報がサードパーティに漏洩する可能性があります。たとえセキュリティが損なわれていなくても、その情報はユーザーが共有してほしくないものかもしれません。

+ +

どのように対処できるか

+ +

このリスクの多くは、アプリケーションの賢明な設計によって軽減することができます。賢明なアプリケーションは、パスワードリセット URL を一度だけの使用、または一意のユーザートークンと組み合わせた場合にのみ使用可能にし、機密データを異なる方法で送信することで、このようなリスクを取り除くことができます。

+ +

URL 経由で他の場所に機密データを渡すことを避けるために、可能な限り {{HTTPMethod("GET")}} ではなく {{HTTPMethod("POST")}} を使用すべきです。

+ +

サイトには常に {{glossary("HTTPS")}} を使用してください。これには多くのセキュリティ上の利点がありますが、HTTPS サイトは参照元情報を HTTPS 以外のサイトには決して送信しないという事実もあります。Web のほとんどが HTTPS を使用するようになった現在では、これはあまり意味をなさなくなってきていますが、それでも検討する価値はあります。

+ +

さらに、パスワードリセットページ、支払いフォーム、ログインエリアなど、Web サイトの安全な領域からサードパーティのコンテンツ ({{htmlelement("iframe")}} に埋め込まれたソーシャルネットワーキングウィジェットなど) を削除することを検討する必要があります。

+ +

また、このようなリスクを軽減するには、次のような方法があります。

+ + + +

セキュリティを意識したサーバーサイドのフレームワークは、例えば、このような問題を緩和するための機能が組み込まれていることが多いです。

+ + + +

ポリシーと要件

+ +

プロジェクトチームのために、関連するリスクを軽減するために、そのような機能の使用方法を指定したセキュリティとプライバシーの要件を書くことは理にかなっているでしょう。これらの要件を書くためには、ウェブセキュリティの専門家の助けを借りて、ユーザーのニーズと福祉の両方を考慮し、EU 一般データ保護規則 (GDPR) のような法律で施行されているポリシーや規制のような他の問題も考慮する必要があります。

+ +

あわせて参照

+ + diff --git a/files/ja/web/security/same-origin_policy/index.html b/files/ja/web/security/same-origin_policy/index.html new file mode 100644 index 0000000000..42ebea014a --- /dev/null +++ b/files/ja/web/security/same-origin_policy/index.html @@ -0,0 +1,272 @@ +--- +title: 同一オリジンポリシー +slug: Web/Security/Same-origin_policy +tags: + - CORS + - Host + - JavaScript + - Same-origin policy + - Security + - URL + - origin + - secure +translation_of: Web/Security/Same-origin_policy +--- +
{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}
+ +

同一オリジンポリシーとは、あるオリジンから読み込まれた文書やスクリプトについて、そのリソースから他のオリジンのリソースにアクセスできないように制限するものです。同一オリジンポリシーはウェブのセキュリティにおける重要な仕組みであり、悪意ある行動を起こしかねないリソースの分離を目的としています。

+ +

オリジンの定義

+ +

二つのページの{{Glossary("protocol", "プロトコル")}}、{{Glossary("port", "ポート番号")}} (もしあれば)、{{Glossary("host", "ホスト")}}が等しい場合、両者のページは同じオリジンです。これは「スキーム/ホスト/ポート番号のタプル」または時に単に「タプル」として参照されます (「タプル」は共に全体を構成する三つの部分の組み合わせを表します)。

+ +

以下の表は、各行の URL が http://store.company.com/dir/page.html と同じオリジンであるかを比較したものです。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
URL結果理由
http://store.company.com/dir2/other.html同一オリジンパスだけが異なる
http://store.company.com/dir/inner/another.html同一オリジンパスだけが異なる
https://store.company.com/page.html不一致プロトコルが異なる
http://store.company.com:81/dir/page.html不一致ポート番号が異なる (http:// は既定で80番ポート)
http://news.company.com/dir/page.html不一致ホストが異なる
+ +

オリジンの継承

+ +

about:blank や javascript: の URL のページから実行されたスクリプトは、その URL にオリジンのサーバーについての情報が明示的に含まれていないため、その URL を開いた文書のオリジンを継承します。

+ +
+

例えば、 about:blank は (例えば {{domxref("Window.open()")}} メカニズムを使用して) 新しい空のポップアップウィンドウを生成し、その中に親スクリプトがコンテンツを書き込むために使用されます。ポップアップウィンドウにもコードが含まれた場合、そのコードはそれを生成したスクリプトと同じオリジンを継承します。 +

+ +
+

data: の URL は新しく、空のセキュリティコンテキストを生成します。

+
+ +

IE における例外事項

+ +

Internet Explorer では、同一オリジンポリシーについて二つの大きな例外があります。

+ +
+
信頼済みゾーン
+
双方のドメインが高く信頼されたゾーン (企業のドメインなど) である場合は、同一オリジンの制限が適用されません。
+
ポート番号
+
IE は同一オリジンの確認要素にポート番号を含みません。従って、 http://company.com:81/index.html と http://company.com/index.html は同一オリジンとみなされ、制限は適用されません。
+
+ +

これらの例外事項は標準外であり、他のブラウザーはこのような挙動に対応していません。

+ +

オリジンの変更

+ +

ページのオリジンは、いくつかの制限の下で変更されることがあります。スクリプトを用いると、 {{domxref("document.domain")}} の値を現在のドメインまたは上位ドメインに変更できます。スクリプトによって現在のドメインの上位ドメインへオリジンが変更された場合、より短くなったドメイン名は次回のオリジン検査時に用いられます。

+ +

例えば、 http://store.company.com/dir/other.html にあるドキュメント内のスクリプトが以下のコードを実行したと仮定します。

+ +
document.domain = "company.com";
+
+ +

このコードが実行された後、そのページは http://company.com/dir/page.html におけるオリジンの検査を通過できます (許可を明示するために http://company.com/dir/page.html が自身の document.domain を "company.com" に変更したと仮定します。詳しくは {{domxref("document.domain")}} を参照してください)。しかし、 company.com が自身のdocument.domain を othercompany.com に変更することはできません。なぜなら company.com の上位ドメインではないためです。

+ +

ブラウザーはポート番号を個別に検査します。 document.domain を呼び出すと、 document.domain = document.domain の場合も含め、ポート番号が null で上書きされます。従って、スクリプトの最初に document.domain = "company.com" を設定しただけでは、 company.com:8080 と company.com とは互いにアクセスできません。双方のポートが null になるように、双方で設定しなければなりません。

+ +
+

注: サブドメインから安全に親ドメインへアクセスさせるために document.domain を使用する際は、親ドメインとサブドメインの双方で同じ値を document.domain に設定することが必要です。この作業は、単に親ドメインを元の値に戻す際にも必要です。これを怠ると権限エラーが発生します。

+
+ +

異なるオリジンへのネットワークアクセス

+ +

{{domxref("XMLHttpRequest")}} や {{htmlelement("img")}} 要素を使用する場合など、 同一オリジンポリシーは 2 つのオリジン間における通信を制御します。一般にこれらの通信は 3 つのカテゴリに分類されます。

+ + + +

以下に挙げるのは、異なるオリジンに埋め込むことができるリソースの例です。

+ + + +

異なるオリジンへのアクセスを許可する方法

+ +

異なるオリジンへのアクセスを許可するには、 CORS を使用してください。 CORS は {{Glossary("HTTP")}} の一部で、サーバーがクライアントに、どのホストがそのサーバーからコンテンツを読み込むことが許可されているかを共有する機能です。

+ +

異なるオリジンへのアクセスをブロックする方法

+ + + +

異なるオリジンへのスクリプトからの API によるアクセス

+ +

{{domxref("HTMLIFrameElement.contentWindow", "iframe.contentWindow")}}, {{domxref("window.parent")}}, {{domxref("window.open")}}, {{domxref("window.opener")}} といった JavaScript API を用いると、ドキュメントが直接互いに参照することができます。2 つのドキュメントが同一のオリジンではない場合、 {{domxref("Window")}} オブジェクトや {{domxref("Location")}} オブジェクトなど、限られたオブジェクトにのみアクセスすることができます。詳しくは次の 2 つのセクションで説明します。

+ +

{{domxref("window.postMessage")}} を使用すると、異なるオリジンの文書間における通信がさらに可能となります。

+ +

仕様書: HTML Living Standard § Cross-origin objects.

+ +

Window

+ +

以下に示した Window のプロパティは、異なるオリジンからのアクセスが許可されています。

+ + + + + + + + + + + + + + + + + + + + + +
メソッド
{{domxref("window.blur")}}
{{domxref("window.close")}}
{{domxref("window.focus")}}
{{domxref("window.postMessage")}}
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
属性
{{domxref("window.closed")}}読み取り専用
{{domxref("window.frames")}}読み取り専用
{{domxref("window.length")}}読み取り専用
{{domxref("window.location")}}読み取り/書き込み
{{domxref("window.opener")}}読み取り専用
{{domxref("window.parent")}}読み取り専用
{{domxref("window.self")}}読み取り専用
{{domxref("window.top")}}読み取り専用
{{domxref("window.window")}}読み取り専用
+ +

一部のブラウザーでは、仕様書で定められたものより多くのプロパティでアクセスが許可されています。

+ +

Location

+ +

以下に示した Location のプロパティは、異なるオリジンからのアクセスが許可されています。

+ + + + + + + + + + + + +
メソッド
{{domxref("location.replace")}}
+ + + + + + + + + + + + + + +
属性
{{domxref("URLUtils.href")}}書き込みのみ
+ +

一部のブラウザーでは、仕様書で定められたものより多くのプロパティでアクセスが許可されています。

+ +

オリジンをまたいだデータストレージアクセス

+ +

ウェブストレージや IndexedDB など、ブラウザー内部に保存されるデータへのアクセスは、オリジンによって権限が分かれています。それぞれのオリジンが個別にストレージを持ち、あるオリジンの JavaScript から別のオリジンに属するストレージを読み書きすることはできません。

+ +

{{glossary("Cookie", "Cookie")}} におけるオリジンの定義は異なります。ページは自身のドメインまたは任意の親ドメイン (親ドメインが public suffix ではない場合に限る) 用の Cookie を設定できます。 ドメインが public suffix であるかを判断する際、Firefox と Chrome は Public Suffix List を使用します。 Internet Explorer は独自の方法で public suffix であるかを判断します。使用しているスキーム (HTTP/HTTPS) やポートに関係なく、ブラウザーはサブドメインも含めて Cookie を使用可能にします。Cookie の設定時に Domain, Path, Secure, HttpOnly の各フラグを用いることで、その Cookie の利用範囲を制限できます。Cookie を読み取るとき、Cookie を設定した場所から知ることはできません。安全な https 接続のみ使用していたとしても、参照している Cookie は安全でない接続を通じて設定された可能性があります。

+ +

関連情報

+ + + +
+

出典情報

+ + +
diff --git a/files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html b/files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html new file mode 100644 index 0000000000..8eb04d2a59 --- /dev/null +++ b/files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html @@ -0,0 +1,236 @@ +--- +title: 安全なコンテキストに制限されている機能 +slug: Web/Security/Secure_Contexts/features_restricted_to_secure_contexts +tags: + - API + - Browsers + - Reference + - Secure contexts + - Security + - Web + - features + - support + - セキュリティ + - ブラウザー + - 安全なコンテキスト +translation_of: Web/Security/Secure_Contexts/features_restricted_to_secure_contexts +--- +

このリファレンスは、安全なコンテキストでのみ使用できるウェブプラットフォーム機能の一覧です — 定義や詳細については、安全なコンテキストを参照してください。

+ +

安全なコンテキストでのみ使用できる現在の機能

+ +

この節では、安全なコンテキストでのみ利用できる API の一覧を、制限が導入されたブラウザーのバージョンと共に示します。

+ +
+

メモ: 実際に安全なコンテキストに対応しているブラウザーのみ表示しています。安全なコンテキストの対応の詳細はこちらをご覧ください。

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
APIChrome/OperaEdgeSafariFirefox
Async Clipboard API66対応なし対応なし63
Background Sync (例えば {{domxref("SyncManager")}} を参照)49対応なし対応なし対応なし
Cache-Control: immutable対応なし151149
Credential Management API51対応なし対応なし対応なし
Generic Sensor API67対応なし対応なし対応なし
Payment Request API (および Basic Card Payment)611511.1開発中 (dom.payments.request.enabled の設定で隠蔽)。
プッシュ API4217対応なし44
Reporting API対応あり対応なし対応なしFirefox 65 以降はフラグで隠ぺい
サービスワーカー401711.144
Storage API55対応なし対応なし51
Web Authentication API65In preview (17)開発中60
Web Bluetooth56対応なし対応なし対応なし
Web MIDI (たとえば、 {{domxref("MIDIAccess")}} を参照)43対応なし対応なし対応なし
Web Crypto API 6079対応なし75
+ +

ブラウザー独自の安全なコンテキストの制限

+ +

ブラウザーによっては、仕様書の要件になくても、特定の API を安全ではないコンテキストでは無効にしたり、その他の制限やセキュリティ要件を課したりしていることがあります。この節では、ブラウザーによって違いがあるものの一覧を示しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
APIChromeEdgeSafariFirefox
Application CacheChrome 70 で安全なコンテキストに限定することを計画中2018年2月に非推奨化の検討が開始非推奨化に対する一般の関心 {{webkitbug(182442)}}Firefox 62 で安全なコンテキストに限定
{{domxref("Geolocation")}}50で安全なコンテキストに限定10で安全なコンテキストに限定55で安全なコンテキストに限定
Device Orientaion / Device Motion非推奨の警告60から非推奨の警告。なお、これは安全なコンテキストでも同様に適用されます。
Encrypted Media Extensions58で安全なコンテキストに限定計画中。
getUserMedia()Chrome 47 以降、安全なコンテキストに限定一時的なアクセスのみ可能 (ユーザーは許可ダイアログで "この設定を記憶する" を選べない)。
NotificationsChrome 62 で安全なコンテキストに限定Firefox 67 で安全なコンテキストに限定
<a ping> 属性安全でないコンテキストでは無効Firefox 3 で対応が追加、但し既定では有効化されていない (browser.send_pings の設定で隠蔽)。
Presentation61 で非推奨の警告
Web Crypto API早期から HTTPS に限定 (API は HTTP で見えたが、操作には失敗した)。 Chrome 60 で安全なコンテキストに限定 (API は安全ではないコンテキストから見えなくなった).計画中。
registerProtocolHandler()Firefox 62 で安全なコンテキストに限定。
+ +

関連情報

+ + + +
{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}
diff --git a/files/ja/web/security/secure_contexts/index.html b/files/ja/web/security/secure_contexts/index.html new file mode 100644 index 0000000000..8c6576066a --- /dev/null +++ b/files/ja/web/security/secure_contexts/index.html @@ -0,0 +1,77 @@ +--- +title: 安全なコンテキスト +slug: Web/Security/Secure_Contexts +tags: + - Secure contexts + - Security + - セキュリティ + - 安全なコンテキスト +translation_of: Web/Security/Secure_Contexts +--- +

セキュアコンテキストとは、認証と機密性の一定の最低基準を満たしている Window や Worker のことです。多くの Web API や機能は安全なコンテキストでのみアクセス可能です。セキュアコンテキストの主な目的は、{{interwiki("wikipedia", "中間者攻撃", "中間者攻撃")}} が攻撃の犠牲者をさらに危険にさらす可能性のある強力な API にアクセスすることを防ぐことです。

+ +

機能をアクセス制限すべき理由

+ +

Web の API には強力なものもあり、攻撃者に対して以下のような (それよりも多くの) 能力を与えてしまう可能性があります。

+ + + +

コンテキストが安全とみなされるのはいつですか？

+ +

コンテキストは、Secure Contexts 仕様で定義されている認証および機密性の一定の最低基準を満たしている場合に、セキュアなコンテキストとみなされます。特定の文書がセキュアコンテキストであるトップレベルのブラウジングコンテキスト (基本的には、セキュアコンテキストであるウィンドウやタブを含むコンテキスト) のアクティブな文書である場合、その文書はセキュアコンテキストにあるとみなされます。

+ +

例えば、{{HTMLElement("iframe")}} 内で TLS 上で配信された文書であっても、TLS 上で配信されなかった祖先がある場合には、そのコンテキストは安全であるとは見なされません。

+ +

しかし、安全ではないコンテキストによって (noopener を指定してもしなくても) 新しいウィンドウが作成された場合、 オープナーが安全ではないという事実は、新しいウィンドウが安全であるとみなされるかどうかに影響を与えないことに注意してください。これは、特定の文書が安全なコンテキストにあるかどうかの判断は、それが関連付けられているトップレベルのブラウジングコンテキスト内でそれを考慮することにのみ基づいており、安全でないコンテキストがたまたまその文書を作成するために使用されたかどうかではないからです。

+ +

http://127.0.0.1 の URL、http://localhost の URL (一定の条件の下で)、file:// の URL など、ローカルに配信されたリソースも安全に配信されていると考えられます。

+ +

ローカルではないリソースが安全であるとみなされるためには、以下の基準を満たす必要があります。

+ + + +

機能の判別

+ +

グローバルスコープで利用できる {{domxref("WindowOrWorkerGlobalScope.isSecureContext", "isSecureContext")}} の真偽値を用いることで、そのページ自身が安全なコンテキストの中にいるかどうか確かめることができます。

+ +
if (window.isSecureContext) {
+  // Service Worker が実行されているので、このページは安全なコンテキストです
+  navigator.serviceWorker.register("/offline-worker.js").then(function () {
+    ...
+  });
+}
+ +

仕様

+ + + + + + + + + + + + + + +
仕様書状態備考
{{SpecName('Secure Contexts')}}{{Spec2('Secure Contexts')}}編集者による草稿
+ +

関連情報

+ + + +
{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}
diff --git a/files/ja/web/security/securing_your_site/index.html b/files/ja/web/security/securing_your_site/index.html new file mode 100644 index 0000000000..8d375d18b7 --- /dev/null +++ b/files/ja/web/security/securing_your_site/index.html @@ -0,0 +1,54 @@ +--- +title: サイトの安全化 +slug: Web/Security/Securing_your_site +tags: + - HTTP + - Security + - Web Development + - Website Security +translation_of: Web/Security/Securing_your_site +--- +
{{ draft() }}
+ +

サイトをより安全にする方法はいくつもあります。この記事はその方法を紹介するとともに他のより有益な記事へのリンクを掲載しています。

+ +
メモ: この記事は作成途中であり、以下の事項に従うことによりあなたのサイトが完全にセキュアになることを保証するものではありません。
+ +

ユーザー情報のセキュリティ

+ +
+
フォームオートコンプリートを無効にするには
+
Geckoではフォームのオートコンプリートがサポートされています。つまり、ユーザがフォームに入力した値を記憶し、次回訪問時には自動的にその値が入力されることになります。ある特定のデータに関しては、この機能を無効にしたほうが適切かもしれません。
+
プライバシーと :visited セレクター
+
この記事では悪質なサイトがユーザーの閲覧履歴を取得できないようにするために getComputedStyle() メソッドに加えられた変更について議論しています。
+
安全なアルゴリズムを使用したパスワードのハッシュ (OWASP)
+
プレーンテキストでパスワードを格納すると、攻撃者がサイトのユーザーの正確なパスワードを知り、漏洩させることにつながり、ユーザーを危険にさらすことになります。古く安全ではないハッシュアルゴリズム (md5 など) を使用すると、同じ問題が浮上します。メッセージダイジェストアルゴリズム (md5 や sha) ではなくパスワード専用のハッシュアルゴリズム (Argon2, PBKDF2, scrypt, bcrypt など) を使用するようにしてください。この記事はパスワードを格納するときに使用することができるベストプラクティスのショーケースです。
+
+ +

コンテンツセキュリティ

+ +
+
サーバーの MIME タイプを正しく設定する
+
MIME タイプを正しく設定しないと、幾つかの潜在的なセキュリティ上の問題が発生します。この記事ではそのうちのいくつかを紹介し、サーバーで MIME タイプを正しく設定する方法を示します。
+
HTTP Strict Transport Security
+
Strict-Transport-Security: HTTP ヘッダーを使うと、そのサイトが HTTPS でのみアクセスされるべきであるということを示すことができます。
+
HTTP アクセス制御
+
Cross-Origin Resource Sharing 標準はどのコンテンツが他のドメインから読み込まれるかを示す方法を提供します。この仕組みによりあなたのサイトが意図せず使われることを防いだり、明示的に使用を許可できます。
+
Content Security Policy
+
{{Glossary("Cross-site_scripting", "クロスサイトスクリプティング (XSS)")}} やデータインジェクション攻撃を含む、特定の攻撃を検知したり軽減したりすることができる追加のセキュリティレイヤーです。これらの攻撃は、データの窃盗からサイトの改ざんやマルウェアの配布まで、あらゆることに利用されます。コードは被害者によって実行され、攻撃者がアクセス制御をバイパスしたり、成りすまししたりすることができるようになります。 Open Web Application Security Project によれば、 XSS は2017年によくあるウェブアプリの脆弱性の第7位でした。
+
X-Frame-Options レスポンスヘッダー
+
+

X-Frame-Options: HTTP レスポンスヘッダーはページを {{ HTMLElement("frame") }} 内に描画して良いかどうかを示すために使われます。これを使うことにより、自身のサイトが他のサイトに埋め込まれていないことを保証できるため、クリックジャッキングを防ぐことができます。

+
+
ウェブサイトの構成によるアクセス制御
+
これはサイトを安全にするのに最良の方法です。 IP アドレスのブラックリスト、ウェブサイトの特定の領域へのアクセス制御、様々なファイルの保護、画像のホットリンクの防止、その他多数です。例えば、 Apache HTTP Server でホスティングされているウェブサイトでは .htaccess ファイルが使用されます。
+
+ +

関連情報

+ + + +
{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}
diff --git a/files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html b/files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html new file mode 100644 index 0000000000..642f8b3317 --- /dev/null +++ b/files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html @@ -0,0 +1,74 @@ +--- +title: フォームの自動補完を無効にするには +slug: Web/Security/Securing_your_site/Turning_off_form_autocompletion +tags: + - Forms + - Guide + - Security + - Web Development + - ウェブ開発 + - セキュリティ + - フォーム +translation_of: Web/Security/Securing_your_site/Turning_off_form_autocompletion +--- +

この記事では、フォーム入力欄の自動補完をウェブサイト側から無効にする方法を説明します。

+ +

既定では、ウェブサイト上の {{HTMLElement("input")}} 欄を通じてユーザーが送信した情報はブラウザーによって記憶されます。これよってブラウザーは、自動補完 (入力を受けた入力欄の補完候補をユーザーに提示する機能) や、オートフィル (読み込まれた入力欄をあらかじめブラウザーが補完する機能) を実現しています。

+ +

これらの機能は通常は既定で有効ですが、ユーザーのプライバシーにかかわる可能性があるため、ブラウザーは無効にすることができます。しかしながら、フォームで送信される情報の中には将来利用する価値のないもの (ワンタイムパスワードなど) や、機微な情報 (公的な識別番号やクレジットカード番号など) があります。ブラウザーの自動補完機能が有効であっても、ウェブサイトの作者としては、そのような入力欄の値をブラウザーに記憶させないほうが適切かもしれません。

+ +

自動補完を無効にすると、 WCAG 2.1 の 1.3.5: Identify Input Purpose の規則を破ることになることを知っておくことが重要です。 WCAG に従うウェブサイトを制作するのであれば、自動的に記入する自動補完を使用するべきです。

+ +

自動補完の無効化

+ +

フォームにおける自動補完を無効にするには、 autocomplete 属性に "off" を指定することで実現できます。

+ +
autocomplete="off"
+ +

上記の設定はフォーム全体に適用することも、特定の input 要素に指定することも可能です。

+ +
<form method="post" action="/form" autocomplete="off">
+[…]
+</form>
+ +
<form method="post" action="/form">
+  […]
+  <div>
+    <label for="cc">クレジットカード番号:</label>
+    <input type="text" id="cc" name="cc" autocomplete="off">
+  </div>
+</form>
+ +

入力欄に autocomplete="off" を指定すると、以下の 2 つの効果が生じます。

+ + + +

autocomplete を off に設定してもブラウザーがサジェスト値を表示し続ける場合は、 input 要素の name 属性を変更する必要があります。

+ +

autocomplete 属性とログイン欄

+ +

現代的なブラウザーでは、パスワードを一括管理する機能が実装されています。ユーザーがウェブサイトでユーザー名とパスワードを入力した際、ブラウザーはその値を記憶するかユーザーに尋ねます。ユーザーがそのウェブサイトを再び訪れた際には、ログイン欄がブラウザーに保存された値で自動入力されます。

+ +

加えて、ユーザーがマスターパスワードを設定すると、ログイン情報をマスターパスワードで暗号化した状態でブラウザーに保存することができます。

+ +

マスターパスワードが用いられない場合でも、ブラウザーのパスワード管理機能は純粋にセキュリティの向上につながります。パスワードをブラウザーが保存すればユーザーは覚えなくてもよいため、覚えなければならない場合よりも強固なパスワードをユーザーが設定できるようになります。

+ +

このような理由から、現代的なブラウザーの多くはログイン欄における autocomplete="off" に対応していません。

+ + + +

この挙動は Firefox 38 以降、 Google Chrome 34 以降、 Internet Explorer 11 以降で共通です。

+ +

autocomplete="new-password" による自動入力を抑止

+ +

他人のパスワードを指定するようなユーザー管理ページを定義していて、パスワード欄の自動入力を抑止したい場合は、 autocomplete="new-password" を使用することができます。

+ +

これはヒントであり、ブラウザーは守る必要はありません。しかし、最近のブラウザーは <input> 要素に autocomplete="new-password" を設定すると自動入力を停止します。例えば、 Firefox バージョン 67 ({{bug(1119063)}} を参照) はこの場合に自動入力を停止していましたが、 Firefox 70 ({{bug(1565407)}} を参照) は安全に生成されたパスワードを提案することができるものの、保存されたパスワードを自動入力しません。詳しくは autocomplete 互換性テーブルを参照してください。

+ +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/site_identity_button/index.html b/files/ja/web/security/site_identity_button/index.html new file mode 100644 index 0000000000..5f28d27ac4 --- /dev/null +++ b/files/ja/web/security/site_identity_button/index.html @@ -0,0 +1,29 @@ +--- +title: サイト認証ボタン +slug: Web/Security/Site_Identity_Button +tags: + - Security + - Web +translation_of: Mozilla/Firefox/Site_identity_button +--- +

Firefox における機能の一つにサイト認証ボタンがあります。このボタンによって、ユーザーは自分が閲覧しているウェブサイトに関する詳しい情報を知ることができます。

+ +

ウェブサイトの設定によって、このボタンは何種類ものアイコンで表示されることがあります。

+ +

サイト認証ボタンの表示が期待と異なる場合 (緑色の錠前を期待したのに、黄色の警告の三角形が表示されるなど)、Firefox の開発ツール内にあるウェブコンソールを確認すれば、問題の原因を探ることができます。

+ +
    +
  1. ウェブコンソールで「セキュリティ」カテゴリの出力が有効になっていることを確認します。
    2. +
  2. 問題が生じているウェブページを再読み込みします。
    3. +
  3. セキュリティに関係するメッセージが表示されます。
    4. +
+ +

サイト認証ボタンが低評価を示す場合、以下の 3 つが原因として考えられます。

+ + + +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/subdomain_takeovers/index.html b/files/ja/web/security/subdomain_takeovers/index.html new file mode 100644 index 0000000000..be1c1e9b66 --- /dev/null +++ b/files/ja/web/security/subdomain_takeovers/index.html @@ -0,0 +1,60 @@ +--- +title: Subdomain takeovers +slug: Web/Security/Subdomain_takeovers +translation_of: Web/Security/Subdomain_takeovers +--- +

subdomain takeover は、攻撃者がターゲットドメインのサブドメインの制御権を獲得したときに発生します。一般的には、サブドメインがドメインネームシステム (DNS) に正規名 (CNAME) を持っているが、そのサブドメインにコンテンツを提供しているホストがいない場合に発生します。これは、バーチャルホストがまだ公開されていないか、バーチャルホストが削除されているために起こる可能性があります。攻撃者は、自分のバーチャルホストを提供して、そのサブドメインのコンテンツをホストすることで、そのサブドメインを乗っ取ることができます。

+ +

攻撃者がこれを行うことができれば、メインドメインから設定されたクッキーを読み取ったり、クロスサイトスクリプティングを行ったり、コンテンツセキュリティポリシーを回避したりすることが可能となり、保護された情報 (ログインを含む) を取得したり、不審なユーザーに悪意のあるコンテンツを送信したりすることが可能となります。

+ +

サブドメインはコンセントのようなものです。自分のアプライアンス (ホスト) をコンセントに差し込んでおけば、すべてが問題ありません。しかし、あなたがコンセントから自分のアプライアンスを取り外すと (またはまだコンセントを差し込んでいない場合)、誰かが別のアプライアンスを差し込んでしまう可能性があります。コンセントが他の人に使われるのを防ぐためには、ブレーカーやヒューズボックス (DNS) で電源を切る必要があります。

+ +

どのようにして起こるのでしょうか？

+ +

バーチャルホストのプロビジョニングやデプロビジョニング (削除) のプロセスが適切に処理されていない場合、攻撃者がサブドメインを乗っ取る機会がある可能性があります。

+ +

プロビジョニング時

+ +

攻撃者は、ホスティングプロバイダで購入したサブドメイン名の仮想ホストを先に設定します。

+ +

あなたがドメイン example.com を管理しているとします。あなたは blog.example.com にブログを追加したいと思っていて、あなたはブログプラットフォームを維持しているホスティングプロバイダを使用することにしました。(「ブログ」は、「電子商取引プラットフォーム」や「顧客サービスプラットフォーム」、あるいは他の「クラウドベース」の仮想ホスティング・シナリオでも代用可能です)。あなたが通過するプロセスは、次のように見えるかもしれません。

+ +
    +
  1. ドメインレジストラに "blog.example.com" という名前を登録します
    2. +
  2. blog.example.com にアクセスしたいブラウザをバーチャルホストに誘導するために DNS レコードを設定します
    3. +
  3. ホスティングプロバイダでバーチャルホストを作成します
    4. +
+ +

ホスティングプロバイダが、バーチャルホストを設定したエンティティが実際にサブドメイン名の所有者であることを確認するように細心の注意を払わない限り、あなたよりも手っ取り早い攻撃者が、あなたのサブドメイン名を使って、同じホスティングプロバイダでバーチャルホストを作成することができます。このような場合、ステップ2で DNS を設定するとすぐに、攻撃者はあなたのサブドメイン上でコンテンツをホストすることができます。

+ +

デプロビジョニング時

+ +

あなたはバーチャルホストを削除したが、攻撃者は同じ名前とホスティングプロバイダを使用して新しいバーチャルホストをセットアップすることがあります。

+ +

あなた (またはあなたの会社) はもうブログを維持したくないと判断したので、ホスティングプロバイダからバーチャルホストを削除します。しかし、ホスティングプロバイダを指す DNS エントリを削除しなければ、攻撃者はそのプロバイダで独自のバーチャルホストを作成し、あなたのサブドメインを主張し、そのサブドメインの下で独自のコンテンツをホストすることができるようになります。

+ +

どうすれば防げるのでしょうか？

+ +

サブドメインの乗っ取りを防ぐことは、バーチャルホストや DNS のライフサイクル管理における業務の順序の問題です。組織の規模にもよりますが、これには複数の部署間でのコミュニケーションと調整が必要となり、脆弱性のある誤設定の可能性が高まるだけです。

+ + + +

サブドメインが乗っ取られてしまいました。どうすればいいですか？

+ +

ドメインのサブドメインが乗っ取られているのを発見した場合、可能であれば、最初のステップは、サブドメインの DNS エントリを削除して「電力をカット」することです。サイトに仮想化の複数のレイヤー (例えば、仮想ホスティングに加えて CDN) がある場合、攻撃者がどこで仮想ホストの主張を主張してドメインを乗っ取ったのかを確認するために、各レイヤーを調べる必要があるかもしれません。

+ +

詳細はこちら

+ + diff --git a/files/ja/web/security/subresource_integrity/index.html b/files/ja/web/security/subresource_integrity/index.html new file mode 100644 index 0000000000..e16794fea6 --- /dev/null +++ b/files/ja/web/security/subresource_integrity/index.html @@ -0,0 +1,150 @@ +--- +title: サブリソース完全性 +slug: Web/Security/Subresource_Integrity +tags: + - HTML + - HTTP + - Intro + - Networking + - セキュリティ +translation_of: Web/Security/Subresource_Integrity +--- +

サブリソース完全性 (Subresource Integrity) (SRI) は、 ({{Glossary("CDN")}} などから) 取得したリソースが意図せず改ざんされていないかをブラウザーが検証するセキュリティ機能です。 SRI を利用する際には、取得したリソースのハッシュ値と一致すべきハッシュ値を指定します。

+ +
+

メモ: サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーはオリジン間リソース共有 (CORS) を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。

+
+ +

サブリソース完全性の必要性

+ +

複数のサイトで使われるスクリプトやスタイルシートなどのファイルを{{Glossary("CDN", "コンテンツ配信ネットワーク (CDN)")}} にホストすることにより、読み込みに必要な時間や通信帯域を減らすことができます。しかし、 CDN はリスクにもなり得ます。仮に攻撃者が CDN を掌握できれば、攻撃者は CDN 上のファイルに悪意あるコンテンツを挿入することにより (あるいは完全に置き換えることにより)、その CDN からファイルを読み込む全てのサイトを攻撃対象とすることができます。

+ +

サブリソース完全性は、ウェブアプリケーションやウェブ文書が (CDN など任意の場所から) 取得したファイルについて、第三者によってファイルの中に別のものが挿入されていないか、そして、それらのファイルに対してその他の改ざんが行われていないかを検証することにより、先程のような攻撃のリスクを軽減します。

+ +

サブリソース完全性の使い方

+ +

サブリソース完全性の機能は、ブラウザーが取得するリソース (ファイル) のハッシュ値を base64 エンコードし、その値を {{HTMLElement("script")}} や {{HTMLElement("link")}} 要素の integrity 属性に指定することによって使用します。

+ +

integrity 属性の値は、ハッシュアルゴリズムを示す接頭辞 (現在利用できる接頭辞は sha256, sha384, sha512 です) と、 base64 でエンコードされたハッシュ値をダッシュで繋いだ文字列です。

+ +
+

メモ: integrity 属性値には、ホワイトスペースで区切って複数のハッシュ値を含めることができます。リソースはこれらのハッシュ値のいずれかに一致した場合に読み込まれます。

+
+ +

base64 でエンコードされた sha384 ハッシュを含む integrity 文字列の例

+ +
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
+
+ +

従って、 oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC がハッシュ値の部分であり、接頭辞の sha384 が sha384 ハッシュであることを示します。

+ +
+

メモ: 厳密に言うと、 integrity 属性値におけるハッシュ値の部分は、あるハッシュ関数にデータを入力 (スクリプトやスタイルシートファイル) して生成された暗号学的ダイジェスト値です。しかし、一般的には短く「ハッシュ」と言えば暗号学的ダイジェスト値を意味するので、本記事でもそのように呼んでいます。

+
+ +

SRI ハッシュを生成するツール

+ +

次の openssl コマンドにより SRI ハッシュを生成することができます。

+ +
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A
+ +

または、次のような shasum コマンドの呼び出しでも実現できます。

+ +
shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64
+
+ +
+

メモ:

+ + +
+ +

また、SRI Hash Generator (https://www.srihash.org/) によりオンラインで SRI ハッシュを生成することもできます。

+ +

オリジン間リソース共有とサブリソース完全性

+ +

サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーはオリジン間リソース共有 (CORS) を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。従って、次の例のように、リソースが要求されたオリジンに共有できるよう {{httpheader("Access-Control-Allow-Origin")}} ヘッダーを付けて提供する必要があります。

+ +
Access-Control-Allow-Origin: *
+ +

例

+ +

以下の例では、 oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC が特定のスクリプト example-framework.js の期待される SHA-384 ハッシュ値としてすでに知られており、スクリプトのコピーが https://example.com/example-framework.js にホストされているものとします。

+ +

<script> 要素のサブリソース完全性

+ +

次の {{HTMLElement("script")}} 要素により、ブラウザーが https://example.com/example-framework.js を実行する前に、まず想定されるハッシュ値とスクリプトのハッシュ値が一致することをブラウザーに確認させることができます。

+ +
<script src="https://example.com/example-framework.js"
+        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
+        crossorigin="anonymous"></script>
+ +
+

メモ: crossorigin 属性については CORS 設定属性を参照してください。

+
+ +

サブリソース完全性のブラウザーでの扱い

+ +

ブラウザは SRI を以下のように処理します。

+ +

メモ: サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーはオリジン間リソース共有 (CORS) を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。

+ +
    +
  1. +

    ブラウザは integrity 属性を持った {{HTMLElement("script")}} または {{HTMLElement("link")}} 属性を見つけると、スクリプトや {{HTMLElement("link")}} 属性で指定された任意のスタイルシートを適用する前に、integrity 属性のハッシュ値とスクリプトやスタイルシートのハッシュ値を比較しなくてはなりません。

    +
    2. +
  2. スクリプトやスタイルシートが対応する integrity 属性値と一致しない場合、ブラウザーはスクリプトを実行したりスタイルシートを適用してはいけません。その代わりに、スクリプトやスタイルシートの取得が失敗したというネットワークエラーを返さなくてはなりません。
    3. +
+ +

仕様

+ + + + + + + + + + + + + + + + + + + + + +
仕様書状態備考
{{SpecName('Subresource Integrity')}}{{Spec2('Subresource Integrity')}}
{{SpecName('Fetch')}}{{Spec2('Fetch')}}
+ +

ブラウザの互換性

+ +

<script integrity>

+ + + +

{{Compat("html.elements.script.integrity")}}

+ +

CSP: require-sri-for

+ + + +

{{Compat("http.headers.csp.require-sri-for")}}

+ +

関連情報

+ + + +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/transport_layer_security/index.html b/files/ja/web/security/transport_layer_security/index.html new file mode 100644 index 0000000000..ee6b578afa --- /dev/null +++ b/files/ja/web/security/transport_layer_security/index.html @@ -0,0 +1,124 @@ +--- +title: Transport Layer Security +slug: Web/Security/Transport_Layer_Security +tags: + - Cryptography + - Guide + - SSL + - Security + - TLS + - セキュリティ + - 暗号化 + - 認証 +translation_of: Web/Security/Transport_Layer_Security +--- +

Transport Layer Security (TLS) を使用した接続のセキュリティは、選択されている暗号スイートとセキュリティ引数に強く依存します。この記事の目的は、クライアントとサーバの間の機密性と完全性の通信を確実にするために、選択の参考になることです。 Mozilla Operations Security (OpSec) チームは、サーバの設定項目のリファレンスが付いたウィキ記事を管理しています。

+ +

Transport Layer Security (TLS) プロトコルは、ネットワークで結ばれた二つのアプリケーションや端末が、私的にかつ強固に情報交換するための標準です。 TLS を使用するアプリケーションは、セキュリティ引数を選択することができ、これは、データのセキュリティと信頼性に大きな影響を与える可能性があります。この記事では、 TLS の概要と、コンテンツを保護するために必要な決定の種類について説明します。

+ +

歴史

+ +

HTTPS が導入されたときは Secure Sockets Layer (SSL) 2.0 という、 Netscape がもたらした技術に基づいていました。その後で間もなく SSL 3.0 に更新され、用途が拡大し、Web ブラウザーとサーバの間の相互運用性を保証するために、共通で標準化された暗号化技術を規定することが必要になりました。 Internet Engineering Task Force (IETF) は TLS 1.0 を {{RFC(2246)}} で1999年1月に規定しました。 TLS の現在のバージョンは 1.3 ({{RFC(8446)}}) です。

+ +
+

Web では暗号化に TLS を使用するようになったという事実に関わらず、多くの人々はまだ習慣的に "SSL" と呼んでいます。

+
+ +

TLS はどのような低水準のトランスポートプロトコルの上でも使用することができますが、このプロトコルの本来の目標は HTTP トラフィックを暗号化することでした。 HTTP を TLS で暗号化することは、一般に {{Glossary("HTTPS")}} と呼ばれています。暗号化されていない HTTP が既定で80番ポートを使用するのに対し、 TLS で暗号化されたWeb トラフィックは、慣習として既定で443番ポートで交わされます。 HTTPS は引き続き、 TLS の重要な用途です。

+ +

HTTP over TLS

+ +

TLS は、それと交換されるデータの安全性とセキュリティを確保するための3つの主要なサービスを提供しています。

+ +
+
認証
+
認証は、通信の各当事者が相手が自分の主張する人物であることを確認することを可能にします。
+
暗号化
+
データは、ユーザーエージェントとサーバの間で送信されている間は暗号化されており、権限のない者によって読み取られたり解釈されたりすることを防ぐことができます。
+
完全性
+
TLS は、データの暗号化から送信、復号化までの間に、情報の紛失、破損、改ざん、偽造がないことを保証します。
+
+ +

TLS 接続は、クライアントとサーバが共有シークレットに合意し、暗号スイートのような重要なパラメータがネゴシエートされるハンドシェイクフェーズから始まります。一旦、パラメータと HTTP などのアプリケーションデータが交換されるデータ交換モードになります。

+ +

暗号スイート

+ +

TLS のハンドシェイクがネゴシエートする主なパラメータは {{interwiki("wikipedia", "cipher suite")}} です。

+ +

TLS 1.2 およびそれ以前のバージョンでは、ネゴシエートされた暗号スイートには、共有秘密のネゴシエート、サーバの認証手段、データの暗号化に使用される方法を提供する一連の暗号アルゴリズムが含まれています。

+ +

TLS 1.3 の暗号化スイートは主にデータの暗号化を管理し、鍵の合意と認証には個別のネゴシエーション方法が使用されます。

+ +

異なるソフトウェアでは、同じ暗号スイートに対して異なる名前を使用している場合があります。例えば、OpenSSL や GnuTLS で使われている名前は TLS 標準のものとは異なります。Mozilla OpSec チームの TLS 設定に関する記事の暗号名対応表には、これらの名前と互換性やセキュリティレベルに関する情報が記載されています。

+ +

サーバの構築

+ +

サーバを正しく設定することは非常に重要です。一般的には、サイトに接続できるようにしたいブラウザと互換性のある、可能な限り最新の暗号をサポートするようにしてください。Mozilla OpSec ガイドの TLS 設定では、推奨される設定についての詳細な情報を提供しています。

+ +

サイトの設定を支援するために、Mozilla は以下の Web サーバ用の設定ファイルを生成する便利な TLS 設定ジェネレータを提供しています。

+ + + +

必要に応じて設定を作成するには、コンフィグレータを使用することをお勧めします。設定ファイルをコピーしてサーバ上の適切なファイルに貼り付け、サーバを再起動して変更を反映させます。設定ファイルにはカスタム設定を含めるための調整が必要な場合がありますので、使用する前に生成された設定を確認してください。ドメイン名などの参照が正しいことを確認せずに設定ファイルをインストールすると、サーバが動作しなくなります。

+ +

TLS 1.3

+ +

{{RFC("8446", "TLS 1.3")}} は、TLS のメジャーリビジョンです。TLS 1.3 には、セキュリティとパフォーマンスを向上させる多数の変更が含まれています。TLS 1.3 の目標は以下の通りです。

+ + + +

TLS 1.3 はプロトコルの基本的な部分の多くを変更していますが、以前のバージョンの TLS と同様に基本的な機能のほとんどすべてを保持しています。Web では、TLS 1.3 はいくつかのまれな例外を除いて、互換性に影響を与えることなく有効にすることができます (以下を参照)。

+ +

TLS 1.3 の主な変更点は以下の通りです。

+ + + +

TLS 1.3 のドラフト版の実装が公開されています。TLS 1.3  は 0-RTT モードを含むいくつかのブラウザで有効になっています。TLS 1.3 を有効にしている Web サーバでは、TLS 1.3 が正常に動作するように設定を調整する必要があるかもしれません。

+ +

TLS 1.3 では、重要な新しいユースケースが 1 つだけ追加されました。0-RTT ハンドシェイクは、Web のようなレイテンシに敏感なアプリケーションに大きなパフォーマンスの向上をもたらします。0-RTT を有効にするには、導入を確実に成功させ、リプレイ攻撃のリスクを管理するための追加のステップが必要です。

+ +

TLS 1.3 でリネゴシエーションが削除されたことは、証明書を使ったクライアント認証に依存する一部の Web サーバに影響を与える可能性があります。一部の Web サーバは、クライアント証明書が暗号化されていることを確実にするため、あるいは特定のリソースが要求されたときにのみクライアント証明書を要求するために、リネゴシエーションを使用しています。クライアント証明書のプライバシーを守るために、TLS 1.3 ハンドシェイクの暗号化によってクライアント証明書の暗号化が確実に行われますが、これにはソフトウェアの変更が必要になるかもしれません。証明書を使ったリアクティブなクライアント認証は TLS 1.3 でサポートされていますが、広くは実装されていません。代替のメカニズムは現在開発中で、HTTP/2 もサポートする予定です。

+ +

古いバージョンの TLS の引退

+ +

よりモダンで安全な Web に向けての取り組みにより、2020 年第 1 四半期に TLS 1.0 および 1.1 のサポートがすべての主要ブラウザーから削除されます。 Web サーバが今後 TLS 1.2 または 1.3 をサポートすることを確認する必要があります。

+ +

Firefox はバージョン 74 以降、古い TLS バージョンを使用してサーバに接続すると Secure Connection Failed エラーを返します ({{bug(1606734)}}) 。

+ +

TLS ハンドシェイクタイムアウト値

+ +

何らかの理由で TLS ハンドシェイクが遅くなったり、反応しなくなったりすると、ユーザーの体験に大きな影響を与える可能性があります。この問題を軽減するために、最近のブラウザはハンドシェイクのタイムアウトを実装しています。

+ + + +

関連情報

+ + + +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

diff --git a/files/ja/web/security/types_of_attacks/index.html b/files/ja/web/security/types_of_attacks/index.html new file mode 100644 index 0000000000..45edd24b04 --- /dev/null +++ b/files/ja/web/security/types_of_attacks/index.html @@ -0,0 +1,88 @@ +--- +title: 攻撃の種類 +slug: Web/Security/Types_of_attacks +translation_of: Web/Security/Types_of_attacks +--- +

{{draft}}

+ +

この記事では、様々な種類のセキュリティ攻撃とそれを軽減するためのテクニックについて解説しています。

+ +

クリックジャッキング

+ +

クリックジャッキングとは、ユーザーを騙して、ユーザーが思っているものとは別のリンクやボタンなどをクリックさせることです。これは、例えば、ログイン認証情報を盗んだり、マルウェアの一部をインストールするためにユーザーの無意識のうちに許可を得るために使用することができます。(クリックジャッキングは、「ユーザーインターフェースのリドレス」と呼ばれることもありますが、これは「リドレス」という用語の誤用です)。

+ +

クロスサイトリクエストフォージェリ (CSRF)

+ +

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

+ +

クロスサイトスクリプティング（XSS）は、攻撃者が悪意のあるクライアント側のコードをウェブサイトに注入することができるセキュリティエクスプロイトです。このコードは被害者によって実行され、攻撃者はアクセス制御を迂回したり、ユーザーになりすましたりすることができます。Open Web Application Security Project によると、XSS は2017年に7番目に多いWebアプリの脆弱性だったという。

+ +

これらの攻撃は、Web アプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに {{glossary("HTML")}} コンテンツを書き換えさせたりします。

+ +

クロスサイトスクリプティング攻撃は、通常、1) 信頼されていないソース (多くの場合、Web リクエスト) を介して Web アプリにデータが入力されたり、2) 悪意のあるコンテンツが検証されずに動的なコンテンツが Web ユーザーに送信されたりした場合に発生します。

+ +

悪意のあるコンテンツには、{{glossary("JavaScript")}} が含まれていることが多いですが、HTML、Flash、またはブラウザが実行できるその他のコードが含まれていることもあります。XSS に基づく攻撃の種類はほぼ無限にありますが、一般的には、クッキーなどのセッション情報などのプライベートデータを攻撃者に送信したり、攻撃者が管理するウェブページに被害者をリダイレクトさせたり、脆弱性のあるサイトを装ってユーザーのマシンに悪意のある操作を行ったりすることが多いです。

+ +

XSS 攻撃は、蓄積型 (パーシステントとも呼ばれる)、反映型 (非パーシステントとも呼ばれる)、DOM ベースの3つに分類されます。

+ +
+
格納された XSS 攻撃
+
注入されたスクリプトは、ターゲットのサーバーに永久に保存されます。そして、被害者は、ブラウザがデータの要求を送信すると、この悪意のあるスクリプトをサーバーから取得します。
+
反映された XSS 攻撃
+
ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のある Web サイトに移動します。Web サーバは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバに送信されたデータを含むその他の応答など、ユーザのブラウザに反映させます。ブラウザは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバからのものであると想定しているため、コードを実行します。
+
DOM ベースの XSS 攻撃
+
ペイロードは、元のクライアントサイドスクリプトが使用していた DOM 環境 (被害者のブラウザ内) を変更した結果、実行されます。つまり、ページ自体は変わりませんが、DOM 環境を悪意を持って改変した結果、ページに含まれるクライアント側のコードが予期せぬ形で実行される。
+
+ +

Wikipedia には、CSRF の良い例が記載されています。この状況では、誰かが (例えば、フィルタリングされていないチャットやフォーラムで) 実際には画像ではない画像を含むが、その代わりに、それは本当にお金を引き出すためにあなたの銀行のサーバーへのリクエストです。

+ +
<img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
+ +

さて、あなたが銀行口座にログインしていて、クッキーがまだ有効であれば (他の検証はありません)、この画像を含む HTML を読み込むとすぐに送金されます。POST リクエストを必要とするエンドポイントでは、ページが読み込まれたときにプログラム的に <form> の送信をトリガーすることができます (おそらく不可視の <iframe> で)。

+ +
<form action="https://bank.example.com/withdraw" method="POST">
+  <input type="hidden" name="account" value="bob">
+  <input type="hidden" name="amount" value="1000000">
+  <input type="hidden" name="for" value="mallory">
+</form>
+<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script>
+ +


+ これを防ぐためには、いくつかのテクニックがあります。

+ + + +

より多くの予防のヒントについては、OWASP CSRF prevention チートシートを参照してください。

+ +

中間者攻撃 (MitM)

+ +

第三者がウェブサーバーとクライアント（ブラウザ）間のトラフィックを傍受し、ウェブサーバーになりすましてデータ（ログイン情報やクレジットカード情報など）を取得します。トラフィックは、場合によっては変更された状態で通過します。オープン WiFi ネットワークは、この攻撃を実行する一般的な手段です。

+ +

セッションハイジャック

+ +

セッションハイジャックは、ユーザの認証されたセッションにアクセスして悪用することです。これは、既存のセッションのクッキーを盗んだり、ユーザ (またはブラウザ) を騙して、あらかじめ設定されたセッション ID のクッキーを設定させることで起こる可能性があります。

+ +

厳密な Content-Security-Policy を展開することで、侵入経路を制限することができます。

+ +

セッションの固定

+ +

第三者は、ユーザーのセッション識別子を判断することができ（つまり、読み取ったり、設定したりすることで）、そのユーザーとしてサーバーとやりとりをすることができます。クッキーを盗むことは、これを行う一つの方法です。

+ +

application.example.com のようなサブドメインは、Domain 属性を設定することで、example.com や他のサブドメインへのリクエストと一緒に送信されるクッキーを設定できることを思い出してください。

+ +
Set-Cookie: CSRF=e8b667; Secure; Domain=example.com
+ +

脆弱性のあるアプリケーションがサブドメイン上で利用可能な場合、このメカニズムはセッション固定化攻撃で悪用される可能性があります。ユーザが親ドメイン(または別のサブドメイン)のページを訪問したとき、アプリケーションはユーザのクッキーで送られた既存の値を信頼するかもしれません。これにより、攻撃者は CSRF 保護を迂回したり、ユーザがログインした後にセッションを乗っ取ったりすることができます。
+ あるいは、親ドメインが includeSubdomains が設定された HTTP Strict-Transport-Security を使用しない場合、アクティブな MitM の対象となるユーザ (おそらくオープンなWiFi ネットワークに接続されている) は、存在しないサブドメインからの Set-Cookie ヘッダを持つレスポンスを提供される可能性があります。ブラウザは違法なクッキーを保存し、example.com の下の他のすべてのページにそれを送信します。

+ +

セッションの固定化は主に、ユーザが認証するときに (たとえクッキーがすでに存在していても) セッションクッキーの値を再生成し、 CSRF トークンをユーザに結びつけることによって緩和されるべきです。

+ +

セッションのサイドジャッキング

+ +

ブラウザハイジャックマルウェア

diff --git a/files/ja/web/security/weak_signature_algorithm/index.html b/files/ja/web/security/weak_signature_algorithm/index.html new file mode 100644 index 0000000000..c66d35c30f --- /dev/null +++ b/files/ja/web/security/weak_signature_algorithm/index.html @@ -0,0 +1,29 @@ +--- +title: 脆弱な署名アルゴリズム +slug: Web/Security/Weak_Signature_Algorithm +tags: + - Cryptography + - ウェブ + - ガイド + - セキュリティ +translation_of: Web/Security/Weak_Signature_Algorithm +--- +

{{Glossary("Digital certificate", "ディジタル証明書")}}の{{Glossary("Signature/Security", "電子署名")}}に用いられるハッシュアルゴリズムの強度は、証明書のセキュリティにおいて核心的な要素です。この記事では、脆弱になったため、可能であれば避けるものと知られている署名アルゴリズムについて、いくらかの情報を提供します。

+ +

ハッシュアルゴリズムの脆弱性は、攻撃者が偽の証明書を作成または取得してしまうような事態を招きます。新しい攻撃手法が発見や、利用可能な攻撃技術の進歩などのため、古いアルゴリズムを使用することは避けるべきであり、いつかは対応が削除されます。

+ +

SHA-1

+ +

SHA-1 の証明書は、2017年の初めから、多くのブラウザーの開発者が安全であるとはみなさなくなりました。より安全なハッシュアルゴリズム (SHA-256 や SHA-512 など) を代わりに使用してください。

+ +

MD5

+ +

MD5 による署名への対応は、2012年初めに削除されました。

+ +

関連情報

+ + + +

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}

-- cgit v1.2.3-54-g00ecf