[35] URL には、利用者名とパスワードを記述できる欄があります。
[36] URL記録は、 利用者名を持ちます。 利用者名を表します。 値は ASCII文字列です。初期値は空文字列です。 >>34
[37] URL記録は、 パスワードを持ちます。 パスワードを表します。 値は ASCII文字列です。初期値は空文字列です。 >>34
[65] URL がcredentialsを含むとは、 利用者名かパスワードが空文字列ではないことをいいます。 >>64
[38] 現行仕様である URL Standard の URL文字列の構文の定義には、 利用者名やパスワードに相当する部分は含まれていません。
[39] つまり、著者は URL文字列を記述する時に利用者名やパスワードを含めてはならないとされています。
[43] 過去の URL 仕様では、 URL文字列の authority 部分
(URL scheme、:
、//
の後に続く部分)
に @
が含まれる場合、それより後はホストとポートであり、
それより前は userinfo と呼ばれていました。
[44] userinfo は、 :
が含まれていればそれより前が利用者名で後がパスワード、
含まれなければ全体が利用者名とされていました。
[45] 利用者名やパスワードは、 それぞれ0個以上のURL単位群の列とされていました。
[48] 利用者名やパスワードは、空文字列とすることもできます。 しかし空文字列は既定値ですから、無指定の場合と区別できません。
[41] これは利用者名やパスワードを URL に含めるのはセキュリティー上好ましくないという近年の流れに沿った制限だと思われます。
[42] しかし Unix 系環境で動作するプログラムの環境変数で URL を指定する場合、 Webアプリケーションでアクセス先の URL (Web Hooks など) を指定する場合、 プロキシを指定する場合、 データベースのURLを指定する場合のように、 利用者名とパスワードが大いに活用されている場面もあり、 それらがすべて無くなるとも思えません。むしろ、 userinfo を禁止することにより path や query に埋め込んで回避しようとする動きが出る方が危険が多様化して好ましくないと感じますが...
[46] URLの構文解析では、利用者名やパスワードの一部とみなされる部分を、 userinfo符号化集合を使ってUTF-8パーセント符号化します。 >>53
[27] URL文字列に非ASCII文字が含まれる場合、URLの構文解析の時点で UTF-8パーセント符号化されます (>>46)。つまり UTF-8 として扱われます。
[49] URL文字列にパーセント符号化が含まれる場合、 URL の他の部分の場合と同様、元の文字コードは特に規定されていません。 つまりどの文字コードか分かりませんし、そもそも文字列であるかも保証されません。
[50] 利用者名やパスワードのパーセント符号化を復号した後どのように解釈するべきかは、 現行のどの仕様書でも明文化されていないと思われます。
[51] Webブラウザーは、 http:
や https:
で利用者名やパスワードが含まれる時、
パーセント復号して何らかの文字コードで復号して、
HTTP認証に使っているものと思われます。
[67] URL
インターフェイスの
username
IDL属性の取得器は、
次のようにしなければなりません >>66。
[69] 同じく設定器は、次のようにしなければなりません >>66。
[73] URL
インターフェイスの
password
IDL属性の取得器は、
次のようにしなければなりません >>66。
[75] 同じく設定器は、次のようにしなければなりません >>66。
[83] HTMLHyperlinkElementUtils
インターフェイスの
username
IDL属性の取得器は、
次のようにしなければなりません >>79。
[88] 同じく設定器は、 CEReactions
と共に、
次のようにしなければなりません >>79。
[95] HTMLHyperlinkElementUtils
インターフェイスの
password
IDL属性の取得器は、
次のようにしなければなりません >>79。
[100] 同じく設定器は、CEReactions
と共に、
次のようにしなければなりません >>79。
[54] URL記録と利用者名の利用者名の設定は、次のようにします >>53。
[58] URL記録とパスワードのパスワードの設定は、次のようにします >>53。
userinfo
として使う例[33] URLの構文解析で使われます。 userinfo が含まれる入力の場合や、 URL の利用者名や合言葉を設定する時に参照されます。
[11] Issue 82250 - chromium - HTTP username:password stripped out from links - An open-source browser project to help move the web forward. - Google Project Hosting ( 版) http://code.google.com/p/chromium/issues/detail?id=82250
[12] Masato Kinugawa Security Blog: CVE-2012-0678: Safariのfeed:// URLのUXSS ( ( 版)) http://masatokinugawa.l0.cm/2012/11/safari-feed-url-uxss.html
[13] Factor out set the username and password algorithms for use by XMLHttpRe... · 4e2f350 · whatwg/url ( ( 版)) https://github.com/whatwg/url/commit/4e2f35062170f11924a35f06abb5e2fb014e48c6
[14] Use the set the username/password algorithms · d699900 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/d699900add11588f35a1d6c74987f288f975f103
[15] Throw if URL includes credentials. Fixes #26. Also more HTTPS. · whatwg/fetch@32ab411 ( 版) https://github.com/whatwg/fetch/commit/32ab4119f9aa5d280507d6201b0784cfe5669106
[16] 479038 – Should the suspicious-auth warning apply to all loads? Should URI userinfo be banned? ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=479038
[17] Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs) ( 版) https://support.microsoft.com/en-us/kb/834489
[18] Copy username/password for relative URLs · whatwg/url@06b2e68 ( 版) https://github.com/whatwg/url/commit/06b2e6895dff2e6efaeba65f4eb1bc27ecc21581
[19] Encode { and } in username/password/path to fix #16. Also acknowledge… · whatwg/url@c296e2f ( 版) https://github.com/whatwg/url/commit/c296e2f8519a1d6614d664708d368a342682c9a1
[20] Make it non-conforming to place a username and/or password in a URL. … · whatwg/url@e0c721b ( 版) https://github.com/whatwg/url/commit/e0c721b680d0977013ef2a14ba578388c01bd331
[21] Use the username and password encode sets within authority state. Fix… · whatwg/url@7876306 ( 版) https://github.com/whatwg/url/commit/78763066648b921c51b0920493c67fc166c3e6f3
[22] Bug 26340 – Ignoring username and password from the base URL? ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=26340#c2
sequelpro://$SP_PROCESS_ID@chooseItemFromList/item1/item2/…
[24] Encode more code points for usernames and passwords. Fixes #30. · whatwg/url@9ca26e5 ( 版) https://github.com/whatwg/url/commit/9ca26e5b0edc131f9cca81d0fef4ab92815bc289
[25] Use "include credentials" from the URL Standard rather than copying i… · whatwg/fetch@2c68504 ( 版) https://github.com/whatwg/fetch/commit/2c68504a5ea6c6742212a31dc357ceab12862296
Some proxy servers require authorization to enable you to use them. The authorization consists of username and password, which must be sent by Wget. As with HTTP authorization, several authentication schemes exist. For proxy authorization only the Basic authentication scheme is currently implemented.
You may specify your username and password either through the proxy URL or through the command-line options. Assuming that the company’s proxy is located at ‘proxy.company.com’ at port 8001, a proxy URL location containing authorization data might look like this:
http://hniksic:mypassword@proxy.company.com:8001/
[28] Fix #44: replace "relative flag" with non-null host check · whatwg/xhr@fabeb1a ( 版) https://github.com/whatwg/xhr/commit/fabeb1a5de040041e213ccd68c63a0d694c2879b
Internet Explorer 3.0 ~ 6.0 では HTTP URL および HTTPS URL で次の構文がサポートされています。
http(s)://username:password@server/resource.ext
この URL 構文を使用すると、基本認証方式をサポートする Web サイトにユーザー情報が自動的に送信されます。
この資料の「背景情報」に記載されている問題を抑制するため、Internet Explorer およびエクスプローラーでは、この形式の HTTP URL および HTTPS URL の処理をサポートしないようになりました。エクスプローラーおよび Internet Explorer では、ユーザー情報を含む URL を使用して HTTP サイトまたは HTTPS サイトを開くことはできません。ユーザー情報が HTTP URL または HTTPS URL に含まれている場合、既定で次のタイトルの Web ページが表示されます。
無効な構文エラー
注: この既定の動作の変更は、他のプロトコルには影響を与えません。たとえば、セキュリティ更新プログラム 832894 をインストールした後でも、FTP URL にはユーザー情報を含めることができます。
この既定の動作の変更は、セキュリティ更新プログラム 832894 のリリース以降にリリースされたセキュリティ更新プログラム、Service Pack、および Internet Explorer の各バージョンでも実装されています。
The following connects to a replica set with two members, one on db1.example.net and the other on db2.example.net:
mongodb://db1.example.net,db2.example.com
[107] No need for null passwords (annevk著, ) https://github.com/whatwg/url/commit/5e0b05e95a81fdd539c7b1bf97e69b3df701384f
[108] Editorial: stop referring to a password alone as credentials (annevk著, ) https://github.com/whatwg/url/commit/240e61d45023b6742d35ac18f14560fcc2ab4bfe
[109] Align <a>/<area>.password with the URL Standard (annevk著, ) https://github.com/whatwg/html/commit/165aeecfb1818912219afc50dd2dd1c6ec935ae2
I'd like to block two kinds of subresource requests from webby documents:
1. Subresources with an "legacy" scheme (e.g. "ftp://my-awesome-ftp-server.com/yay.tiff")
2. Subresources with credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff").
[111] A file URL cannot have credentials (annevk著, ) https://github.com/whatwg/url/commit/9b2eb10eb8436adaf6620b1864b25442152f205b
[112] Editorial: use specific names for encode sets (annevk著, ) https://github.com/whatwg/url/commit/1d69a774bab856651e0d792e825a976056aeaf59
Basic認証を利用しているURLを監視したい場合は"user:password@監視先URL"としてください
ベーシック認証を設定しURLに認証情報を含める
https://user:p4ssw0rd@example.com のような形式
Basic認証のかかったサーバへも、userinfo を URL に含むことによって Web フックを送信できるように対応しました。
Password-based authorization - The webhook URI is saved with a username and password, eg. https://userid:password@mysamplealert/webcallback?someparamater=somevalue&foo=bar
While it's already possible to include basic auth credentials directly in the webhook URL (e.g. http://username:password@example.com/foobar), the URL and credentials are written to the Sync Gateway log every time a webhook event is issued. This makes it less than ideal because, in general, secrets should not appear in logs.
For Atlassian applications, the REST plugin : https://developer.atlassian.com/display/DOCS/REST+and+os_authType allows you to apend the authentication type to the URL. This can be adapted as a workaround. When I add the os_oauthtype to the URL, it works:
http://localhost:10520/bamboo52/rest/api/latest/server/pause?os_authtype=basic&os_username=admin&os_password=admin
Note: While this workaround works, it's not great because applications frequently log URLs (for example, Apache can be configured that way) and this means that the password will be leaked, which is not desirable.
webhookの認証を必要とするサービスと連携するには、HTTPのベーシック認証を使い、登録するURLの部分を次のように書き換えて下さい。
https://my.service.com —> https://username:password@my.service.com
We support basic HTTP authentication in our Event Webhook. Those who wish to implement can provide credentials in the post event url field on the app settings page. Below is an example of the post url with authentication included.
http(s)://username:password@domain/foo.php
You can configure your webhook URL with basic HTTP authentication by adding the user name and password to the URL https://example.com/webhook in the following format and setting the result as the webhook URL:
https://<username>:<password>@example.com/webhook
トピック編集ページから、bot (任意) という ID でボットを作成し、Webhook URL を設定してください。Basic 認証もサポートしています。(例: http://user:password@example.com/)
sftp|ftp|ftps|ftpes|http|https|scp :// [ <username> [ : <password> ] [ ; <fingerprint> ] @ ] <host> [ : <port> ] /
[124] draft-ietf-secsh-scp-sftp-ssh-uri-04 - Uniform Resource Identifier (URI) Scheme for Secure File Transfer Protocol (SFTP) and Secure Shell (SSH) ( ()) https://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04
[126] Fixed parse_userinfo breaking with complex passwords by Thomspoon · Pull Request #293 · servo/rust-url () https://github.com/servo/rust-url/pull/293
[127] 504300 - Disallow requests with basic auth credentials in URL - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=504300
[128] 707761 - Name and Password in XMLHttpRequest.open no longer work - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=707761
[129] 708131 - Removal of username/password support in XHR breaks remote control functionality - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=708131
[130] XMLHttpRequest: align username/password test with the standard by annevk · Pull Request #10419 · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/pull/10419
[131] Restructure URL rendering section and add additional guidance (estark37著, ) https://github.com/whatwg/url/commit/8809598ddfd1d935432c8a0cad53f13d70e24bc6
[132] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--disallow-username-in-url
[133] GNU Wget 1.20 Manual () https://www.gnu.org/software/wget/manual/wget.html#index-URL-syntax
この例での ~/git.store は以下のようになっています。
https://bob:s3cre7@mygithost
中身は認証情報つきの URL がずらずらと続く形になっています。
[135] CVE-2024-38428 & CVE-2024-38428 Wget Vulnerability: All you need to know, zoer, , https://jfrog.com/blog/cve-2024-38428-wget-vuln-all-you-need-to-know/