CSRF 공격에 대한 응용 프로그램의 유일한 방어가 동일한 출처에 대해 참조 원 헤더를 확인한다고 가정합니다. 또한 모든 브라우저가 referer 헤더를 보낼 것이라고 가정합니다 (항상 그렇지는 않지만).CSRF 공격 중에 Referer Header를 스푸핑하는 것은 어떻게 불가능합니까?
사용자가 자신의 리퍼러 헤더를 스푸핑하는 것은 사소하지만 CSRF 공격자가 동일한 작업을 수행하려면 IMPOSSIBLE이라는 것을 알았습니다.
1.) 어떻게 당신은 referer 헤더를 스푸핑합니까? 참고로 리퍼러 헤더는 프로그래밍 방식으로 modified 일 수 없습니다.
2.) CSRF 공격자는 왜 그렇게 할 수 없습니까?
자신의 브라우저에서 리퍼러 헤더를 스푸핑하는 것은 프로그래밍 방식으로 수정할 수는 없지만 사소한 일입니다. 트릭은 브라우저가 서버로 전송 한 후 서버에 도달하기 전에 요청을 가로 챕니다.
Burp Suite과 같은 차단 프록시를 사용하면 쉽게 수행 할 수 있습니다. 기본적으로 브라우저에 로컬 인터셉트 프록시를 프록시 서버로 사용하도록 지시합니다. 그런 다음 브라우저가 로컬 프록시에 요청합니다. 로컬 프록시는 요청을 유지하고 참조 텍스트를 포함하여 HTTP 텍스트에서 원하는 내용을 변경할 수 있습니다. 준비가되면 요청을 릴리스하면 로컬 프록시가 요청을 보냅니다. 쉬워요.
웹 사이트에서 TLS를 사용하지 않으면 홉 (hop)이 악의적 일 수 있고 원하는 경우 요청/응답을 수정할 수 있다는 점에 유의해야합니다. 도중에 많은 홉에 대한 아이디어를 얻으려면 traceroute를 시도 할 수 있습니다 (일부 라우터는 traceroute 도구를 작동시키는 패킷을 드롭하기 때문에 신뢰할 수있는 측정 값은 아닙니다).
그러나 순수 CSRF 공격의 경우 공격자는 피해자의 브라우저를 제어하지 않습니다.. 이는 희생자의 브라우저가 웹 서버에 직접 요청을 보내고, 항상 리퍼러 헤더를 보낸다는 것을 의미합니다. 이는 일반적으로 추천 헤더가 매우 쉽게 위장되어 있기 때문에 피해자의 참조 헤더를 변경하는 것이 불가능한 이유입니다.
모두 그렇습니다. CSRF를 퇴치하기위한 최상의 솔루션은 CSRF 토큰을 사용하는 것입니다. OWASP recommends using the origin header and a CSRF token.
이 정보가 도움이되기를 바랍니다. 그렇지 않은 경우 의견에 대해 알려주세요. 명확히하려고 노력할 것입니다.
프록시를 통해 리퍼러 헤더를 수정하기 위해 정의한 두 번째 기술의 경우 사이트가 HTTPS에 올바르게 연결되면 작동하지 않습니다. – Vinay
사이트에서 HTTPS를 사용하는 경우에도이 작업을 수행 할 수 있습니다. Burp의 인증서는 기본적으로 브라우저에서 신뢰하지 않으므로 브라우저는 인증서 경고를 표시합니다. 어쨌든 여전히 작동 할 것입니다. Burp의 인증서를 신뢰할 수있는 인증서로 수동 설정하면 경고가 제거 될 수 있습니다 – niilzon