From a79e77a6ce3cb71a63f8dafa105c10c6967598bf Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Sat, 19 Feb 2022 23:07:31 +0900 Subject: Web/HTTP/Authentication を移行 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- files/ja/web/http/authentication/index.html | 144 ---------------------------- files/ja/web/http/authentication/index.md | 144 ++++++++++++++++++++++++++++ 2 files changed, 144 insertions(+), 144 deletions(-) delete mode 100644 files/ja/web/http/authentication/index.html create mode 100644 files/ja/web/http/authentication/index.md (limited to 'files/ja/web') diff --git a/files/ja/web/http/authentication/index.html b/files/ja/web/http/authentication/index.html deleted file mode 100644 index bc7bb26fee..0000000000 --- a/files/ja/web/http/authentication/index.html +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: HTTP 認証 -slug: Web/HTTP/Authentication -tags: - - Access Control - - Authentication - - Guide - - HTTP - - Security - - アクセス制限 - - セキュリティ - - 認証 -translation_of: Web/HTTP/Authentication ---- -
{{HTTPSidebar}}
- -

HTTP はアクセス制御と認証の基本的な枠組みを提供しています。このページでは、HTTP の認証の枠組みを紹介し、サーバーで HTTP の "Basic" 認証を使用してアクセスを制限する方法を紹介します。

- -

一般的な HTTP 認証の枠組み

- -

{{RFC("7235")}} は、サーバーがクライアント要求を {{glossary("challenge")}} し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義しています。

- -

チャレンジとレスポンスの流れは以下のようになります。

- -
    -
  1. サーバーは少なくとも１回のチャレンジで、クライアントに {{HTTPStatus("401")}} (Unauthorized) レスポンスステータスを返し、 {{HTTPHeader("WWW-Authenticate")}} レスポンスヘッダーを含めて認証方法に関する情報を提供します。
    2. -
  2. サーバーで自身を認証したいクライアントは {{HTTPHeader("Authorization")}} リクエストヘッダフィールドに資格情報を含めることでそれを行うことができます。
    3. -
  3. 通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい Authorization ヘッダーを含むリクエストを発行します。
    4. -
- -

クライアントとサーバーのライフライン間の HTTP メッセージを説明するシーケンス図。

- -

この図に示したような "Basic" 認証の場合、やり取りは安全のために HTTPS (TLS) 接続を介して行われなければなりません。

- -

プロキシ認証

- -

プロキシ認証にも同じチャレンジとレスポンスのメカニズムを使用できます。リソース認証とプロキシ認証の両方が共存できるため、異なるヘッダーとステータスコードのセットが必要です。プロキシの場合、チャレンジのステータスコードは {{HTTPStatus("407")}} (Proxy Authentication Required) で、 {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーはプロキシサーバーに資格情報を提供するために、 {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーが使用されます。

- -

アクセスの不許可

- -

特定のリソースにアクセスするのに十分ではないが有効な資格情報を (プロキシ) サーバーが受け取った場合、サーバーは {{HTTPStatus("403")}} Forbidden ステータスコードを返す必要があります。 {{HTTPStatus("401")}} Unauthorized または {{HTTPStatus("407")}} Proxy Authentication Required とは異なり、このユーザーは認証できません。

- -

オリジン間の画像の認証

- -

ブラウザーによって最近修正された潜在的なセキュリティホールとして、サイト間での画像の認証があります。 Firefox 59 以降、異なるオリジンから現在の文書に読み込まれる画像リソースは、 HTTP 認証ダイアログを起動することができなくなり ({{bug(1423146)}})、攻撃者が任意の画像をサードパーティ製のページに埋め込んでユーザーの認証情報を盗むことを防ぎます。

- -

HTTP 認証の文字エンコーディング

- -

ブラウザーはユーザー名とパスワードに utf-8 エンコーディングを使用します。

- -

Firefox は ISO-8859-1 を使用していましたが、他のブラウザーとの互換性のために utf-8 に変更され、 {{bug(1419658)}} で説明されているような潜在的な問題を回避します。

- -

WWW-Authenticate および Proxy-Authenticate ヘッダー

- -

{{HTTPHeader("WWW-Authenticate")}} および {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーは、リソースへのアクセスに使用する認証メソッドを定義します。どの認証方式を使用するかを指定するため、認証を希望するクライアントは資格情報の提供方法を知ることができます。これらのヘッダーの構文は次のとおりです。

- -

これらのヘッダーの構文は以下の通りです。

- -
WWW-Authenticate: <type> realm=<realm>
-Proxy-Authenticate: <type> realm=<realm>
-
- -

ここで、 <type> は認証スキームです ("Basic" は最も一般的なスキームであり、以下で紹介します)。 realm は保護された領域を説明するため、または保護の範囲を示すために使用されます。これは、「ステージングサイトへのアクセス」などのようなメッセージにすることができ、それによってユーザーが、どの領域にアクセスしようとしているかを知ることができます。

- -

Authorization および Proxy-Authorization ヘッダー

- -

{{HTTPHeader("Authorization")}} および {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーには、(プロキシ) サーバーがユーザーエージェントを認証する資格情報が入ります。ここでは、 <type> が再び必要となり、その後に使用される認証方式によって符号化または暗号化された資格情報が続きます。

- -
Authorization: <type> <credentials>
-Proxy-Authorization: <type> <credentials>
-
- -

認証方式

- -

一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。スキームはセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。

- -

最も一般的な認証方式は "Basic" 認証方式であり、これについては以下で詳しく説明します。 IANA は認証スキームの一覧を管理していますが、 Amazon AWS などのホストサービスが提供する他のスキームもあります。一般的な認証方式には次のものがあります。

- -
-
Basic
-
{{rfc(7617)}} を参照。 base64 でエンコードされた資格情報です。詳しくは後述します。
-
Bearer
-
{{rfc(6750)}} を参照。 OAuth 2.0 で保護されたリソースにアクセスするベアラトークンです。
-
Digest
-
{{rfc(7616)}} を参照。 Firefox では md5 ハッシュだけに対応しています。 SHA 暗号化の対応については {{bug(472823)}} を参照。
-
HOBA
-
{{rfc(7486)}} 3章 を参照、HTTP オリジン認証 (HTTP Origin-Bound Authentication)、電子署名ベース
-
Mutual
-
{{rfc(8120)}} を参照
-
AWS4-HMAC-SHA256
-
AWS docs を参照
-
- -

Basic 認証方式

- -

"Basic" HTTP 認証方式は {{rfc(7617)}} で定義されており、Base64 を使用してエンコードされたユーザー ID とパスワードのペアとしてクレデンシャルを送信します。

- -

Basic 認証の安全性

- -

ユーザー ID とパスワードはネットワークを介してクリアテキスト (base64 でエンコードされていますが、 base64 は可逆エンコードです) として渡されるため、 Basic 認証方式は安全ではありません。 Basic 認証と組み合わせて HTTPS/TLS を使用する必要があります。これらの追加のセキュリティ強化機能がない場合は、機密情報や重要な情報を保護するために Basic 認証を使用しないでください。

- -

Apache と Basic 認証によるアクセス制限

- -

Apache サーバー上のディレクトリをパスワードで保護するには、 .htaccess ファイルと .htpasswd ファイルが必要です。

- -

.htaccess ファイルは通常、次のようになります。

- -
AuthType Basic
-AuthName "Access to the staging site"
-AuthUserFile /path/to/.htpasswd
-Require valid-user
- -

.htaccess ファイルは .htpasswd ファイルを参照し、各行にはユーザー名とパスワードをコロン (":") で区切って記述します。実際のパスワードは暗号化されている (この場合は md5) ので表示できません。必要に応じて .htpasswd ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないように注意してください。(Apache は通常 .ht* ファイルへのアクセスを禁止するように設定されています)。

- -
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
-user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
-
- -

nginx と Basic 認証によるアクセス制限

- -

nginx の場合は、保護する場所とパスワードで保護された領域に名前を指定する auth_basic ディレクティブを指定する必要があります。auth_basic_user_file ディレクティブは上の Apache の例のように、暗号化されたユーザー資格情報を含む .htpasswd ファイルを指します。

- -
location /status {
-    auth_basic           "Access to the staging site";
-    auth_basic_user_file /etc/apache2/.htpasswd;
-}
- -

URL 内の認証情報を使用したアクセス

- -

多くのクライアントでは次のように、ユーザー名とパスワードを含むエンコードされた URL を使用してログインプロンプトを回避できます。

- -
https://username:password@www.example.com/
- -

これらの URL の使用は推奨されていません。Chrome ではセキュリティ上の理由から、URL の username:password@ 部分も削除されます。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「"username" というユーザー名で "www.example.com" というサイトにログインしようとしていますが、ウェブサイトは認証を必要としません。これはあなたを騙そうとしている可能性があります。」と警告します。

- -

関連情報

- - diff --git a/files/ja/web/http/authentication/index.md b/files/ja/web/http/authentication/index.md new file mode 100644 index 0000000000..bc7bb26fee --- /dev/null +++ b/files/ja/web/http/authentication/index.md @@ -0,0 +1,144 @@ +--- +title: HTTP 認証 +slug: Web/HTTP/Authentication +tags: + - Access Control + - Authentication + - Guide + - HTTP + - Security + - アクセス制限 + - セキュリティ + - 認証 +translation_of: Web/HTTP/Authentication +--- +
{{HTTPSidebar}}
+ +

HTTP はアクセス制御と認証の基本的な枠組みを提供しています。このページでは、HTTP の認証の枠組みを紹介し、サーバーで HTTP の "Basic" 認証を使用してアクセスを制限する方法を紹介します。

+ +

一般的な HTTP 認証の枠組み

+ +

{{RFC("7235")}} は、サーバーがクライアント要求を {{glossary("challenge")}} し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義しています。

+ +

チャレンジとレスポンスの流れは以下のようになります。

+ +
    +
  1. サーバーは少なくとも１回のチャレンジで、クライアントに {{HTTPStatus("401")}} (Unauthorized) レスポンスステータスを返し、 {{HTTPHeader("WWW-Authenticate")}} レスポンスヘッダーを含めて認証方法に関する情報を提供します。
    2. +
  2. サーバーで自身を認証したいクライアントは {{HTTPHeader("Authorization")}} リクエストヘッダフィールドに資格情報を含めることでそれを行うことができます。
    3. +
  3. 通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい Authorization ヘッダーを含むリクエストを発行します。
    4. +
+ +

クライアントとサーバーのライフライン間の HTTP メッセージを説明するシーケンス図。

+ +

この図に示したような "Basic" 認証の場合、やり取りは安全のために HTTPS (TLS) 接続を介して行われなければなりません。

+ +

プロキシ認証

+ +

プロキシ認証にも同じチャレンジとレスポンスのメカニズムを使用できます。リソース認証とプロキシ認証の両方が共存できるため、異なるヘッダーとステータスコードのセットが必要です。プロキシの場合、チャレンジのステータスコードは {{HTTPStatus("407")}} (Proxy Authentication Required) で、 {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーはプロキシサーバーに資格情報を提供するために、 {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーが使用されます。

+ +

アクセスの不許可

+ +

特定のリソースにアクセスするのに十分ではないが有効な資格情報を (プロキシ) サーバーが受け取った場合、サーバーは {{HTTPStatus("403")}} Forbidden ステータスコードを返す必要があります。 {{HTTPStatus("401")}} Unauthorized または {{HTTPStatus("407")}} Proxy Authentication Required とは異なり、このユーザーは認証できません。

+ +

オリジン間の画像の認証

+ +

ブラウザーによって最近修正された潜在的なセキュリティホールとして、サイト間での画像の認証があります。 Firefox 59 以降、異なるオリジンから現在の文書に読み込まれる画像リソースは、 HTTP 認証ダイアログを起動することができなくなり ({{bug(1423146)}})、攻撃者が任意の画像をサードパーティ製のページに埋め込んでユーザーの認証情報を盗むことを防ぎます。

+ +

HTTP 認証の文字エンコーディング

+ +

ブラウザーはユーザー名とパスワードに utf-8 エンコーディングを使用します。

+ +

Firefox は ISO-8859-1 を使用していましたが、他のブラウザーとの互換性のために utf-8 に変更され、 {{bug(1419658)}} で説明されているような潜在的な問題を回避します。

+ +

WWW-Authenticate および Proxy-Authenticate ヘッダー

+ +

{{HTTPHeader("WWW-Authenticate")}} および {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーは、リソースへのアクセスに使用する認証メソッドを定義します。どの認証方式を使用するかを指定するため、認証を希望するクライアントは資格情報の提供方法を知ることができます。これらのヘッダーの構文は次のとおりです。

+ +

これらのヘッダーの構文は以下の通りです。

+ +
WWW-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <type> realm=<realm>
+
+ +

ここで、 <type> は認証スキームです ("Basic" は最も一般的なスキームであり、以下で紹介します)。 realm は保護された領域を説明するため、または保護の範囲を示すために使用されます。これは、「ステージングサイトへのアクセス」などのようなメッセージにすることができ、それによってユーザーが、どの領域にアクセスしようとしているかを知ることができます。

+ +

Authorization および Proxy-Authorization ヘッダー

+ +

{{HTTPHeader("Authorization")}} および {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーには、(プロキシ) サーバーがユーザーエージェントを認証する資格情報が入ります。ここでは、 <type> が再び必要となり、その後に使用される認証方式によって符号化または暗号化された資格情報が続きます。

+ +
Authorization: <type> <credentials>
+Proxy-Authorization: <type> <credentials>
+
+ +

認証方式

+ +

一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。スキームはセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。

+ +

最も一般的な認証方式は "Basic" 認証方式であり、これについては以下で詳しく説明します。 IANA は認証スキームの一覧を管理していますが、 Amazon AWS などのホストサービスが提供する他のスキームもあります。一般的な認証方式には次のものがあります。

+ +
+
Basic
+
{{rfc(7617)}} を参照。 base64 でエンコードされた資格情報です。詳しくは後述します。
+
Bearer
+
{{rfc(6750)}} を参照。 OAuth 2.0 で保護されたリソースにアクセスするベアラトークンです。
+
Digest
+
{{rfc(7616)}} を参照。 Firefox では md5 ハッシュだけに対応しています。 SHA 暗号化の対応については {{bug(472823)}} を参照。
+
HOBA
+
{{rfc(7486)}} 3章 を参照、HTTP オリジン認証 (HTTP Origin-Bound Authentication)、電子署名ベース
+
Mutual
+
{{rfc(8120)}} を参照
+
AWS4-HMAC-SHA256
+
AWS docs を参照
+
+ +

Basic 認証方式

+ +

"Basic" HTTP 認証方式は {{rfc(7617)}} で定義されており、Base64 を使用してエンコードされたユーザー ID とパスワードのペアとしてクレデンシャルを送信します。

+ +

Basic 認証の安全性

+ +

ユーザー ID とパスワードはネットワークを介してクリアテキスト (base64 でエンコードされていますが、 base64 は可逆エンコードです) として渡されるため、 Basic 認証方式は安全ではありません。 Basic 認証と組み合わせて HTTPS/TLS を使用する必要があります。これらの追加のセキュリティ強化機能がない場合は、機密情報や重要な情報を保護するために Basic 認証を使用しないでください。

+ +

Apache と Basic 認証によるアクセス制限

+ +

Apache サーバー上のディレクトリをパスワードで保護するには、 .htaccess ファイルと .htpasswd ファイルが必要です。

+ +

.htaccess ファイルは通常、次のようになります。

+ +
AuthType Basic
+AuthName "Access to the staging site"
+AuthUserFile /path/to/.htpasswd
+Require valid-user
+ +

.htaccess ファイルは .htpasswd ファイルを参照し、各行にはユーザー名とパスワードをコロン (":") で区切って記述します。実際のパスワードは暗号化されている (この場合は md5) ので表示できません。必要に応じて .htpasswd ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないように注意してください。(Apache は通常 .ht* ファイルへのアクセスを禁止するように設定されています)。

+ +
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+
+ +

nginx と Basic 認証によるアクセス制限

+ +

nginx の場合は、保護する場所とパスワードで保護された領域に名前を指定する auth_basic ディレクティブを指定する必要があります。auth_basic_user_file ディレクティブは上の Apache の例のように、暗号化されたユーザー資格情報を含む .htpasswd ファイルを指します。

+ +
location /status {
+    auth_basic           "Access to the staging site";
+    auth_basic_user_file /etc/apache2/.htpasswd;
+}
+ +

URL 内の認証情報を使用したアクセス

+ +

多くのクライアントでは次のように、ユーザー名とパスワードを含むエンコードされた URL を使用してログインプロンプトを回避できます。

+ +
https://username:password@www.example.com/
+ +

これらの URL の使用は推奨されていません。Chrome ではセキュリティ上の理由から、URL の username:password@ 部分も削除されます。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「"username" というユーザー名で "www.example.com" というサイトにログインしようとしていますが、ウェブサイトは認証を必要としません。これはあなたを騙そうとしている可能性があります。」と警告します。

+ +

関連情報

+ + -- cgit v1.2.3-54-g00ecf