도메인 앞의 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]하면 Google 홈페이지로 이동합니다.
이것은 정말 흥미 롭습니다. @도메인 이전의 URL에서 정보를 찾을 수 없습니다 . 어떻게 부르나요? 이것은 인터넷의 초기 단계에서 쓸모없는 것입니까? URL의이 부분을 처리 할 수있는 웹 서버가 있습니까 (이 매개 변수를 기반으로 다른 사이트를 반환하도록 내 nginx 인스턴스를 수정할 수 있다는 것은 멋질 것입니다)?
답변
이 구문은 '권한'에 연결하기위한 프로토콜 레벨 인증 세부 사항 (사용자 이름, 경우에 따라 비밀번호)을 지정하는 데 사용됩니다. 예를 들어 RFC 3986 섹션 3.2.1을 참조하십시오 .
HTTP와 함께 사용되는 경우 자격 증명은 HTTP Authorization : 헤더 로 전송 됩니다 . 형식은 서버에서 요청한 인증 메커니즘에 따라 다르지만 가장 일반적으로 Basic인증은 추가 처리없이 사용됩니다. RFC 7617 또는 MDN을 참조하십시오 .
많은 웹 서버가 'htpasswd'파일, LDAP, SQL 또는 기타 데이터베이스에 대한 자격 증명을 확인할 수 있습니다. 예를 들어 Nginx의 경우 auth_basic 또는 Apache httpd AuthType Basic을 참조하십시오 .
또는 표준 HTTP 헤더 및 상태 코드를 통해 수행되기 때문에 웹앱 자체에서 검증을 수행 할 수 있습니다. 예를 들어 PHP를 참조하십시오 (하지만 Apache에서이 작업을 수행 CGIPassAuth하려면 이상한 재 작성 트릭 을 활성화 하거나 사용해야 할 수 있습니다 . 그렇지 않으면 Authorization 헤더를 앱 런타임에 전달하지 않습니다.)
기본 제공 HTTP 인증은 일반적으로 API 및 기타 자동화 된 요청에 사용됩니다. 사용자 상호 작용이 필요하지 않고 쿠키 또는 기타 상태를 저장할 필요가 없으며 "로그인"POST 요청을 형식화하는 방법을 알 필요가 없기 때문입니다. <양식> 기반 인증이 필요합니다).
이는 다음 프롬프트에서 사용하는 것과 정확히 동일한 인증 방법입니다.
URL을 사용하고 인증을 지원하는 FTP 및 기타 여러 프로토콜에도 동일한 구문이 적용됩니다. 모든 경우에 해당 프로토콜의 기본 제공 메커니즘이 사용됩니다.
여기서 공격은 HTTP 인증이 선택 사항이며 대부분의 경우 추가 HTTP 헤더가 웹 서버와 웹 응용 프로그램에서 무시되기 때문에 작동합니다. 그리고 그 반대는 반대, 브라우저는 서버가 될 때까지 인증을 요구할지 모른다 후 요청이 전송됩니다.
그러나, 공격은 새로운 것이 아니다 전혀 - 그것은 적어도 2000 년대 초반에서부터 주변에있었습니다. (사실 어떤 시점에서 브라우저는 서버가 401로 응답할지 여부를 확인하기 위해 먼저 인증 없이 요청 을 함으로써 확인을 시작했습니다 . 서버가 인증을 요청하지 않으면 Chrome은 주소 표시 줄에서 사용자 이름을 숨기고 실제 도메인은 더 분명하며 Firefox는 실제로 "이는 사용자를 속이려는 시도 일 수 있습니다."라고 경고합니다.)