9
기본적으로 레일스는 멱등수라고 주장하므로 HTTP GET 요청에 대해 CSRF 보호가 없습니다. 그러나 이러한 GET 요청을 통해 사용자에게 반환되는 중요한 정보가 있으며이 정보를 검색하는 악성 사이트가 필요하지 않습니다.CSRF Rails에서 HTTP GET 요청으로 보호
HTTP GET 요청을에서 Rails로 보호하는 가장 좋은 방법은 무엇입니까?
A
답변
9
CSRF 공격의 요청에 대한 응답을 읽을 수 있으려면 공격자가 희생자에게 자신의 JavaScript 코드를 실행시켜야합니다. 이 경우 액세스는 일부 Same Origin Policy으로 제한됩니다.
정말 cross origin을 공격 요청을한다 가정하면, Same Origin Policy for DOM는 DOM을 통해 접근을 금지 (예 : iframe를 사용하여 포함 된 경우) 다음과 같이 Cross-Origin Resource Sharing (CORS)는 XMLHttpRequest를 통해 출처 간 요청을 조절 : 요청이 simple cross-origin request입니다
있다면, . 이자형. simple method이 simple header fields 인 경우 해당 요청이 전송됩니다 (HTML 기반 CSRF와 유사 함). 그러나 단순 교차 출처 요청의 응답은 response allows resource sharing인지 여부에 달려 있습니다.
다른 원본 출처 요청에는 실제 요청을 보내기 전에 소위 preflight이 필요합니다. 이 요청은 서버가 프리 플라이트가 보낸 원본 요청을 허용하는지 여부를 확인하기 위해 전송됩니다. 프리 플라이트가 성공하고 실제 요청에 대한 응답이 리소스 공유를 허용하는 경우에만 응답에 액세스 할 수 있습니다.
결론 : 서버가 CORS를 지원하고 다른 출처 (예 : Access-Control-Allow-Origin: *)와 명시 적으로 공유 할 수있는 경우가 아니라면 요청이 허용되면 CSRF 응답이 공격 사이트에서 읽을 수 없습니다 .
악의적 당사자가 CSRF 공격 그들이 요청의 결과가 표시되지 않습니다 - 단지 부작용 –
당신은 일반적으로 인증이 쿠키를 통해 @NikitaBeloglazov 경우에도 작업 –
이런 종류의 쿠키를 통해 인증을 사용 위험을 , 브라우저는 피해자 사이트가 만들어지기를 요청할 때 일반적으로 쿠키를 피해자 웹 사이트로 보냅니다. 이것은 [위키 백과 문서] (http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics)에서입니다. "Bob의 은행이 쿠키에 인증 정보를 보관하고 쿠키가 만료되지 않은 경우, Bob의 브라우저가 이미지를로드하려고 시도하면 쿠키가있는 철회 양식이 제출되어 Bob의 승인없이 거래가 승인됩니다. " –