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

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

---

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

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

---

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

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

---

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응답을 올바르게 거부 한다는 오류를 볼 수 있습니다 . 서버가 이미 스푸핑 된 요청을 수락하고 내 돈을 보냈기 때문에이 시점에서 중요하지 않습니다 .

---

겸손한 마무리 :

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 요청이라는 것을 인식하지만 서버가 리소스 (여기서는 균형 쿼리 끝점)를 웹 사이트와 공유하고 있음을 보여주지 않습니다. 따라서 흐름을 차단하므로 반환 결과가 악성 코드에 도달하지 않습니다.

참고 URL : https://stackoverflow.com/questions/21058183/whats-to-stop-malicious-code-from-spoofing-the-origin-header-to-exploit-cors