CORS를 악용하기 위해 악성 코드가 "Origin"헤더를 스푸핑하는 것을 막는 것은 무엇입니까?

142

foo.com의 페이지에서 실행되는 클라이언트 쪽 스크립트가 bar.com에서 데이터를 요청하려면 요청에서 헤더를 지정 Origin: http://foo.com해야하고 bar는로 응답해야합니다 Access-Control-Allow-Origin: http://foo.com.

사이트 roh.com의 악성 코드가 단순히 헤더 Origin: http://foo.com를 스푸핑하여 막대에서 페이지를 요청하지 못하게하려면 어떻게해야합니까?

— 제이 라 몬트
소스

요점은 페이지가 제공되는 원래 도메인 (여기서는 foo.com)이 Access-Control-Allow-Origin헤더 를 제공해야 하거나 브라우저가 요청을 허용하지 않는다는 것 bar.com입니다.

— Chris Hayes

이 게시물을 읽으면 브라우저, 원본 서버 및 대상 서버 간의 cors 프로세스를 이해하는 데 실제로 도움 이되었습니다 . html5rocks.com/en/tutorials/cors

— brendonparker

@ChrisHayes CORS가 전혀 작동하지 않습니다. 스펙 이나 주제에 관한이 훌륭한 MDN 위키 페이지를 보면 이것에 대해 좀 더 읽을 수 있습니다 .

— 레이 니콜러스

@brendonparker 그렇습니다. 훌륭한 기사입니다. 이 저자는 SO에 대한 많은 CORS 질문에 답변하고 enable-cors.org 도 유지 합니다 .

— 레이 니콜러스

@RayNicholus 흥미롭게도, 나는 분명히 벗어났다. 링크 주셔서 감사합니다. 내 의견에 대한 투표로 판단하면 나는이 망상에서 고통받는 유일한 사람이 아닙니다. 나는 그 두 사람이 돌아와서 배우기를 바랍니다 (그리고 투표를 제거하십시오!).

— Chris Hayes

답변:

149

브라우저는 Origin헤더 설정을 제어 하며 사용자는이 값을 무시할 수 없습니다. 따라서 Origin브라우저에서 헤더가 스푸핑 되지 않습니다 . 악의적 인 사용자가 수동으로 Origin헤더를 설정하는 curl 요청을 만들 수 있지만이 요청은 브라우저 외부에서 발생하며 브라우저 관련 정보 (예 : 쿠키)가 없을 수 있습니다.

CORS는 보안이 아닙니다. 사이트를 보호하기 위해 CORS에 의존하지 마십시오. 보호 된 데이터를 제공하는 경우 쿠키 또는 OAuth 토큰 또는 Origin헤더 이외의 다른 것을 사용하여 해당 데이터를 보호하십시오. Access-Control-Allow-OriginCORS 의 헤더는 교차 출처 요청을 허용 할 오리진 만 지정합니다. 더 이상 그것에 의존하지 마십시오.

— 몬 수르
소스

이것은 많은 의미가 있습니다. 브라우저에서 JavaScript가 Origin 헤더를 재정의하도록 허용하지 않으면 아무런 문제가 없습니다. 브라우저 외부에서 요청을 실행하는 경우 쿠키가 없습니다. 내가 읽고있는 모든 문서에서 Origin 헤더를 재정의 할 수 없다고 명시 적으로 말한 곳이 없기 때문에 혼란 스러웠습니다 . 감사!

— Jay Lamont

누군가가 스푸핑을 원한다면 그렇게 할 수 있습니다. 거의 모든 스크립팅 언어를 사용하여 http 요청을 구성 할 수 있습니다. Perl과 Python에는 http 라이브러리가있어이를 쉽게 만들 수 있습니다. 라이브러리는 쿠키를 저장 및 전송하고 임의의 헤더를 추가하며 많은 디버깅 정보를 제공합니다. 따라서 CORS 헤더는 브라우저에서 모두 로그인했을 때 다른 도메인의 은행 계좌에 불쾌한 행동을하는 포럼의 악성 자바 스크립트를 어렵게 만드는 것입니다.

— Mnebuerquo

분명히 말하면 악의적 인 사용자는 패치 된 브라우저 인스턴스를 생성하여 Origin 헤더를 수동으로 제어 한 다음 일반 사용자, 쿠키, AJAX 등을 완벽하게 가장 할 수 있습니다.

— Jordan Rieger

"브라우저는 Origin 헤더를 제어 할 수 있으며 사용자는이 값을 무시할 수 없습니다." 요청이 브라우저를 떠나면 Fiddler2 또는 Charles와 같은 도구를 사용하여 헤더를 수정하는 것이 매우 쉽다고 확신합니다.

— Asa

악의적 인 사용자는 단순히 패치 된 브라우저 인스턴스를 스폰하여 Origin 헤더를 수동으로 제어 할 수 있습니다. 나에게), 왜 디스크에서 쿠키를 직접 읽지 않습니까? 그것들은 당신이 알고있는 평문에 저장됩니다. 실제 사이트 간 스크립팅은 실제 위협 인 반면, 공격 시나리오는 단지 고 안되고 비현실적입니다.

— Stijn de Witt

TLDR : 악성 코드가 원본을 스푸핑하는 것을 막을 수있는 것은 없습니다. 이 경우 서버는 서버에 대해 알지 못하고 요청에 따라 작동합니다. 때로는 그러한 요청이 비쌉니다. 따라서 보안 유형 대신 CORS를 사용하지 마십시오.

나는 최근 CORS와 함께 놀고 있었고, 나에게 같은 질문을했다. 내가 찾은 것은 브라우저가 스푸핑 된 CORS 요청을 볼 때 충분히 똑똑 할 수 있지만 서버가 똑똑하지 않다는 것입니다.

내가 찾은 첫 번째 것은 Origin헤더가 프로그래밍 방식으로 수정할 수없는 HTTP 금지 헤더 이름이라는 것 입니다. Chrome 용 헤더 수정을 사용하여 약 8 초 안에 수정할 수 있습니다 .

이를 테스트하기 위해 두 개의 클라이언트 도메인과 하나의 서버 도메인을 설정했습니다. 클라이언트 1의 CORS 요청은 허용했지만 클라이언트 2의 CORS 요청은 허용하지 않는 CORS 화이트리스트를 서버에 포함 시켰습니다. 두 클라이언트를 모두 테스트했으며 실제로 클라이언트 2의 CORS 요청은 성공했지만 클라이언트 2는 실패했습니다.

그런 다음 Origin클라이언트 1과 일치하도록 클라이언트 2의 헤더를 스푸핑했습니다 . 서버가 스푸핑 된 Origin헤더를 수신하고 화이트리스트 확인을 통과했습니다 (또는 절반 정도의 빈 사람인 경우 실패). 그 후 서버는 소비하도록 설계된 모든 리소스 (데이터베이스 호출, 고가의 전자 메일 보내기, 훨씬 비싼 SMS 메시지 보내기 등)를 소비하여 충실하게 수행했습니다. 이 작업이 완료되면 서버는 행복하게 스푸핑 된 Access-Control-Allow-Origin헤더를 브라우저로 다시 보냈습니다 .

내가 읽은 문서에는 Access-Control-Allow-Origin수신 된 Origin값이 요청에서 보낸 값 과 정확히 일치해야 한다고 명시되어 있습니다. 그들은 일치했기 때문에 Chrome에서 다음 메시지를 보았을 때 놀랐습니다.

XMLHttpRequest를로드 할 수 없습니다 http://server.dev/test. 'Access-Control-Allow-Origin'헤더의 값 http://client1.dev 은 제공된 원점과 같지 않습니다. http://client2.dev 따라서 원점 에 액세스 할 수 없습니다.

내가 읽은 문서가 정확하지 않은 것 같습니다. Chrome의 네트워크 탭에는 요청 및 응답 헤더가 모두로 명확하게 표시 http://client1.dev되지만 Chrome은 실제 출처를 알고 http://client2.dev응답을 올바르게 거부 한다는 오류를 볼 수 있습니다 . 서버가 이미 스푸핑 된 요청을 수락하고 내 돈을 보냈기 때문에이 시점에서 중요하지 않습니다 .

— 녹턴
소스

@Nocturno, 예를 주셔서 감사합니다. 관찰 내용을 추가하겠습니다. CORS는 브라우저 안전 기능과 관련이 있습니다. 안전한 브라우저가 원래 상태에서 수정되면 브라우저에 안전 기능이없는 것으로 해석 될 수 있습니다.

— Luka Žitnik

전혀 화려하지 않습니다. CORS의 요점을 완전히 놓친 것입니다. 사용자 컴퓨터에서 발생하는 요청을 가로 챌 수있는 위치에 있다면 쿠키를 읽고 키로거, 바이러스 및 기타 모든 실제 위협을 설치할 수 있습니다. CORS는 사이트 B에 주입 된 악의적 인 스크립트로부터 사이트 A에 로그인 한 정직한 사용자를 보호하기 위해 존재합니다. 사이트 B의 스크립트 (사이트 B가 올바르게 이스케이프하지 않은 포럼 게시물의 Javascript 스니 펫일 수 있음)가 수행합니다. 사이트 A의 세션 쿠키를 사용하여 사이트 A에서 사용자 계정으로 작업 (예 : 항목 삭제 등)

— Stijn de Witt

이를 사이트 간 스크립팅이라고하며 CORS를 사용하지 않으면 사용자 시스템을 제어 할 필요가 없습니다. 그게 요점입니다. 사이트 A에 요청을 할 때 브라우저가 요청에 세션 쿠키를 자동으로 추가하는 데 사용되는 브라우저가 실제로 다른 스크립트의 스크립트에서 왔을 때 사용자 자신의 유효한 요청처럼 보였기 때문에 사용자 컴퓨터를 제어 할 필요가 없었습니다. 대지. 동일 출처 정책으로이를 방지하고 CORS는 도메인이 다른 경우에도 액세스 권한이 부여되어야하는 도메인을 허용 목록에 사용합니다.

— Stijn de Witt

@Nocturno 그래, 난 너무 조잡했다, 미안. 당신의 원래 요점이 서 있습니다. 동일 출처 정책은 브라우저 보안 기능이며 CORS는 일부 도메인을 허용 목록에 추가하여 해당 보안을 약화시키는 메커니즘입니다. OP는 Origin 헤더를 스푸핑하는 것이 실제로 컬과 같이 할 수 없었던 것을 가져 오지 않기 때문에 실제로는 '공격'으로서 실행 가능하지 않다는 것을 이해해야합니다.

— Stijn de Witt

@Nocturno 나는 당신의 시작 진술이 약간 오도라고 생각합니다. There's nothing stopping malicious code from spoofing the origin-> 예, 자바 스크립트를 설정할 수 없습니다 Origin. 예, 사용자는 브라우저를 사용하여 피들러를 사용하여 출처를 변경할 수 있지만 CORS가 방어하는 것은 아닙니다. 공격자 제어 웹 사이트 는 Origin을 변경할 수 없습니다.

— RJFalconer

겸손한 마무리 :

Q : 브라우저에서만 SOP (Same Origin Policy)를 시행합니까?
A : 그렇습니다. 브라우저 내에서하는 모든 호출에 대해 브라우저에서 SOP를 확실히 적용합니다. 서버가 요청의 출처를 확인하거나 확인하지 않을 수 있습니다.

Q : 요청이 SOP를 준수하지 않으면 브라우저가 요청을 차단합니까?
A : 아니요. 브라우저 권한을 벗어났습니다. 브라우저는 단지 크로스 오리진 요청을 보내고 응답이 서버에서 Access-Control-* 헤더를 통해 합법적으로 신호를 받는지 확인하기를 기다립니다 . 서버가 Access-Control-Allow-Origin헤더를 다시 보내지 않거나 발신자의 발신지를 에코하지 않거나 헤더에서 다시 보내지 않으면 *브라우저가 할 일은 발신자에게 응답을 제공하지 않는 것입니다.

Q : 스푸핑을 할 수 없다는 의미 Origin입니까?
A : 브라우저 및 스크립팅을 사용 Origin하는 경우 브라우저를 제어하므로 무시할 수 없습니다 . 그러나 자신을 해킹하려는 경우 브라우저 확장 프로그램이나 컴퓨터에 설치 한 다른 도구를 사용하여 브라우저에서 나오는 통화를 변조 할 수 있습니다. 또한 발행 할 수 있습니다 HTTP사용하여 전화를 curl, Python, C#, 등 및 변경 Origin트릭 서버에 헤더.

Q : 를 변경하여 서버를 속일 수 있다면 안전하지 않다는 Origin의미 CORS입니까?
A : CORS 그 자체로는 보안, 즉 요청의 인증 및 권한 부여에 대해서는 침묵합니다. 쿠키 및 헤더와 같이 작동하는 모든 메커니즘으로 요청을 검사하고 인증 / 권한을 부여하는 것은 서버에 달려 있습니다. XSS와 같은 공격의 경우 우리를 조금 더 보호 할 수 있습니다.

예 : 웹 사이트에 로그인했으며 악의적 인 스크립트가 은행 웹 사이트에 잔액을 요청하는 요청을 보내려고한다고 가정합니다 ( 반사 된 XSS 공격). 귀하의 은행 웹 사이트는 귀하의 웹 사이트에서 오는 자격 증명을 신뢰하므로 요청이 인증되고 HTTP악성 코드를 목표로 하는 응답이 발행됩니다. 은행 웹 사이트가 다른 출발점과 엔드 포인트를 공유하는 것을 신경 쓰지 않으면 포함하지 않습니다.Access-Control-Allow-Origin응답의 헤더. 이제 요청이 도착하면 브라우저는 요청이 Cross Origins 요청이라는 것을 인식하지만 서버가 리소스 (여기서는 균형 쿼리 끝점)를 웹 사이트와 공유하고 있다는 것을 응답하지 않습니다. 따라서 흐름을 차단하므로 반환 된 결과는 악성 코드에 도달하지 않습니다.

— 알리레자
소스

허용 된 답변 IMO

— 3dGrabber