CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (2) - 가상의 브라우저에 대한 CSRF 공격, 서버의 책임과 브라우저의 책임

목차

---

1. CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (1) - CSRF 공격이란 무엇인가

2. CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (2) - 가상의 브라우저에 대한 CSRF 공격, 서버의 책임과 브라우저의 책임

3. CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (3) - CSRF 공격을 직접 시도해보자 (Safari 브라우저)
4. CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (4) - SOP, CORS, Browser, Third-Party Cookie, SameSite)

5. CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (5) - CSRF 공격을 방어해보자 (SSR Application)

6. CSRF(Cross-Site Request Forgery) 개념부터 재현, 방어까지 (6) - CSRF 공격을 방어해보자 (CSR Application)

 

 

---

서론

---

현대의 브라우저는 많이 발전했기에 브라우저 차원에서 CSRF 공격을 막아주는 옵션이 많다.

 

그 옵션들을 하나씩 설명하며 재현하는 것은 누군가는 흥미를 가질 수 있지만 누군가는 지루해 할 수도 있다.

 

그리고 1~2년이 지나면 브라우저들도 업데이트를 하면서 재현예제가 무용지물이 될 수 있기에 브라우저 스펙들이 바뀌더라도 이해할 수 있는 개념들을 설명하고자 한다.

 

그렇기에 이번 포스팅에서는 가상의 브라우저가 있다고 가정하고 CSRF 공격의 예시를 들어보겠다.

 

---

가상의 브라우저

---

Ping9 브라우저가 있다고 가정하겠다.

 

Ping9 브라우저의 쿠키처리에 대한 스펙은 아래와 같이 단 3가지 이다.

• 응답에 Set-Cookie 헤더가 있으면, Browser 의 Local Storage 에 저장한다.
  • Key 는 응답한 서버의 도메인이며, Value 는 Set-Cookie 의 값을 `;` 를 기준으로 split 하여 저장한다.
• 발생하는 모든 요청에 대하여 Request URL 의 도메인을 Key 로 하는 모든 값을 Local Storage 에서 찾아 Cookie 헤더에 Value 로 추가한다.
• 자바스크립트로 Local Storage 를 조회할 수 없다.

Ping9 브라우저의 쿠키처리 스펙

---

CSRF 공격 - 가상의 브라우저

---

Ping9 브라우저에서 CSRF 공격을 하려면 어떻게 해야할까?

 

1. 사용자에 대한 인증을 Cookie 로 하는 사이트를 찾는다.

2. 해당 사이트에 돈이 될만한(?) API Endpoint 를 찾는다.

3. 피싱 사이트를 만들어 피싱사이트 진입을 유도하고 진입했을 때 미리 물색해 둔 API Endpoint 를 호출하게 한다.
  (취약사이트에 피싱사이트 링크가 삽입된 글을 올린다거나 등)

 

Ping9 브라우저에서는 현재 브라우저에 있는 도메인과 다른 도메인에 대해 요청을 할 때 쿠키 값을 포함시킬 수 있기에 `attacker.com` 이라는 사이트에서 `target.com` 으로 요청을 생성하기만 하면 Ping9 브라우저는 친절하게도 `target.com` 의 쿠키값을 request 에 추가하여 보내주게 된다.

 

CSRF 가상 공격 예시

 

 

서버의 책임

요청을 받는 서버는 Ping9 브라우저를 사용하는 유저에 대한 예외처리를 하거나, 제 2의 Ping9 브라우저가 유행할 것에 대비하여 Cookie 값만으로 서버의 동작 및 리소스 권한을 허락해서는 안될 것이다.

 

CSRF Token, JWT Token 인증방식의 개념이 이를 보완하고자 탄생하게 된다.

 

 

브라우저의 책임

브라우저는 렌더링하고 있는 사이트에서 발생하는 요청이 타 도메인을 향할 경우, 타 도메인이 허락하지 않는 이상 쿠키 값을 포함시키지 말아야 한다.

 

HTTP 통신 특성상 브라우저는 타 도메인의 허락에 대한 유무를 Response 를 통해 판단할 수 밖에 없으며, 타 도메인에서 Response 에 특정 flag 를 추가 하지 않는다면 기본적으로 쿠키 값을 Reqeust 에 포함시키지 말아야 기존 서비스들이 추가적인 개발 없이 안전할 것이다.

 

SOP, CORS Access-Control-Allow-Credentials, Third-Party Cookie Block, Cookie SameSite 등의 개념들이 모두 여기서 탄생하게 된다.

 

그리고 쿠키의 탈취를 막고자 HttpOnly, Secure 와 같은 쿠키 옵션도 등장하게 된다.