CSRF, CORS 개념

두가지 단언가 이름도 비슷하고 자꾸 혼동이와서 정리할려고 한다.

 

CORS(Cross-Origin Resource Sharing)

CORS는 한국어로 직역하면 교차 출처 리소스 공유라고 해석된다. 여기서 교차출처란 "다른출처"를 의미한다.

 

출처란 무엇인가?

이때 출처는 Protocol과 Host를 나타낸다 (:8080 , :433 포트 번호까지 포함) 즉 서버의 위치를 찾아 가기 위한 기본적ㅇ니 것들을 합쳐놓은 주소이다.

SOP(Same-Origin Policy)

웹 생태계에는 다른 출처로의 리소스 요청을 제한하는 것과 관련된 두 가지 정책이 존재한다. 한 가지는 이 포스팅의 주제인 CORS, 그리고 또 한 가지는 SOP(Same-Origin Policy)이다.
SOP는 지난 2011년, RFC 6454에서 처음 등장한 보안 정책으로 말 그대로 “같은 출처에서만 리소스를 공유할 수 있다”라는 규칙을 가진 정책이다.
그러나 웹이라는 오픈스페이스 환경에서 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔한 일이라 무작정 막을 수도 없는 노릇이니 몇 가지 예외 조항을 두고 이 조항에 해당하는 리소스 요청은 출처가 다르더라도 허용하기로 했는데, 그 중 하나가 “CORS 정책을 지킨 리소스 요청”이다. (참고로 CORS라는 이름이 처음 등장한 것은 2009년이라, SOP의 등장보다 빠르다)

즉 SOP 정책을 웹 서버상에서는 지키기 어려우니 CORS란 정책을 도입하여 다른 출처들간의 자원을 교환하는 것이다.

재밌는점은 여기서 출처를 비교하는 로직이 서버에 구현된 스펙이 아니라 브라우저에 구현되어 있다는점이다.

 

CORS 동작방식 3가지

• Preflight Request
• Simple Request
• Credentialed Request

CORS를 해결할 수 있는 방법

Access-Control-Allow-Origin 세팅하기

CORS 정책 위반으로 인한 문제를 해결하는 가장 대표적인 방법은, 그냥 정석대로 서버에서 Access-Control-Allow-Origin 헤더에 알맞은 값을 세팅해주는 것이다.
이때 와일드카드인 *을 사용하여 이 헤더를 세팅하게 되면 모든 출처에서 오는 요청을 받아먹겠다는 의미이므로 당장은 편할 수 있겠지만, 바꿔서 생각하면 정체도 모르는 이상한 출처에서 오는 요청까지 모두 받아먹겠다는 오픈 마인드와 다를 것 없으므로 보안적으로 심각한 이슈가 발생할 수도 있다.
그러니 가급적이면 귀찮더라도 Access-Control-Allow-Origin: https://www.naver.com와같이 출처를 명시해주도록 하자.

 

CSRF(Cross Site Request Forgery)

CSRF는 해커가 사용자의 컴퓨터를 감염시키거나 페이스북 서버를 해킹을 해서 이뤄지는 공격은 아닙니다. 그래서 CSRF 공격이 이뤄지려면 다음 조건이 만족되어야 합니다.

• 위조 요청을 전송하는 서비스(은행,네이버,페이스북)에 희생자가 로그인 한 상태
• 희생자가 해커가 만든 피싱 사이트에 접속(주로.. 음란물 사이트같이 클릭을 유도하는 사이트인것 같다)

Spring Security에서는 이러한 CSRF에 의한 공격을 방지하기 위해서 Form형식의 전송 들에대해서는 _csrf 라는 hidden 타입으로 값을 설정하고 이값과 서버에서 받는 값이 일치해야 요청 전송을 허가한다.

이러한 CSRF는 다음과 같은 설정으로 사용하지 않을 수도 있다. ( REST API 요청에대해서는 필요없다)

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
   WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
      .csrf().disable();
  }
}