대부분의 CSRF 솔루션은 CSRF 토큰이 POST 데이터의 일부로 보내야한다고 주장하는 것 같습니다.CSRF 토큰을 본문 또는 헤더로 보낼 수있는 보안 위험이 있습니까?
내 상황에서 보내지는 데이터는 json이고 보내지는 것을 제어하지 않습니다 (그리고 나는 json으로 엉망이되고 싶지 않습니다). 그래서 CSRF 토큰을 헤더로 보내려합니다. 그러나 본문에 토큰을 보낼 수 있어야하는 기존 응용 프로그램 부분 (예 : html 양식 제출)이 있습니다.
그래서 유효한 CSRF 토큰이 본문 또는 헤더에있는 경우 내 CSRF 보호가 요청을 허용해야합니다. 이것은 토큰이 본문에 있다고 주장하는 것에 비해 보안 위험입니까?
CSRF에 대한 공격자는 사용자가 로그인을 믿는 서버에 의심하지 않는 사용자 포스트 데이터를하게된다.
보호 뒤에 아이디어를, 서버가 세션에 토큰을 연결하는 것이, 그리고 보냅니다 쿠키 및 페이로드 요구 사항에 따라 그런 다음 게시 할 때 페이로드에 토큰을 보내고 쿠키로 보냅니다. 따라서 공격자는 쿠키 또는 세션에 어떤 토큰이 있는지 추측 할 수 없습니다. 서버가 두 개의 서로 다른 토큰이 포함 된 게시물을 받으면 거부됩니다.
페이로드 토큰을 헤더에 넣는 것이 좋을 것입니다. "쿠키"또는 "기억 된"다른 헤더가 브라우저에서 자동으로 보내지는 한 오래 걸릴 수 있습니다.
헤더에 CSRF 토큰을 보내는 경우 보안 위험이 없습니다. 클라이언트가 페이지를 요청할 때마다이 헤더의 값이 변경되도록하십시오. 즉, 임의의 숫자 여야합니다. 또한 클라이언트 측의 웹 응용 프로그램은이 헤더를 서버로 다시 보내야 서버가 클라이언트로 보낸 헤더 값을 클라이언트의 응답에서받은 동일한 헤더 값과 일치시킬 수 있습니다.
[security.se]이 질문에 더 나은 선택 일 수 있습니다. – CodesInChaos