CSRF, 이를 막기 위한 CORS

CSRF는 Cross Site Request Forgery, CORS는 Cross Origin Resource Sharing의 약자.

 

일단 Site와 Origin의 차이를 살펴보자.

• Origin : Scheme :// Host Name(Domain Name) : Port
  • ex) https://namucy.tistory.com:8080
    • https 가 scheme ; 프로토콜을 의미
    • namucy.tistory.com 가 Host Name;
      namucy가 subdomain, tistory가 second level domain, com이 top level domain
    • Port는 서버가 요청을 받는 포트를 말한다. 일반적으로 생략되어있으면 default 포트로 향함.
• Site : Domain Name 중 Second level domain + Top level domain이다.
  • ex) 위의 예시에서는 tistory.com
  • www.ibk.co.kr에서는 ibk.co.kr이다 (co.kr을 eTLD라고 하고 이를 사용)

 

 

CSRF (Cross-Site Request Forgery)

• 타 사이트에 대한 의도치 않은 요청.
• 웹 브라우저 뿐 아니라 앱에서도 가능한 일이다.
• 웹 브라우저에서는 유저가 의도치 않은 요청이 JavaScript 실행을 통해 서버에 전송되는 것.
• 후술 할 CORS를 통해 CSRF의 일부분을 방어가 가능함.
  • 네이티브 앱에서는 방어가 불가능해 XSRF Token을 사용(임의 난수+ 세션 활용)
  • 웹브라우저에서 AJAX가 아닌 FORM을 통한 POST요청은 방어 불가능

 

이미지 출처 : https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/cors.html

 

 

CORS (Cross Origin Resource Sharing)

• 웹 브라우저에서 CSRF를 막기 위해 사용 되는 정책
• 기본적으로 같은 출처에서만 요청을 허용하는 SOP(Same-Origin Policy)를 사용하지만,
  CORS는 이를 보완해서 특정 조건에서 AJAX 요청을 허용해서
  FE 개발자들이 자바스크립트로 API를 호출할 수 있게 허용.
• 즉, 브라우저가 다른 도메인으로의 AJAX 요청을 제한하는 정책.
• 서버가 CORS 헤더를 설정 후, 브라우저가 요청을 허용할 지 결정하는 방식.
  • Simple Request(GET, HEAD) 요청과 같은 서버 상태 조회 요청의 경우,
    요청 → 처리 → 응답 후 브라우저가 CORS 헤더를 검증
  • Preflight Request: POST, PATCH, PUT 등 서버 상태를 변경하는 요청은
    먼저 Preflight 요청(OPTIONS)을 보내서 서버가 요청을 허용하는지 확인한 후 원 요청을 보냄.
• CORS 서버 측 설정 방법
  1. Access-Control-Allow-Origin: 허용된 출처 설정.
  2. Access-Control-Allow-Method: 허용된 HTTP 메서드 설정 (GET, POST 등).
  3. Access-Control-Allow-Headers: 허용된 요청 헤더 설정 (예: Content-Type 등).
  추가적으로, 인증 정보를 포함하는 요청은 Access-Control-Allow-Credentials 헤더를 설정해야 한다.
• 서버는 3가지 CORS 헤더를 설정하여 요청을 허용할지 결정

 

 

 

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Origin - HTTP | MDN