> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> さまざまな種類のサイバー攻撃と、それらを防ぐためにどのような対策を講じられるかについて説明します。

# 一般的なサイバーセキュリティの脅威を防ぐ

一般的なサイバーセキュリティの脅威には、次のようなものがあります。

* バケツリレー攻撃
* リプレイ攻撃
* クロスサイトリクエストフォージェリ (CSRF または XSRF) 攻撃
* 総当たり攻撃
* <Tooltip tip="Suspicious IP Throttling: 単一の IP アドレスから多数のアカウントを標的とする不審なログインからテナントを保護する攻撃対策の一種です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Suspicious+IP+throttling">Suspicious IP throttling</Tooltip>
* クレデンシャルスタッフィング攻撃
* リスト検証攻撃

Auth0 には、特定の種類の攻撃を防ぐのに役立つ[攻撃対策機能](/docs/ja-jp/secure/attack-protection)があります。

<div id="bucket-brigade-attacks">
  ## バケツリレー攻撃
</div>

脅威の一種に、バケツリレー攻撃があります。これは「中間者攻撃」と呼ばれることもあり、攻撃者が二者の間に割り込む攻撃です。双方はプライベートな接続を通じてやり取りしているつもりでも、実際にはその通信はサードパーティの攻撃者に制御されています。この種の攻撃を成立させるには、攻撃者が両者との間で相互認証を成立させなければなりません。

通常、バケツリレー攻撃では、攻撃者が WiFi ルーターを使ってユーザーの通信を傍受します。ユーザーは攻撃者のルーターに接続し、その後 Web サイトにアクセスして機密の資格情報でログインします。攻撃者はそのユーザーのログイン資格情報を保存し、後からそれを使ってユーザーになりすますことができます。

一部のバケツリレー攻撃では、アプリケーションとサーバーの間で送信されるデータが改ざんされることもあります。こうした攻撃は、新しい PC の試用版ソフトウェアやプリインストール済みソフトウェア、ソフトウェア更新ツール、そのほかのソフトウェアの脆弱性を通じて発生する可能性があります。最悪の場合、これによりリモートコード実行、システムへのバックドア設置、マルウェアのインストールなどにつながるおそれがあります。また、他のネットワーク資産の侵害につながる可能性もあります。

この種の攻撃への対策としては、アプリケーションとサーバーの間で強力な暗号化と認証を使用することが重要です。暗号化を用いることで、サーバーはデジタル証明書を提示してアプリケーションのリクエストを認証し、その後でのみ接続を確立できます。たとえば、HTTPS はブラウザーの secure sockets layer (SSL) 機能を使用して Web トラフィックを保護します。HTTPS を復号するには、攻撃者はネットワークトラフィックの暗号化に使用されるキーを入手しなければなりません。

サーバーで TLS を構成する際は、TLSv1.2 を使用する [Mozilla OpSec recommendations](https://wiki.mozilla.org/Security/Server_Side_TLS) に従うことを推奨します。Mozilla は [SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/) も提供しています。これを使用するには、まずサーバーが稼働しているプラットフォームを選択し、次にアプリケーション基盤でサポート可能な範囲で最も新しい構成を選択します。より新しい構成では、攻撃の防止に役立つ、より強力な暗号アルゴリズムが提供されます。

<div id="replay-attacks">
  ## リプレイ攻撃
</div>

リプレイ (または再生) 攻撃により、攻撃者は次のことが可能になります。

* 本来であれば容易にアクセスできないネットワークや情報にアクセスする
* 重複した取引を完了する

これは、別の送信者によるデータ送信を意図された受信システムに再送することで、セキュリティプロトコルを攻撃するものです。こうした攻撃によって、データ送信が正常に完了したと参加者に誤認させます。

リプレイ攻撃は、セッショントークンを使用することで回避できます。ただし、これらの資格情報がローカルストレージから盗まれた場合 (XSS 攻撃時など) には、誰かが有効なトークンをいつまでも保持し続けることを防ぐ方法があります。

* トークンの有効期限を短く設定する
* 使用されたトークン (場合によってはユーザーも) を DenyList に追加できるようにする
* ワンタイムパスワードを使用する

[JWT](/docs/ja-jp/secure/tokens/json-web-tokens) 仕様では、リプレイ攻撃を防ぐ方法として `jti` フィールドが提供されています。Auth0 のトークンは現在 `jti` を返しませんが、`jti` を使用してトークンを DenyList に追加することで、指定回数を超えてトークンが使用されるのを防げます。これは、<Tooltip tip="Nonce: リプレイ攻撃を検出して防ぐために、認証プロトコルで一度だけ発行される任意の数値。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=nonce">nonce</Tooltip> に似た仕組みを実装していると考えられます (トークンの署名を nonce と考えてください) 。トークンが盗まれた場合や、指定回数を超えて使用された場合は、DenyList に追加する必要があります。これにより、有効なトークンが悪意をもって使用されるのを防げます。トークンの有効期限が切れれば、攻撃者はそのユーザーになりすますことができなくなります。

ワンタイムパスワードを使用してリプレイ攻撃を回避することもできます。Auth0 では、従来のパスワードではなく、使い捨てコードやメールリンクを利用する<Tooltip tip="パスワードレス: 第一要素としてパスワードに依存しない認証の形式。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Passwordless">パスワードレス</Tooltip>認証を使用できます。Auth0 はまた、プッシュ通知や SMS で送信できるワンタイムパスワードを第 2 の認証要素として使用する<Tooltip tip="多要素認証 (MFA): SMSによるコードなど、ユーザー名とパスワードに加えて認証要素を使用するユーザー認証プロセス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=multi-factor+authentication">多要素認証</Tooltip> (MFA) も提供しています。

<div id="cross-site-request-forgery">
  ## クロスサイトリクエストフォージェリ
</div>

クロスサイトリクエストフォージェリ (CSRF または XSRF) 攻撃は、悪意のあるプログラムによって、ユーザーが現在認証済みの信頼されたサイトに対し、ユーザーの意図しない操作をウェブブラウザーに実行させられることで発生します。攻撃者は偽造されたリクエストのレスポンスを確認する手段を持たないため、この種の攻撃はユーザーデータの取得ではなく、特定の操作を開始するような状態変更を伴うリクエストを主な標的とします。

送信されるリクエストを検証する方法の 1 つとして、レスポンスを認証するために、<Tooltip tip="認可プロトコルとワークフローを定義するOAuth 2.0の認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> プロトコルの[state パラメーター](/docs/ja-jp/secure/attack-protection/state-parameters)を利用できます。

<div id="learn-more">
  ## 詳しくはこちら
</div>

* [トークン](/docs/ja-jp/secure/tokens)
* [攻撃対策](/docs/ja-jp/secure/attack-protection)
* [一般的なセキュリティのヒント](/docs/ja-jp/secure/security-guidance/tips)