Skip to content

Commit

Permalink
CORS 관련 포스팅 추가
Browse files Browse the repository at this point in the history
  • Loading branch information
mainmethod0126 committed Dec 28, 2024
1 parent 067a806 commit 83e0fe2
Show file tree
Hide file tree
Showing 2 changed files with 84 additions and 1 deletion.
3 changes: 2 additions & 1 deletion pages/security/_meta.json
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
{
"SSLandTLS": "SSL과 TLS",
"What-is-SSH": "SSH(Secure Shell Protocol) 란?",
"oauth-authentication-method": "oauth에 대해서 알아보자"
"oauth-authentication-method": "oauth에 대해서 알아보자",
"what-is-cors": "CORS 란?"
}
82 changes: 82 additions & 0 deletions pages/security/what-is-cors.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
import { Callout } from "nextra/components";


# CORS 란

CORS 정말 간단하게 살펴보자

사용자가 `은행` 사이트에 접속해서 온라인 뱅킹을 하고있다고 가정하자

이때 `공격자(해커)` 가 은행 웹 사이트를 제공하는 서버에 취약점을 발견하여 자신이 만든 `악성 웹사이트` 접속 URL을 은행 사이트 어딘가에 숨겨놓았다.

```
은행 도메인 : bank.com
악성 웹 사이트 도메인 : copy.back.com
```

`악섭 웹 사이트` 접속할 경우 브라우저 스토리지에 저장된 `인증 정보` 를 찾아서 이를 통해 `은행 송금 API`를 호출하여 공격자의 통장으로 입금되도록 해놓는다

이렇게되면 사용자가 은행 웹 사이트를 이용하다가 자신도 모르는 사이에 공격자의 통장으로 송금을 해버리는 문제가 발생한다

`브라우저(chrome, edge, sarfari 등)` 는 이를 방지하기 위해 서버 Service 가 보내주는 `Access-Control-Allow-Origin` 라는 값에 허용되는 도메인이 아닐 경우 `Request` 자체를 차단시켜버린다

서버가 보내는 `Access-Control-Allow-Origin` 의 예시는 보통 아래와 같다

```
Access-Control-Allow-Origin : * : 클라이언트의 도메인이 무엇이든 허용하겠다
Access-Control-Allow-Origin : back.com : 클라이언트의 도메인이 bank.com 일 때만 허용하겠다
```

차단 자체는 브라우저에서 하는 거기 때문에 브라우저에서 정책을 꺼버리면 그냥 `Request`를 그대로 진행해버린다.

이때 브라우저는 서버로 보내는 요청에 자동으로 `Origin` 이라는 헤더를 추가하는데 예시는 아래와 같다

```
정상적인 은행 웹 사이트에서 Request를 보낼 때
Origin : bank.com
악성 웹 사이트에서 Request를 보낼 때
Origin : copy.bank.com
```

브라우저는 Request에 붙어있는 `Origin` 값과 서버가 보내준 `Access-Control-Allow-Origin` 을 비교하여 일치하는 값이 있을 경우에만 `Request`를 허용한다

<Callout type="warning" emoji="">
"Access-Control-Allow-Origin 를 받았다는 건 이미 서버에서 응답을 보낸거 아니냐? 이미 Request를 보냈는데 그 이후에 차단하는게 무슨 의미냐"
</Callout>

정확하다, 애초에 Request가 가야 `Access-Control-Allow-Origin` 를 받을 수 있는데, 그러면 이미 Request를 보내버린 시점이라 그 이후 차단은 무의미하다.

그렇기 때문에 브라우저는 실제 Request가 발생하기 전, 서버로 부터 `Access-Control-Allow-Origin` 을 확인하기 위한 `Request를 하나 더 보낸다` 이를 `Preflight 요청` 이라고 한다

## Preflight 요청

`Preflight Request`의 경우 일반적으로 `OPTIONS` Method를 사용하게 된다

1. Client 코드에서 `송금API Request` 를 시도한다
2. 브라우저가 먼저 `송금API Request Url` 쪽에 `OPTIONS` Method를 이용하여 `Origin` 을 포함한 `Preflight Request` 를 보낸다
3. 서버는 이에 응답으로 `Access-Control-Allow-Origin` 를 반환한다
4. `Origin``Access-Control-Allow-Origin` 를 비교하여 허용된 `Origin` 일 때 `송금API Request` 를 보낸다

Preflight Request 예시

```
OPTIONS /api/remittance HTTP/1.1
Host: bank.com
Origin: https://bank.com
```

## 요약

브라우저가 실제 Request 전 `Origin` 헤더를 포함한 `Preflight Request` 를 보내는데 이때 응답으로 오는 `Access-Control-Allow-Origin``Origin` 를 비교하여 허용되지 않은 `Origin`이면 실제 Request를 보내지 않음











0 comments on commit 83e0fe2

Please sign in to comment.