CORS & CSRF

CORS 

Cross-Origin Resource Sharing (CORS):

두가지 출처에서 서로의 자원을 공유

 

여기서 출처: Origin 이란 URI를 뜻한다.

origin: (도메인주소, 포트 번호 , HTTP 프로토콜)

 

서로 다른 출처에서 자원공유를 하려할 때 브라우저에서 보안적 의미로 막는 행위

CORS가 없다면 해커의 서버에서 나의 서버로 쉽게 침투 할 수 있다.

 

보안 공격방법이 아닌 보안협약이라고 볼 수 있다.

 

이렇기에 백엔드서버와 프론트서버의 자원 공유를 위해 수동으로 이 설정을 풀어줘야한다.

 

해결 방법

1. @CrossOrigin(origins = "http://localhost:4200"):

Spring REST API 서버에서 Annotation으로 해당 origin의 요청을 허용

 

문제점: 실무 Controller의 요청 메서드에 일일히 Annotation을 달아줘야한다. 비생산적

 

2. Spring Security Config에서 CORS 설정:

 

 

 

해당 강의에서는 스프링 시큐리티 프레임워크를 사용할경우 스프링 시큐리티로 CORS 설정을하는것을 추천하고있다.

 

스프링 시큐리티를 사용하지 않는경우 

    /*
     * CORS 에러를 서버측에서 해결하는 방법.
     */
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:5173");
    }

 

WebMvcConfigurer를 구현한 WebConfig 클래스를 만들어 해결 할 수 있다.

 

 

2. Front server에서 설정하는 경우:

server: {
  proxy: {
    "/my-backend-api": {
      target: "http://localhost:8080",
      rewrite: (path: string) => path.replace(/^\/my-backend-api/, ''),
    },
  },
}

 

Vue.js와 같은 경우 프록시 서버를 설정으로 CORS 설정을 허용 할 수 있다.

 

쉽게 생각하자면 백엔드서버를 프론트 서버측에서 프록시 서버로 하나 만들어 프록시 서버에 API요청을 진행하여 프론트 서버는 API에 대한 로직을 수행 할 수 있게된다.

 

 

---

CSRF 

Cross-Site Request Forgery (CSRF):

해커는 사용자의 세션아이디, 쿠키, 어떠한 정보도 원하지않는다 

다만, 사용자가 무의식중에 보안에 취약한 행동을 하게 유도한다.

 

 공격 과정

1. 사용자가 A 사이트에 로그인 요청을 보낸다.

2. A 사이트에 요청을 허용하고 자격증명과 관련된 쿠키를 사용자에게 응답한다. (쿠키는 브라우저에서 보관됨)

3. 사용자가 A 사이트에서 해커가 운영하는 Evli.com에 접속

4. 사용자가 해당 해킹사이트에서 어떠한 링크에 속아 요청을 보낼 경우 해커의 숨겨놓은 코드가 실행 됨

5. A 사이트의 쿠키를 해킹하여 해커는 A사이트에 사용자 쿠키로 요청을 보냄. 

6. A 사이트 입장에서는 사용자의 쿠키인지 해커의 쿠키인지 구별할 수 없게되어 해킹이 되어버림

 

 

스프링 시큐리티로 구현한 CSRF 방어 코드

 

CSRF 토큰을 생성하여 방어하는 메커니즘

 

CSRF토큰을 생성해 이 토큰 없이는 요청을 받아주지 않는다.

CSRF는 쿠키의 속성이 Same-Site 이기때문에 다른 도메인 요청시 전송되지않는다.

따라서 해커의 입장에서는 CSRF토큰의 정보를 모르기때문에 해커의 악의적인 요청이 불가능해진다.