CORS

김기한·2022년 3월 7일
0

Web

목록 보기
2/2
post-thumbnail

교차 출처 리소스 공유 (CORS) 란, 서로 다른 도메인으로 요청을 보낼 수 있도록 허용하는 시스템이다.

만약 서로 다른 도메인으로부터 받는 모든 요청에 대한 제약이 없다면, CSRF나 XSS같은 공격에 취약할 수 있다.

CSRF

정상적인 사용자의 권한을 탈취하여 공격자가 의도한 행위 (데이터 수정, 삭제, 등록) 등의 행위를 함으로써 웹사이트를 공격하는 방법.

예를 들어, 페이스북의 어떤 사용자의 권한을 탈취하여 페이스북 서버로 post요청을 보내게 되면, 해당 사용자의 글목록에 새로운 글이 추가되게 되고, delete 요청을 보내면 글을 삭제할 수 있어 큰 문제가 된다.

<form action="http://facebook.com/api/content" method="post">
  <input type="hidden" name="body" value="대충 광고하는 내용" /> 
  <input type="submit" value="Click Me"/> 
</form>

위 코드에서 submit 버튼을 클릭하게 되면, facebook 서버로 광고성 글을 body에 담아 post 요청이 보내지고, 페이스북 데이터베이스에 글이 저장되게 된다.

그렇기 때문에 허용되지 않은 도메인으로부터 받은 요청을 검증할 필요가 있고, SOP(Same Origin Policy)에 의해 허용되지 않은 도메인은 요청을 보낼 수 없게 된다.

Stored XSS

CSRF와 비슷하지만, Stored XSS 공격은 아무 웹사이트에 스크립트를 삽입하여 공격대상 서버에 요청을 보내는 방식이다.

위 사진에는 alert 함수를 호출하도록 스크립트 코드를 작성하였지만, 공격대상 서버로 request를 보내는 코드를 작성하게 되면 이 역시 권한 없는 사용자가 데이터의 수정, 삭제, 등록이 가능하게 되고, 심각한 문제로 이어질 수 있다.

그렇기 때문에 허용되지 않은 도메인으로 부터의 요청을 거부하게 된다면 공격을 어느정도 방어할 수 있다.


이러한 문제를 해결하기 위해 SOP(Same Origin Policy)를 적용해야 하지만, 실제로 웹 애플리케이션을 설계하는 데 있어서 문제가 되게 된다.

SPA(Single Page Application)을 개발할 때, 보통 SPA 서버와 API 서버를 분리하게 된다. 이 때 SPA 서버와 API 서버의 origin이 달라지게 되는데, 이 역시 위에서 언급한 SOP에 위반되기 때문에 적절한 처리가 필요하다. 다음 두 가지 방법을 알아보자.

CORS

교차 출처 리소스 공유(Cross-Origin Resource Sharing) 로, 위의 문제를 해결할 수 있다. options 메서드를 이용한 요청을 통해 미리 허용된 origin 인지 검사하고 실제 필요한 요청을 처리하는 방식이다.

위 그림을 정리해보면,

  • 요청할 메서드와 헤더 종류, origin 전달 (Client -> Server)
  • 허용 목록에 존재하는 메서드와 헤더 종류, origin 인지 검증 후 허용 목록 전달 (Server -> Client)
  • 실제 요청 작업 처리

순서로 작업이 진행된다.

Proxy

두 번째 방법으로 Proxy가 있다. SOP 정책이 적용되는 것은 브라우저이기 때문에 Server<->Server 간 request에 대해서는 적용되지 않는다. 그렇기 때문에 Client -> API 서버로 전달되는 요청을 SPA 서버에서 Proxy 함으로써 SOP를 우회할 수 있다.


두 가지 방법을 살펴보았는데, 보통 개발 시에 webpackDevServer를 통해 proxy를 사용하여 cors를 처리하고, 빌드 시 서버 측에서 cors 보안 설정을 통해 해결한다고 한다.

개인적인 생각으로는 서버측에서 cors 보안 설정이 갖춰지지 않은 경우 테스트가 불가능하기 때문에 개발 시에 proxy를 사용하는 것이 아닌가 하고 추측해본다.

profile
vgihan's velog

0개의 댓글