From 2002ca53aa5aa00259ba9b1078b9389b8460d707 Mon Sep 17 00:00:00 2001
From: x270 <42441861+x270@users.noreply.github.com>
Date: Mon, 3 May 2021 10:29:47 +0900
Subject: Docs/Web/Security/Types_of_attacks の修正 (#566)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* Docs/Web/Security/Types_of_attacks

CSRFの章タイトル位置が誤っていたのを修正。
CSRFの章の第一段落が未翻訳だったのを追加。
Web サーバー、Web アプリケーション、Web サイトをそれぞれ「ウェブ～」に修正。
「サーバ」と「サーバー」の混在を「サーバー」へ統一。

* Web / security / types_of_attacks
---
 files/ja/web/security/types_of_attacks/index.html | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

(limited to 'files/ja/web')

diff --git a/files/ja/web/security/types_of_attacks/index.html b/files/ja/web/security/types_of_attacks/index.html
index 45edd24b04..fe99ad3a25 100644
--- a/files/ja/web/security/types_of_attacks/index.html
+++ b/files/ja/web/security/types_of_attacks/index.html
@@ -11,15 +11,13 @@ translation_of: Web/Security/Types_of_attacks
 
 <p>クリックジャッキングとは、ユーザーを騙して、ユーザーが思っているものとは別のリンクやボタンなどをクリックさせることです。これは、例えば、ログイン認証情報を盗んだり、マルウェアの一部をインストールするためにユーザーの無意識のうちに許可を得るために使用することができます。(クリックジャッキングは、「ユーザーインターフェースのリドレス」と呼ばれることもありますが、これは「リドレス」という用語の誤用です)。</p>
 
-<h2 id="クロスサイトリクエストフォージェリ_CSRF">クロスサイトリクエストフォージェリ (CSRF)</h2>
-
 <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番目に多いWebアプリの脆弱性</a>だったという。</p>
+<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>これらの攻撃は、Web アプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに {{glossary("HTML")}} コンテンツを書き換えさせたりします。</p>
+<p>これらの攻撃は、ウェブアプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに {{glossary("HTML")}} コンテンツを書き換えさせたりします。</p>
 
-<p>クロスサイトスクリプティング攻撃は、通常、1) 信頼されていないソース (多くの場合、Web リクエスト) を介して Web アプリにデータが入力されたり、2) 悪意のあるコンテンツが検証されずに動的なコンテンツが Web ユーザーに送信されたりした場合に発生します。</p>
+<p>クロスサイトスクリプティング攻撃は、通常、1) 信頼されていないソース (多くの場合、ウェブリクエスト) を介してウェブアプリにデータが入力されたり、2) 悪意のあるコンテンツが検証されずに動的なコンテンツがウェブユーザーに送信されたりした場合に発生します。</p>
 
 <p>悪意のあるコンテンツには、{{glossary("JavaScript")}} が含まれていることが多いですが、HTML、Flash、またはブラウザが実行できるその他のコードが含まれていることもあります。XSS に基づく攻撃の種類はほぼ無限にありますが、一般的には、クッキーなどのセッション情報などのプライベートデータを攻撃者に送信したり、攻撃者が管理するウェブページに被害者をリダイレクトさせたり、脆弱性のあるサイトを装ってユーザーのマシンに悪意のある操作を行ったりすることが多いです。</p>
 
@@ -29,11 +27,15 @@ translation_of: Web/Security/Types_of_attacks
  <dt>格納された XSS 攻撃</dt>
  <dd>注入されたスクリプトは、ターゲットのサーバーに永久に保存されます。そして、被害者は、ブラウザがデータの要求を送信すると、この悪意のあるスクリプトをサーバーから取得します。</dd>
  <dt>反映された XSS 攻撃</dt>
- <dd>ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のある Web サイトに移動します。Web サーバは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバに送信されたデータを含むその他の応答など、ユーザのブラウザに反映させます。ブラウザは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバからのものであると想定しているため、コードを実行します。</dd>
+ <dd>ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のあるウェブサイトに移動します。ウェブサーバーは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバーに送信されたデータを含むその他の応答など、ユーザのブラウザに反映させます。ブラウザは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバーからのものであると想定しているため、コードを実行します。</dd>
  <dt>DOM ベースの XSS 攻撃</dt>
  <dd>ペイロードは、元のクライアントサイドスクリプトが使用していた DOM 環境 (被害者のブラウザ内) を変更した結果、実行されます。つまり、ページ自体は変わりませんが、DOM 環境を悪意を持って改変した結果、ページに含まれるクライアント側のコードが予期せぬ形で実行される。</dd>
 </dl>
 
+<h2 id="クロスサイトリクエストフォージェリ_CSRF">クロスサイトリクエストフォージェリ (CSRF)</h2>
+
+<p>CSRF ( XSRF とも呼ぶ) は、関連するクラスの攻撃です。攻撃者はユーザーのブラウザにユーザーの同意なく、または、知らないうちにウェブサイトのバックエンドへの要求を実行させます。攻撃者は XSS ペイロードを使用して CSRF 攻撃を開始できます。</p>
+
 <p>Wikipedia には、CSRF の良い例が記載されています。この状況では、誰かが (例えば、フィルタリングされていないチャットやフォーラムで) 実際には画像ではない画像を含むが、その代わりに、それは本当にお金を引き出すためにあなたの銀行のサーバーへのリクエストです。</p>
 
 <pre class="brush: html notranslate">&lt;img src="https://bank.example.com/withdraw?account=bob&amp;amount=1000000&amp;for=mallory"&gt;</pre>
@@ -54,7 +56,7 @@ translation_of: Web/Security/Types_of_attacks
  <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>機密性の高い動作 (セッションクッキーなど) に使用されるクッキーは、SameSite 属性を Strict または Lax に設定して、有効期限を短くする必要があります (上記の SameSite cookies を参照)。サポートしているブラウザでは、これはクロスサイトリクエストと一緒にセッションクッキーが送信されないようにする効果があり、そのリクエストはアプリケーションサーバーに対して事実上認証されません</li>
  <li>CSRF トークンと SameSite Cookie の両方を導入する必要があります。これにより、すべてのブラウザが保護され、SameSite のクッキーでは対応できない場合 (別のサブドメインからの攻撃など) にも保護されます</li>
 </ul>
 
-- 
cgit v1.2.3-54-g00ecf