Web/Security/Types_of_attacks を更新

- 2021/05/07 時点の英語版に同期

1 files changed, 18 insertions, 19 deletions

diff --git a/files/ja/web/security/types_of_attacks/index.html b/files/ja/web/security/types_of_attacks/index.html
index fe99ad3a25..2539af2807 100644
--- a/files/ja/web/security/types_of_attacks/index.html
+++ b/files/ja/web/security/types_of_attacks/index.html
@@ -13,28 +13,28 @@ translation_of: Web/Security/Types_of_attacks
 
 <h2 id="クロスサイトスクリプティング_XSS">クロスサイトスクリプティング (XSS)</h2>
 
-<p>クロスサイトスクリプティング（XSS）は、攻撃者が悪意のあるクライアント側のコードをウェブサイトに注入することができるセキュリティエクスプロイトです。このコードは被害者によって実行され、攻撃者はアクセス制御を迂回したり、ユーザーになりすましたりすることができます。Open Web Application Security Project によると、XSS は2017年に<a href="https://owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf">7番目に多いウェブアプリの脆弱性</a>だったという。</p>
+<p>クロスサイトスクリプティング（XSS）は、攻撃者が悪意のあるクライアント側のコードをウェブサイトに注入することができるセキュリティエクスプロイトです。このコードは被害者によって実行され、攻撃者はアクセス制御を迂回したり、ユーザーになりすましたりすることができます。Open Web Application Security Project によると、XSS は2017年に<a href="https://owasp.org/www-project-top-ten/2017/Top_10">7番目に多いウェブアプリの脆弱性</a>だったという。</p>
 
-<p>これらの攻撃は、ウェブアプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに {{glossary("HTML")}} コンテンツを書き換えさせたりします。</p>
+<p>これらの攻撃は、ウェブアプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザーは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに {{glossary("HTML")}} コンテンツを書き換えさせたりします。</p>
 
 <p>クロスサイトスクリプティング攻撃は、通常、1) 信頼されていないソース (多くの場合、ウェブリクエスト) を介してウェブアプリにデータが入力されたり、2) 悪意のあるコンテンツが検証されずに動的なコンテンツがウェブユーザーに送信されたりした場合に発生します。</p>
 
-<p>悪意のあるコンテンツには、{{glossary("JavaScript")}} が含まれていることが多いですが、HTML、Flash、またはブラウザが実行できるその他のコードが含まれていることもあります。XSS に基づく攻撃の種類はほぼ無限にありますが、一般的には、クッキーなどのセッション情報などのプライベートデータを攻撃者に送信したり、攻撃者が管理するウェブページに被害者をリダイレクトさせたり、脆弱性のあるサイトを装ってユーザーのマシンに悪意のある操作を行ったりすることが多いです。</p>
+<p>悪意のあるコンテンツには、{{glossary("JavaScript")}} が含まれていることが多いですが、HTML、Flash、またはブラウザーが実行できるその他のコードが含まれていることもあります。XSS に基づく攻撃の種類はほぼ無限にありますが、一般的には、クッキーなどのセッション情報などのプライベートデータを攻撃者に送信したり、攻撃者が管理するウェブページに被害者をリダイレクトさせたり、脆弱性のあるサイトを装ってユーザーのマシンに悪意のある操作を行ったりすることが多いです。</p>
 
 <p>XSS 攻撃は、蓄積型 (パーシステントとも呼ばれる)、反映型 (非パーシステントとも呼ばれる)、DOM ベースの3つに分類されます。</p>
 
 <dl>
  <dt>格納された XSS 攻撃</dt>
- <dd>注入されたスクリプトは、ターゲットのサーバーに永久に保存されます。そして、被害者は、ブラウザがデータの要求を送信すると、この悪意のあるスクリプトをサーバーから取得します。</dd>
+ <dd>注入されたスクリプトは、ターゲットのサーバーに永久に保存されます。そして、被害者は、ブラウザーがデータの要求を送信すると、この悪意のあるスクリプトをサーバーから取得します。</dd>
  <dt>反映された XSS 攻撃</dt>
- <dd>ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のあるウェブサイトに移動します。ウェブサーバーは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバーに送信されたデータを含むその他の応答など、ユーザのブラウザに反映させます。ブラウザは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバーからのものであると想定しているため、コードを実行します。</dd>
+ <dd>ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のあるウェブサイトに移動します。ウェブサーバーは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバーに送信されたデータを含むその他の応答など、ユーザーのブラウザーに反映させます。ブラウザーは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバーからのものであると想定しているため、コードを実行します。</dd>
  <dt>DOM ベースの XSS 攻撃</dt>
- <dd>ペイロードは、元のクライアントサイドスクリプトが使用していた DOM 環境 (被害者のブラウザ内) を変更した結果、実行されます。つまり、ページ自体は変わりませんが、DOM 環境を悪意を持って改変した結果、ページに含まれるクライアント側のコードが予期せぬ形で実行される。</dd>
+ <dd>ペイロードは、元のクライアントサイドスクリプトが使用していた DOM 環境 (被害者のブラウザー内) を変更した結果、実行されます。つまり、ページ自体は変わりませんが、DOM 環境を悪意を持って改変した結果、ページに含まれるクライアント側のコードが予期せぬ形で実行される。</dd>
 </dl>
 
-<h2 id="クロスサイトリクエストフォージェリ_CSRF">クロスサイトリクエストフォージェリ (CSRF)</h2>
+<h2 id="クロスサイトリクエストフォージェリー_CSRF">クロスサイトリクエストフォージェリー (CSRF)</h2>
 
-<p>CSRF ( XSRF とも呼ぶ) は、関連するクラスの攻撃です。攻撃者はユーザーのブラウザにユーザーの同意なく、または、知らないうちにウェブサイトのバックエンドへの要求を実行させます。攻撃者は XSS ペイロードを使用して CSRF 攻撃を開始できます。</p>
+<p>CSRF (XSRF とも呼ぶ) は、関連するクラスの攻撃です。攻撃者はユーザーのブラウザーにユーザーの同意なく、または、知らないうちにウェブサイトのバックエンドへの要求を実行させます。攻撃者は XSS ペイロードを使用して CSRF 攻撃を開始できます。</p>
 
 <p>Wikipedia には、CSRF の良い例が記載されています。この状況では、誰かが (例えば、フィルタリングされていないチャットやフォーラムで) 実際には画像ではない画像を含むが、その代わりに、それは本当にお金を引き出すためにあなたの銀行のサーバーへのリクエストです。</p>
 
@@ -49,26 +49,25 @@ translation_of: Web/Security/Types_of_attacks
 &lt;/form&gt;
 &lt;script&gt;window.addEventListener('DOMContentLoaded', (e) =&gt; { document.querySelector('form').submit(); }&lt;/script&gt;</pre>
 
-<p><br>
- これを防ぐためには、いくつかのテクニックがあります。</p>
+<p>これを防ぐためには、いくつかのテクニックがあります。</p>
 
 <ul>
- <li>GET エンドポイントは、変更を実行するアクションであって、単にデータを取得するだけのものではなく、POST (または他の HTTP メソッド) リクエストの送信を必要とするものでなければなりません。POST エンドポイントは、クエリ文字列内のパラメータを持つ GET リクエストを相互に受け入れてはいけません</li>
+ <li>GET エンドポイントは、変更を実行するアクションであって、データを取得するだけのものではなく、POST (または他の HTTP メソッド) リクエストの送信を必要とするものでなければなりません。POST エンドポイントは、クエリ文字列内のパラメータを持つ GET リクエストを相互に受け入れてはいけません</li>
  <li>CSRF トークンは、非表示の入力フィールドを経由して &lt;form&gt; 要素に含まれなければなりません。このトークンはユーザーごとに一意で、リクエストが送られたときにサーバーが期待値を調べることができるように、(たとえばクッキーに) 保存されるべきです。アクションを実行する可能性のあるすべての非 GET リクエストに対して、 この入力フィールドは期待値と比較されるべきです。不一致があった場合、リクエストは中止されるべきです</li>
  <li>CSRF トークンを予測できないことに依存しています。トークンはサインイン時に再生成されなければなりません</li>
- <li>機密性の高い動作 (セッションクッキーなど) に使用されるクッキーは、SameSite 属性を Strict または Lax に設定して、有効期限を短くする必要があります (上記の SameSite cookies を参照)。サポートしているブラウザでは、これはクロスサイトリクエストと一緒にセッションクッキーが送信されないようにする効果があり、そのリクエストはアプリケーションサーバーに対して事実上認証されません</li>
- <li>CSRF トークンと SameSite Cookie の両方を導入する必要があります。これにより、すべてのブラウザが保護され、SameSite のクッキーでは対応できない場合 (別のサブドメインからの攻撃など) にも保護されます</li>
+ <li>機密性の高い動作 (セッションクッキーなど) に使用されるクッキーは、SameSite 属性を Strict または Lax に設定して、有効期限を短くする必要があります (上記の SameSite cookies を参照)。サポートしているブラウザーでは、これはクロスサイトリクエストと一緒にセッションクッキーが送信されないようにする効果があり、そのリクエストはアプリケーションサーバーに対して事実上認証されません</li>
+ <li>CSRF トークンと SameSite Cookie の両方を導入する必要があります。これにより、すべてのブラウザーが保護され、SameSite のクッキーでは対応できない場合 (別のサブドメインからの攻撃など) にも保護されます</li>
 </ul>
 
 <p>より多くの予防のヒントについては、OWASP CSRF prevention チートシートを参照してください。</p>
 
 <h2 id="中間者攻撃_MitM">中間者攻撃 (MitM)</h2>
 
-<p>第三者がウェブサーバーとクライアント（ブラウザ）間のトラフィックを傍受し、ウェブサーバーになりすましてデータ（ログイン情報やクレジットカード情報など）を取得します。トラフィックは、場合によっては変更された状態で通過します。オープン WiFi ネットワークは、この攻撃を実行する一般的な手段です。</p>
+<p>第三者がウェブサーバーとクライアント（ブラウザー）間のトラフィックを傍受し、ウェブサーバーになりすましてデータ（ログイン情報やクレジットカード情報など）を取得します。トラフィックは、場合によっては変更された状態で通過します。オープン WiFi ネットワークは、この攻撃を実行する一般的な手段です。</p>
 
 <h2 id="セッションハイジャック">セッションハイジャック</h2>
 
-<p>セッションハイジャックは、ユーザの認証されたセッションにアクセスして悪用することです。これは、既存のセッションのクッキーを盗んだり、ユーザ (またはブラウザ) を騙して、あらかじめ設定されたセッション ID のクッキーを設定させることで起こる可能性があります。</p>
+<p>セッションハイジャックは、ユーザーの認証されたセッションにアクセスして悪用することです。これは、既存のセッションのクッキーを盗んだり、ユーザー (またはブラウザー) を騙して、あらかじめ設定されたセッション ID のクッキーを設定させることで起こる可能性があります。</p>
 
 <p>厳密な Content-Security-Policy を展開することで、侵入経路を制限することができます。</p>
 
@@ -80,11 +79,11 @@ translation_of: Web/Security/Types_of_attacks
 
 <pre class="notranslate">Set-Cookie: CSRF=e8b667; Secure; Domain=example.com</pre>
 
-<p>脆弱性のあるアプリケーションがサブドメイン上で利用可能な場合、このメカニズムはセッション固定化攻撃で悪用される可能性があります。ユーザが親ドメイン(または別のサブドメイン)のページを訪問したとき、アプリケーションはユーザのクッキーで送られた既存の値を信頼するかもしれません。これにより、攻撃者は CSRF 保護を迂回したり、ユーザがログインした後にセッションを乗っ取ったりすることができます。<br>
- あるいは、親ドメインが <code>includeSubdomains</code> が設定された <a href="/ja/docs/Glossary/HSTS">HTTP Strict-Transport-Security</a> を使用しない場合、アクティブな MitM の対象となるユーザ (おそらくオープンなWiFi ネットワークに接続されている) は、存在しないサブドメインからの Set-Cookie ヘッダを持つレスポンスを提供される可能性があります。ブラウザは違法なクッキーを保存し、example.com の下の他のすべてのページにそれを送信します。</p>
+<p>脆弱性のあるアプリケーションがサブドメイン上で利用可能な場合、このメカニズムはセッション固定化攻撃で悪用される可能性があります。ユーザーが親ドメイン(または別のサブドメイン)のページを訪問したとき、アプリケーションはユーザーのクッキーで送られた既存の値を信頼するかもしれません。これにより、攻撃者は CSRF 保護を迂回したり、ユーザーがログインした後にセッションを乗っ取ったりすることができます。<br>
+ あるいは、親ドメインが <code>includeSubdomains</code> が設定された <a href="/ja/docs/Glossary/HSTS">HTTP Strict-Transport-Security</a> を使用しない場合、アクティブな MitM の対象となるユーザー (おそらくオープンな WiFi ネットワークに接続されている) は、存在しないサブドメインからの Set-Cookie ヘッダーを持つレスポンスを提供される可能性があります。ブラウザーは違法なクッキーを保存し、example.com の下の他のすべてのページにそれを送信します。</p>
 
-<p>セッションの固定化は主に、ユーザが認証するときに (たとえクッキーがすでに存在していても) セッションクッキーの値を再生成し、 CSRF トークンをユーザに結びつけることによって緩和されるべきです。</p>
+<p>セッションの固定化は主に、ユーザーが認証するときに (たとえクッキーがすでに存在していても) セッションクッキーの値を再生成し、 CSRF トークンをユーザーに結びつけることによって緩和されるべきです。</p>
 
 <h3 id="セッションのサイドジャッキング">セッションのサイドジャッキング</h3>
 
-<h3 id="ブラウザハイジャックマルウェア">ブラウザハイジャックマルウェア</h3>
+<h3 id="ブラウザーハイジャックマルウェア">ブラウザーハイジャックマルウェア</h3>