브라우저에서 CSRF를 허용하는 이유는 무엇입니까?

Question

저는 웹 보안에 대해 처음 접했고, 다른 공격 경로에 대해 더 많이 읽었을 때, 제 마음은 처음부터 허락한다는 것을 깨닫습니다. 마치 웹이 깨진 보안 모델로 설계되어 취약한 것처럼 보입니다.

모호하고 부정확 한 정보에 놀랐습니다. 예를 들어, 처음에는 Single Origin Policy가 꽤 좋아 보인다. 그런 다음 XHR에만 적용된다는 것을 알았지 만, 실제로 CSR은 고전적인 CSRF 공격 인 XHR 교차 출처 POST를 실제로 방지하지 못합니다. 다행히 계속 읽고 있습니다.

서버가 요청이 올바른 위치에서 오는 지 확인하는 데 사용할 수있는 Origin 헤더가 있지만 브라우저간에 불일치하게 설정되며 설정되지 않은 경우에는 사용할 수 없습니다 같은 출처 요청 또는 특정 브라우저 (어쩌면 IMG 태그)에서 가져 오지 못했던 요청 유형 때문인지 확실히 확신 할 수 있습니다. 계속 읽으세요.

오른쪽 웨이는 세션 쿠키에 CSRF 토큰을 설정하고 해당 토큰을 양식/링크에 추가 한 다음 제출시 서버 측과 비교합니다. 이론적으로 (이 질문의 목적을 위해 모든 XSS 공격을 제외시킵니다.) 다른 탭의 CSRF 시도는 쿠키를 포함하는 양식으로 POST 요청을 할 수 있지만 양식 입력 요소가 일치하는 토큰으로 설정되지 않았습니다 (왜냐하면 쿠키에서 토큰을 읽을 수 없으므로) 서버가 요청을 거부합니다. 작동하지만 kludgy, 확인 절대 잊지 절대!

잠시 생각해 보니 여기 내 질문 - 브라우저가 쿠키의 원본이 아닌 페이지에서 발생한 요청으로 세션 쿠키를 보내는 이유는 무엇입니까? 내 말은

, 브라우저는 좋은 이유 쿠키를 에 다른 도메인을 전송을 거부하지만, 서로 다른 기원에서 그들에게 을 보내 매우 행복 할 것인가? 그들이하지 않으면 물건이 깨지겠습니까? 그것은 CSRF에 대한 견고한 방어가 될 것인데, 서버가 어쨌든 무엇을하고 있는지를 요구하고 유효한 세션 쿠키를 확인해야합니까?

편집 : 상황을 개선하기위한 시도 일 수 있습니까? https://tools.ietf.org/html/draft-west-origin-cookies-01

Answer 1

나는 웹 보안에 아주 새로운 오전, 나는 더 다른 공격 경로에 대해 읽을 때, 내 마음은 그들이 처음에 허용되는 주춤 거린다. 마치 웹이 깨진 보안 모델로 설계되어 취약한 것처럼 보입니다.

모두 true입니다. 처음부터 안전하도록 설계된 적이 없었습니다. 웹은 원래 정적 문서 관리 및 공유 시스템으로 설계되어 다른 시스템의 자원에 직접 링크를 허용합니다.

오늘 보는 동적 웹 은 kurdge입니다. CSRF 토큰, HTTP 헤더 등으로 해결할 수 있지만 이러한 작업을 수행하지 않고도 동적 웹 사이트를 만들면 위험에 처할 가능성이 있으며 (나 같은 사람을 직장에서 유지할 수 있습니다).

체크 아웃 its history in the Wikipedia article을 확인하십시오.

모호하고 부정확 한 정보에 놀랐습니다. 예제의 경우 처음에는 단일 출처 정책이 상당히 좋게 들린다. 그런 다음 은 XHR에만 적용되며, 그런데도 은 XHR 교차 출처 POST (클래식 CSRF)를 실제로 방지하지 않습니다. 공격. 다행히 계속 읽고 있습니다.

또한 주로 사실입니다. 동일 원산지 정책은 창과 프레임에도 적용됩니다 (예 : example.com에서 iframe에 iframe을 포함하는 경우 example.com은 example.org의 콘텐츠를 자바 스크립트로 변경할 수 없음). 예, 도메인 간 XHR을 만들 수 있지만 CORS을 사용하지 않으면 응답을 읽을 수 없습니다. 이것은 CSRF 토큰이 도난당하는 것을 막아 주지만 CSRF 보호를 사용하지 않는다면 CSRF 취약성을 나타냅니다.

사용자 지정 헤더가 도메인 간 전송 될 수 없기 때문에 adding a custom header과 같은 다른 방어 수단을 사용하여 CSRF를 완화 할 수 있습니다.

XHR은 너무 큰 제한으로 여겨지는 크로스 도메인에 액세스 할 수 없었기 때문에 CORS의 출현이있었습니다. 이전에는 양식이 어쨌든 다른 도메인에 액세스 할 수 있으므로 특히 위험한 조작으로 간주되지 않았습니다. 적절한 통제가 제 공되는 한 그것은 여전히 ​​아닙니다.

이 서버는 요청이 적절한 장소에서오고 있는지 를 만들기 위해 사용할 수있는 원산지 헤더도 -하지만 죄송합니다, 그것은 브라우저에서 일관성 을 설정하고, 설정되지 않은 경우, 같은 출처 요청 때문이거나 특정 브라우저 (어쩌면 IMG 태그 일까?)를 얻지 못했던 유형의 요청 때문일 수 있습니다. 독서를 계속하십시오.

매우 사실입니다. this answer을 참조하십시오.

은 쿠키의 원본이 아닌 페이지에서 브라우저가 보낸 요청으로 세션 쿠키를 보내는 이유는 무엇입니까?

많은 것들이 다르기 때문에. 정적 사이트에서 백 엔드 처리를 수행하는 동적 사이트로 제출되도록 설계된 셀 수없는 양식이 있습니다.

새로운 standard for "same-site" cookies가 있습니다. 덜 건조한 설명은 here입니다.

기본적으로 쿠키는 새로운 속성 SameSite으로 설정할 수 있습니다. strict 모드에서는 원본이 다른 경우 쿠키가 보내지지 않습니다. lax 모드에서, 방법이 예인 경우에만 보류됩니다. POST는 CSRF 취약점이 주로있는 곳입니다.

내가 링크 한 것은 초기 초안입니다.