[7] 認証は、合言葉その他の方法によってクライアントが鯖の資源にアクセスする権限を有しているか確認し、限定する機能です。 基本認証や OAuth が広く用いられています。
[4] HTTP認証に関わる次のHTTP状態符号があります。
[8] HTTP認証では基本認証や OAuth をはじめ、
色々な認証方式を用いることができます。詳しくは
auth-scheme を参照してください。
[11] 起源鯖は、保護された資源に対する要求で credentials がなかったり、
非妥当な credentials (例えば誤ったパスワード) が指定されていたり、
不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階)
が指定されていたりする場合には、最低1つの (おそらくは新しい)
challenge が指定された WWW-Authenticate:
ヘッダーを含む 401 応答を送信するべきです >>10。
[12] 認証が必要な串は、要求で串についての credentials がなかったり、
非妥当な credentials (例えば誤ったパスワード) が指定されていたり、
不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階)
が指定されていたりする場合には、最低1つの (おそらくは新しい)
challenge が指定された Proxy-Authenticate:
ヘッダーを含む 407 応答を送信するべきです >>10。
[13] 鯖は、妥当な credentials が含まれていて、なお適切なアクセス権を有しない場合には、
403 応答を返すべきです >>10。
[32] Webブラウザーが対応するべき (または対応するべきでない) 認証方式については、 認証方式の項を参照。
[33] credentials の再利用については、 credentials、 パスワードマネージャー、ダイジェスト認証を参照。
[35] Webブラウザーは、利用者にダイアログを表示して利用者名と合言葉を尋ねるのが普通です。
realm 引数があれば、それをダイアログに表示します。
[36] HTTP認証ダイアログには、起源サーバーの認証のためのものと、 プロキシの認証のためのものがあります。 利用者に対してどちらであるのか明確に表示する必要があります。
[38] 悪意あるサーバーによる spoofing で、 他のサイトと見せかけて利用者名や合言葉を収集される危険性があります >>37。 従ってダイアログはフィッシング対策が必要となります。
realm を表示する際に、他のサイトやシステムのメッセージと誤認されにくい形とするよう配慮する必要もあります。
窓が最小化されていたり、他のタブが表示されていたり、
フレームとして埋め込まれていたりして、どの閲覧文脈と認証ダイアログが対応しているのか利用者に分かりにくい状態となることも、
避けるべきでしょう。[34] 認証ダイアログの表示中Webブラウザーの他の関係ない機能まで使えなくならないよう、 利用者の便宜をはかることが望ましいと考えられます。
[40] 実装によっては、合言葉として非ASCII文字を入力できません。 そのような実装方法は望ましくないと思われますが、 サーバーは非ASCII文字を使うべきではないでしょう。
[56]
Chrome はいつのまにか fetch
で認証ダイアログが出ず、
即座に
401
Response
をスクリプトにわたすようになりました。
(昔はちゃんと出てたのに。)
どうして非互換変更しちゃうんだろうなあ。
[16] HTTP では資源にどのような認証によるアクセス制御が適用されているかクライアントが確実に知る方法はありません。 認証の有無によって応答が成功するかエラーになるか異なる場合もありますが、 認証しない「匿名」権限でも一部のみアクセスできるような場合もあります。
[17] If-Match: にダミーの実体タグを指定してダミーの PUT
要求を (認証なしで) 送信すると、認証が必要なら 401
応答と WWW-Authenticate: ヘッダーが返され、
必要ないとしても If-Match: の実体タグと実際の実体タグが一致しないので、
PUT は実行されません。 >>15
[20] Authorization: ヘッダーに適当な
(認証を通過しなそうな) 値を指定して送信することで、401
応答と WWW-Authenticate: ヘッダーが返されると期待できます
>>15。
[1] [IE5] Office ドキュメントを開くと認証ダイアログが表示される http://support.microsoft.com/default.aspx?scid=kb;ja;415541
基本認証のかかったページ内にある Excel などの Office ドキュメントを Internet Explorer 5 上から開こうとすると、再度、認証ダイアログが表示される現象
Office 2000 アプリケーションが Internet Explorer から起動される場合、Internet Explorer のキャッシュを利用せずに、Internet Explorer から渡された URL から自分自身で、ファイルをダウンロードして、ファイルを表示するようになっています。Internet Explorer は、他のプロセスにパスワードなどの認証情報を引き継がないため、Office 2000 アプリケーションが認証情報を設定せずに、Web サーバへリクエストを送信するためです。
[57] 逆プロキシとアプリケーションサーバーが分離されているタイプの (中規模・大規模の) Webアプリケーションで、 HTTP認証をプロキシサーバーに担当させ、 アプリケーションサーバーは認証済みの要求だけが来るものと想定して認証しない設計が、 しばしば使われます。
[58] この設計方法には、多数のアプリケーションサーバーがあっても認証情報をプロキシサーバー側に集約でき、 アプリケーションサーバーはアプリケーションロジックに集中できるという管理運用上のメリットがあります。
[59] ところがこの設計方法は、ちょっとしたミスで認証なしでのアクセスを認めてしまうという、 脆弱性と隣合わせです。設計当初、すべてがうまく機能しているうちは、 まったく問題がありません。長く運用しているうちに、気付かないでミスを起こし、 長く脆弱な状態のまま放置してしまいがち、という嫌なタイプです。 具体的には、
[63]
あるプロキシサーバーで URL path が /admin/ から始まる
(大文字・小文字を区別する)
なら認証する、
と設定しているとします。
対応するアプリケーションサーバー側で、
WAF のルーティングによって
URL path /admin/
をプログラミング言語側の
Admin
という名前の処理に割り当てているとします。
ところが実はアプリケーション開発者は気づいていませんでしたが、
WAF のルーターは
URL path /ADMIN/
も
Admin
という名前の処理に割り当てているとしたらどうでしょうか。
開発者はプロキシサーバーで認証されていると思っていますが、
実は認証を回避できる抜け道が存在しています。
[9] HTTP では、 HTTP 本体の機能である HTTP認証の他に、 用途や個々の Webアプリケーション特有の色々な認証方式が用いられています。 例えば次のものがあります。
[22] HTTPキャッシュは HTTP認証については適切に処理するのが既定の動作になっていますが、
それ以外の認証方式には対応できないので、適宜 Cache-Control:
ヘッダーなどで制御する必要があります。 (通常はクライアントも鯖も、
相手との間にキャッシュが存在するかどうか知り得ないので、両者共に適切なヘッダーを指定する必要があります。)
[1] HTTP Authentication with HTML forms : Paul James http://www.peej.co.uk/articles/http-auth-with-html-forms.html
[408] draft-williams-websec-session-continue-proto-00 - Hypertext Transport Protocol (HTTP) Session Continuation Protocol ( ( 版)) http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00
[410] draft-oiwa-httpauth-multihop-template-00 - Common Template for HTTP Message-based Multi-hop Authentication ( ( 版)) https://tools.ietf.org/html/draft-oiwa-httpauth-multihop-template-00
[411] draft-williams-httpbis-auth-classification-01 - A Proposals for Classification and Analysis of HTTPbis Authentication Proposals ( ( 版)) http://tools.ietf.org/html/draft-williams-httpbis-auth-classification-01
[413] Define authentication entries a bit better https://www.w3.org/Bugs/Publi... · bffaa17 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/bffaa17cdad4f7924548233d24ff14b0ae793bbb
[414] XEP-0070: Verifying HTTP Requests via XMPP ( ( 版)) http://xmpp.org/extensions/xep-0070.html
Chrome supports four authentication schemes: Basic, Digest, NTLM, and Negotiate. Basic, Digest, and NTLM are supported on all platforms by default. Negotiate is supported on all platforms except ChromeOS by default.
When a server or proxy accepts multiple authentication schemes, our network stack selects the authentication scheme with the highest score:
Basic: 1
Digest: 2
NTLM: 3
Negotiate: 4
The Basic scheme has the lowest score because it sends the username/password unencrypted to the server or proxy.
So we choose the most secure scheme, and we ignore the server or proxy's preference, indicated by the order in which the schemes are listed in the WWW-Authenticate or Proxy-Authenticate response headers. This could be a source of compatibility problems because MSDN documents that "WinInet chooses the first method it recognizes." Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.
[25] Handling Authentication (Windows) ( 版) https://msdn.microsoft.com/en-us/library/aa384220(VS.85).aspx
[26] Part3 - browsersec - Browser Security Handbook, part 3 - Browser Security Handbook - Google Project Hosting ( 版) https://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication
Servers MUST support either Basic or Digest authentication; they are
not required to support both. Clients MUST support both to
interoperate with servers that support one or the other. Servers may
provide a login page that triggers HTTP authentication. Clients
should continue sending the HTTP authentication header once they
receive an initial 401 (Unauthorized) response from the HTTP server
as long as the scheme portion of the URL doesn't change.
[29] Bug 25791 – [new feature] Provide a way to opt out of authentication dialogs ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25791
[41] Fix #209: no credential prompt when credentials mode is not include · whatwg/fetch@10cb34f ( 版) https://github.com/whatwg/fetch/commit/10cb34f48160b21c1013aa720242f4bb12eceb45
[42] 21013 – Credentials and HTTP authentication ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013
HTTP Basic and Digest authentication MUST only be performed over TLS
1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST
NOT be used because they do not provide confidentiality or support
mutual certificate-based or certificate-less authentication,
respectively.
As specified in "Certificate Management over CMS
(CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume
client support for any type of HTTP authentication such as cookies,
Basic authentication, or Digest authentication". Clients SHOULD
support the Basic and Digest authentication mechanism.
A client MAY set the username to the empty string ("") if it is
presenting a password that is not associated with a username.
[46] RFC 8053 は、 HTTP認証の拡張機能を提案するもので、 に出版されました >>47。
[48] 現在主流の HTML フォームベースの認証にはフィッシングなどの問題があると指摘して、 新しい方法を提案しています。認証方式は既存の HTTP認証のものを流用しているものの、 新しいHTTPヘッダーを導入するなど既存の HTTP認証の方式との互換性はありません。 また、広く使われているフォームやクッキー認証との互換性もありません。
[49] 主要な Webブラウザーは実装していませんし、 Webサーバー側の開発者にとっても既存の方式から乗り換えるだけのメリットがあるのかは謎です。 今後普及する見込みがあるのかどうかは不明です。
[50] Use Fetch terminology for HTTP authentication. (mikewest著, ) https://github.com/w3c/webappsec-clear-site-data/commit/78abb9acf975d4a48870138bc40d9d77626219e4
[51] HTTP Authentication - WHATWG Wiki () https://wiki.whatwg.org/wiki/HTTP_Authentication
[52] 174179 - Re-Re-Think HTTP Basic Auth experience with respect to embedded content - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=174179
[53] Stop saying HTTP authentication over WebSocket is disallowed (ricea著, ) https://github.com/whatwg/fetch/commit/8b070f14a1fb2d1f8f4d07e1902a40a14f77b060
[54] WebSocket: "HTTP authentication will not function" is not correct · Issue #565 · whatwg/fetch () https://github.com/whatwg/fetch/issues/565
[55] Stop saying WebSocket auth is disallowed by ricea · Pull Request #761 · whatwg/fetch () https://github.com/whatwg/fetch/pull/761
[66] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--location-trusted
[67] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#-n
[68] GNU Wget 1.20 Manual () https://www.gnu.org/software/wget/manual/wget.html#index-authentication-2
[69] CACAO Security Playbooks Version 1.0 (, ) https://docs.oasis-open.org/cacao/security-playbooks/v1.0/cs01/security-playbooks-v1.0-cs01.html#_lzonmc14ppik
Proxy-Authorization:ヘッダーを削除して転送しますが、 串の構成によってはそのまま転送することもあります。Proxy-Authorization:ヘッダーの項を参照。