https://learn.dreamhack.io/7#2 페이지에서
Introduction
이 강의는 Client-side(클라이언트 사이드) 취약점의 대표적인 공격 방법과 방어법을 다룹니다.
"Introduction of Webhacking" 강의에서 HTTP는 Connectionless와 Stateless한 특성을 가지고 있기 때문에 웹 서버가 사용자를 식별하기 위해 보편적으로 쿠키와 세션을 사용한다고 했습니다. 공격자는 사용자로부터 본인을 식별하기 위한 사용자 정보, 즉 쿠키나 세션에 저장된 세션 아이디를 탈취해 사용자 권한을 얻거나, 사용자의 브라우저에서 자바스크립트를 실행하는 등의 특별한 행위를 수행해 사용자가 요청을 보낸 것처럼 하는 것이 클라이언트 사이드 취약점의 주 목적입니다.
위와 같은 클라이언트 사이드 취약점이 발생할 수 있는 이유는 웹 브라우저는 Stateful한 상태를 유지하기 위해 모든 HTTP 요청에 쿠키를 함께 보냅니다. 아래는 웹 브라우저가 리소스를 요청할 때 보내는 HTTP 패킷입니다.
GET /resource1 HTTP/1.1
Host: dreamhack.io
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
Accept: image/webp,image/apng,image/,/;q=0.8
Referer: http://dreamhack.io/sandbox
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: cookie=choco_poco; user_id=admin
GET /resource1 HTTP/1.1
Host: dreamhack.io
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
Accept: image/webp,image/apng,image/,/;q=0.8
Referer: http://theori.io
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: cookie=choco_poco; user_id=admin
서로 다른 사이트인 dreamhack.io 와 theori.io에서 dreamhack.io/resource1 에 요청을 보내지만, 동일한 쿠키(cookie=choco_poco; user_id=admin)가 함께 전송되는 것을 확인할 수 있습니다.
이런 내용이 나오는데 밑에서 9번째 줄 Host가 dreamhack.io 가 아니라 theori.io 라고 되어야 하는거 아닌가요.?
Host 헤더가 dreamhack.io 으로 설정되고, Referer 헤더가 다른게 정상 리퀘스트입니다.
그 이유는, 아래와 같이 쉽게 설명드립니다.
- Host 헤더: 요청 받는 곳
- Referer 헤더: 요청 하는 곳
추가적으로, 아래는 RFC-2616 (Hypertext Transfer Protocol:HTTP/1.1)에 명시된 내용입니다.
Host Header
The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL,The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.
Referer Header
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.