ドメインの前のURLの@（アットマーク）の目的は何ですか？
最近@、シンボルを使用してURLを正当に見せかける新しいフィッシング攻撃に遭遇しました。こんなふうになります：
私はにアカウントを持ってtotally-legit-site.comおり、攻撃者はのように自分のIPにフィッシングサイトを設定します192.168.50.20。次に、彼はサイトで、のようなリンクを含むメッセージを送信しますhttp://[email protected]/account。これは、これが合法的なサイトへのリンクであるとユーザーに思わせるために使用されます。
ただし、このリンクをクリックすると192.168.50.20/account、ブラウザ（Google Chrome）でページが開きます。@ランダムドメインの前にランダムなものを追加しようとしましたが、ブラウザは常にページを正しく解決し、そのようなものを破棄し@ます。ですから、開こうとするhttp://[email protected]とグーグルのホームページにたどり着きます。
これは本当に興味があります。@ドメインの前のURLで情報を見つけることができませんでした。これはどのように呼ばれますか？これはインターネットの初期段階からのいくつかの時代遅れのものですか？URLのこの部分を処理できるWebサーバーはありますか（このパラメーターに基づいて異なるサイトを返すようにnginxインスタンスを変更できると便利です）？
回答
この構文は、「権限」に接続するためのプロトコルレベルの認証の詳細（ユーザー名、場合によってはパスワード）を指定するために使用されます。たとえば、RFC3986セクション3.2.1を参照してください。
HTTPで使用する場合、資格情報はHTTP Authorization：ヘッダーで送信されます。形式はサーバーによって要求された認証メカニズムによって異なりますが、最も一般的にはBasic認証は追加の処理なしで使用されます。RFC7617またはMDNを参照してください。
多くのWebサーバーは、「htpasswd」ファイル、LDAP、SQL、またはその他のデータベースに対して資格情報を検証できます。たとえば、Nginxについては、auth_basicまたはApache httpd AuthTypeBasicを参照してください。
または、標準のHTTPヘッダーとステータスコードを介して検証が行われるため、Webアプリ自体で検証を行うこともできます。たとえばPHPを参照してください（ただし、Apacheでこれを機能させるにCGIPassAuthは、奇妙な書き換えトリックを有効にするか使用する必要がある場合があります。そうしないと、Authorizationヘッダーがアプリランタイムに転送されません。）
組み込みのHTTP認証は、ユーザーの操作を必要とせず、Cookieやその他の状態を保存する必要がなく、「ログイン」POSTリクエストのフォーマット方法を知る必要がないため、APIやその他の自動リクエストに一般的に使用されます。 <form>ベースの認証が必要です）。
これも、これらのプロンプトで使用されるのとまったく同じ認証方法です。
同じ構文は、URLを使用し、認証をサポートするFTPおよび他の多くのプロトコルにも適用されます。すべての場合において、そのプロトコルの組み込みメカニズムが使用されます。
ここでの攻撃は、HTTP認証がオプションであり、ほとんどの場合、余分なHTTPヘッダーがWebサーバーとWebアプリケーションによって単に無視されるために機能します。そしてその逆、ブラウザは、サーバが認証されるまでを求めるかどうかはわかりません後に送信される要求。
ただし、この攻撃はまったく新しいものではありません。少なくとも2000年代初頭から存在しています。（実際、ある時点でブラウザは、サーバーが401で応答するかどうかを確認するために、最初に認証なしでリクエストを行うことでチェックを開始しました。サーバーが認証をリクエストしない場合、Chromeはアドレスバーからユーザー名を非表示にして作成します実際のドメインはより明白であり、Firefoxは実際に「これはあなたをだまそうとする試みかもしれない」と警告します。）