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

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

---

이 질문은 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 페이지의 교차 사이트 스크립팅 버그,
• ...

---

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

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

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

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

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

참고 : 나는

• 기본 애플리케이션,

• 조작 된 브라우저,

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

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

---

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

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

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

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

참고 URL : https://stackoverflow.com/questions/24680302/csrf-protection-with-cors-origin-header-vs-csrf-token