CORS Origin 헤더와 CSRF 토큰을 사용한 CSRF 보호

103

이 질문은 Cross Site Request Forgery 공격으로부터 만 보호하는 것에 관한 것입니다.

구체적으로 다음과 같습니다. Origin 헤더 (CORS)를 통한 보호가 CSRF 토큰을 통한 보호만큼 좋은가요?

예:

Alice는 브라우저에서 " https://example.com "에 로그인 (쿠키 사용) 합니다. 나는 그녀가 최신 브라우저를 사용한다고 가정합니다.
Alice는 " https://evil.com "을 방문 하고 evil.com의 클라이언트 측 코드는 " https://example.com "에 대한 일종의 요청을 수행합니다 (고전적인 CSRF 시나리오).

그래서:

Origin 헤더 (서버 측)를 확인하지 않고 CSRF 토큰이없는 경우 CSRF 보안 허점이있는 것입니다.
CSRF 토큰을 확인하면 안전합니다 (하지만 약간 지루합니다).
Origin 헤더를 확인하는 경우, evil.com의 코드가 Origin 헤더를 설정할 수있는 경우를 제외하고는, CSRF 토큰을 사용할 때와 마찬가지로 evil.com의 클라이언트 측 코드의 요청도 차단되어야합니다.

나는 이것이 XHR (예 : 교차 출처 리소스 공유를위한 보안 참조)에서는 가능하지 않아야한다는 것을 알고 있습니다 . 적어도 우리가 W3C 사양이 모든 최신 브라우저에서 올바르게 구현 될 것이라고 믿는다면 (그럴 수 있습니까?)

그러나 다른 종류의 요청 (예 : 양식 제출)은 어떻습니까? 스크립트 / img / ... 태그를로드 하시겠습니까? 아니면 페이지가 (합법적으로) 요청을 만드는 데 사용할 수있는 다른 방법이 있습니까? 아니면 알려진 JS 해킹?

참고 : 나는

기본 애플리케이션,
조작 된 브라우저,
example.com 페이지의 교차 사이트 스크립팅 버그,
...

— 크리스 러처
소스

많은 프록시가 원본 헤더를 제거한다고 생각합니다.

— thefourtheye

그리고 양식 제출 및 img / script 태그의 경우 이전 브라우저에 대해서는 확실하지 않지만 CSP에 의존해야합니다.

— thefourtheye

@thefourtheye : TLS를 통해 연결이 시작되기 때문에 프록시가 중간자 수있는 경우 사용자는 CSRF보다 훨씬 더 시급한 문제가 있습니다.

— Perseids

@thefourtheye, 그들은 왜 스트립을 Origin할까요? 이는 CORS 보호를 무효화합니다.

— 폴 드레이퍼

나는이 질문과 그 대답이 특정한 것에 관한 것이기 때문에 좋아하지만 CSRF와 CORS의 차이점을 상기시켜줍니다. (나는 그이 인정 쉽게 혼동하지 개념 ...하지만 난 여전히 그들을 혼란스럽게 관리 할 수 있습니다.)

— 붉은 완두콩

답변:

적어도 모든 최신 브라우저에서 W3C 사양이 올바르게 구현된다고 믿는다면 XHR (예 : 교차 출처 리소스 공유를위한 보안 참조)에서는 이것이 가능하지 않아야합니다 (그럴 수 있습니까?).

하루가 끝나면 클라이언트 브라우저를 "신뢰"하여 사용자 데이터를 안전하게 저장하고 세션의 클라이언트 측을 보호해야합니다. 클라이언트 브라우저를 신뢰하지 않는 경우 정적 콘텐츠 이외의 다른 용도로 웹 사용을 중단해야합니다. CSRF 토큰을 사용하더라도 동일한 출처 정책 을 올바르게 준수하기 위해 클라이언트 브라우저를 신뢰하고 있습니다.

공격자가 동일한 출처 정책을 우회하고 공격을 실행할 수 있는 IE 5.5 / 6.0 과 같은 이전의 브라우저 취약성이 있었지만 일반적으로 이러한 취약성 은 발견되는 즉시 패치되고 대부분의 브라우저가 자동으로 업데이트됩니다. ,이 위험은 대부분 완화됩니다.

그러나 다른 종류의 요청 (예 : 양식 제출)은 어떻습니까? 스크립트 / img / ... 태그를로드 하시겠습니까? 아니면 페이지가 (합법적으로) 요청을 만드는 데 사용할 수있는 다른 방법이 있습니까? 아니면 알려진 JS 해킹?

Origin헤더는 일반적으로 만 XHR 크로스 도메인 요청을 전송됩니다. 이미지 요청에는 헤더가 없습니다.

참고 : 나는

기본 애플리케이션,

조작 된 브라우저,

example.com 페이지의 교차 사이트 스크립팅 버그,

이것이 조작 된 브라우저에 해당하는지 여부는 확실하지 않지만 이전 버전의 Flash 에서는 공격자가 referer공격을 실행하기 위해 피해자의 컴퓨터에서 스푸핑 된 헤더가 있는 요청을 보낼 수 있도록 임의의 헤더를 설정할 수있었습니다 .

— SilverlightFox
소스

Flash 예제는 좋은 예입니다. 다른 플러그인에도 비슷한 취약점이있을 수 있습니다. 나는 (불행히도) Alice가 최신 브라우저 등을 사용하는 경우 CSRF로부터 만 Alice를 보호 할 수 있습니다. 그러나 보안을 잘 알고있는 사용자라도 타사 플러그인을 설치했을 수 있다는 것은 비합리적인 일이 아닙니다. 특히 대규모 (신뢰할 수있는) 회사의 경우 더욱 그렇습니다. 안전한 플러그인을 작성할 수 있지만 CSRF에 대해서도 생각한다면 100 % 확신하지는 않습니다! 따라서 브라우저 샌드 박스가 플러그인이 SOP를 위반하는 것을 제한하지 않는 한 (아마도?) CSRF 토큰을 고수하는 것이 좋습니다.

— Chris Lercher 2014

@ChrisLercher : 예, 현대의 플러그인은 좀 더 강력 해 보입니다. 그러나 공격자가 브라우저 보호를 우회하는 방식으로이를 활용할 수있는 새 버전이 언제든지 출시 될 수 있습니다. 이를 처리하는 가장 좋은 방법 (예 : 토큰 / 헤더)은 데이터의 민감도와 그러한 위험이 허용되는지 여부에 따라 달라집니다. Flash는 SOP를 따르지만 Flash 플러그인의 출처는 JavaScript와 같은 호출 사이트가 아니라로드 된 사이트입니다. crossdomain.xml도메인 간 통신을 가능하게 하는 것이 있습니다.

— SilverlightFox

웹 콘텐츠는 Origin 헤더를 조작 할 수 없습니다. 또한 동일한 오리진 정책에 따라 한 오리진은 사용자 지정 헤더를 다른 오리진으로 보낼 수도 없습니다. [1]

따라서 Origin 헤더를 확인하는 것은 CSRF 토큰을 사용하는 것만 큼 공격 을 차단 하는 데 효과적 입니다.

이것에 의존하는 주된 관심사는 모든 합법적 인 요청이 작동하도록 허용하는지 여부입니다. 질문자는이 문제에 대해 알고 있으며 주요 사례를 배제하기 위해 질문을 설정했습니다 (오래된 브라우저 없음, HTTPS 만 해당).

브라우저 공급 업체는 이러한 규칙을 따르지만 플러그인은 어떻습니까? 그렇지 않을 수도 있지만 질문은 "조작 된 브라우저"를 무시합니다. 공격자가 Origin 헤더를 위조 할 수있는 브라우저의 버그는 어떻습니까? CSRF 토큰이 출처를 가로 질러 누출되도록하는 버그가있을 수 있으므로 하나가 다른 것보다 낫다고 주장하는 데 더 많은 작업이 필요합니다.

— 손님
소스

방금 Firefox 47을 테스트했으며 교차 출처 양식 게시물 (XHR에 대한 CORS를 활성화하지 않는 REST 서비스를 공격하는 일반적인 방법)에 대한 출처 헤더를 보내지 않으므로 출처 헤더 확인을 생각하지 않습니다. 사용자가 Firefox를 사용하는 경우 효과적입니다.

— Andy

참고로 Firefox에서 "Origin"헤더를 보내지 않는 문제는 Bugzilla에서 추적됩니다. bugzilla.mozilla.org/show_bug.cgi?id=446344 이 경우 "Referer"헤더를 확인하는 것으로 대체 할 수 있지만 제 경험상 일부 Firefox 사용자는 개인 정보 보호 문제로 인해 "Referer"헤더를 차단합니다 (IMHO는 경로와 쿼리를 제거하는 것으로 충분합니다).

— Steffen