initial commit

1 files changed, 60 insertions, 0 deletions

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
+---
+<p>subdomain takeover は、攻撃者がターゲットドメインのサブドメインの制御権を獲得したときに発生します。一般的には、サブドメインがドメインネームシステム (<a href="https://wiki.developer.mozilla.org/en-US/docs/Glossary/DNS">DNS</a>) に正規名 (<a href="https://en.wikipedia.org/wiki/CNAME_record">CNAME</a>) を持っているが、そのサブドメインにコンテンツを提供しているホストがいない場合に発生します。これは、バーチャルホストがまだ公開されていないか、バーチャルホストが削除されているために起こる可能性があります。攻撃者は、自分のバーチャルホストを提供して、そのサブドメインのコンテンツをホストすることで、そのサブドメインを乗っ取ることができます。</p>
+
+<p>攻撃者がこれを行うことができれば、メインドメインから設定された<a href="/ja/docs/Web/HTTP/Cookies">クッキー</a>を読み取ったり、<a href="/ja/docs/Web/Security/Types_of_attacks#Cross-site_scripting_XSS">クロスサイトスクリプティング</a>を行ったり、<a href="/ja/docs/Web/HTTP/CSP">コンテンツセキュリティポリシー</a>を回避したりすることが可能となり、保護された情報 (ログインを含む) を取得したり、不審なユーザーに悪意のあるコンテンツを送信したりすることが可能となります。</p>
+
+<p>サブドメインはコンセントのようなものです。自分のアプライアンス (ホスト) をコンセントに差し込んでおけば、すべてが問題ありません。しかし、あなたがコンセントから自分のアプライアンスを取り外すと (またはまだコンセントを差し込んでいない場合)、誰かが別のアプライアンスを差し込んでしまう可能性があります。コンセントが他の人に使われるのを防ぐためには、ブレーカーやヒューズボックス (DNS) で電源を切る必要があります。</p>
+
+<h2 id="どのようにして起こるのでしょうか？">どのようにして起こるのでしょうか？</h2>
+
+<p>バーチャルホストのプロビジョニングやデプロビジョニング (削除) のプロセスが適切に処理されていない場合、攻撃者がサブドメインを乗っ取る機会がある可能性があります。</p>
+
+<h3 id="プロビジョニング時">プロビジョニング時</h3>
+
+<p>攻撃者は、ホスティングプロバイダで購入したサブドメイン名の仮想ホストを先に設定します。</p>
+
+<p>あなたがドメイン example.com を管理しているとします。あなたは blog.example.com にブログを追加したいと思っていて、あなたはブログプラットフォームを維持しているホスティングプロバイダを使用することにしました。(「ブログ」は、「電子商取引プラットフォーム」や「顧客サービスプラットフォーム」、あるいは他の「クラウドベース」の仮想ホスティング・シナリオでも代用可能です)。あなたが通過するプロセスは、次のように見えるかもしれません。</p>
+
+<ol>
+ <li>ドメインレジストラに "blog.example.com" という名前を登録します</li>
+ <li>blog.example.com にアクセスしたいブラウザをバーチャルホストに誘導するために DNS レコードを設定します</li>
+ <li>ホスティングプロバイダでバーチャルホストを作成します</li>
+</ol>
+
+<p>ホスティングプロバイダが、バーチャルホストを設定したエンティティが実際にサブドメイン名の所有者であることを確認するように細心の注意を払わない限り、あなたよりも手っ取り早い攻撃者が、あなたのサブドメイン名を使って、同じホスティングプロバイダでバーチャルホストを作成することができます。このような場合、ステップ2で DNS を設定するとすぐに、攻撃者はあなたのサブドメイン上でコンテンツをホストすることができます。</p>
+
+<h3 id="デプロビジョニング時">デプロビジョニング時</h3>
+
+<p>あなたはバーチャルホストを削除したが、攻撃者は同じ名前とホスティングプロバイダを使用して新しいバーチャルホストをセットアップすることがあります。</p>
+
+<p>あなた (またはあなたの会社) はもうブログを維持したくないと判断したので、ホスティングプロバイダからバーチャルホストを削除します。しかし、ホスティングプロバイダを指す DNS エントリを削除しなければ、攻撃者はそのプロバイダで独自のバーチャルホストを作成し、あなたのサブドメインを主張し、そのサブドメインの下で独自のコンテンツをホストすることができるようになります。</p>
+
+<h2 id="どうすれば防げるのでしょうか？">どうすれば防げるのでしょうか？</h2>
+
+<p>サブドメインの乗っ取りを防ぐことは、バーチャルホストや DNS のライフサイクル管理における業務の順序の問題です。組織の規模にもよりますが、これには複数の部署間でのコミュニケーションと調整が必要となり、脆弱性のある誤設定の可能性が高まるだけです。</p>
+
+<ul>
+ <li>ホストのプロビジョニングとデプロビジョニングの標準プロセスを定義します。すべての手順を可能な限り密接に行います
+  <ul>
+   <li>バーチャルホストを主張してプロビジョニングを開始し、<em>最後に</em> DNS レコードを作成します</li>
+   <li><em>最初に</em> DNS レコードを削除してデプロビジョニングを開始します</li>
+  </ul>
+ </li>
+ <li>組織のすべてのドメインとそのホスティングプロバイダのインベントリを作成し、変化に応じて更新することで、何もぶら下がったままにならないようにします</li>
+ <li>バーチャルホストを主張する人が実際にドメイン名への正当な主張を持っていることをどのように検証するのかを尋ねてください。あなたの組織内での作業は、ベンダーの資格プロセスの一部にするためです</li>
+</ul>
+
+<h2 id="サブドメインが乗っ取られてしまいました。どうすればいいですか？">サブドメインが乗っ取られてしまいました。どうすればいいですか？</h2>
+
+<p>ドメインのサブドメインが乗っ取られているのを発見した場合、可能であれば、最初のステップは、サブドメインの DNS エントリを削除して「電力をカット」することです。サイトに仮想化の複数のレイヤー (例えば、仮想ホスティングに加えて <a href="/ja/docs/Glossary/CDN">CDN</a>) がある場合、攻撃者がどこで仮想ホストの主張を主張してドメインを乗っ取ったのかを確認するために、各レイヤーを調べる必要があるかもしれません。</p>
+
+<h2 id="詳細はこちら">詳細はこちら</h2>
+
+<ul>
+ <li><a href="https://blog.rubidus.com/2017/02/03/deep-thoughts-on-subdomain-takeovers/">'Deep Thoughts' on Subdomain Takeover Vulnerabilities</a></li>
+ <li><a href="https://0xpatrik.com/subdomain-takeover-basics/">Subdomain Takeover: Basics</a></li>
+</ul>