CSRF 정리 (feat. SOP/CORS)

 

오늘은 13주 차를 들어 지금까지 배운 CSRF와 새로 배운 SOP/CORS를 정리하는 시간입니다.

 

 CSRF ( Cross Site Request Forgery )

CSRF란 피해자가 의도와는 상관없이 공격자가 원하는 요청을 서버로 보내도록 만드는 공격입니다.

 

원인

CSRF가 발생하는 가장 큰 원인은 인증정보의 부재입니다.

ex) 비밀번호 변경 시 현재 비밀번호를 입력하지 않음 등

 

해결 방법

인증정보가 없어서 발생하는 취약점이니 인증정보를 포함합니다.

 

 인증정보 예시

- 현재 비밀번호

=> 비밀번호 변경, 개인정보 변경 열람 등 중요한 요청에 대한 인증정보로 사용합니다.

 

- csrf token

=> 게시글 열람, 게시글 작성 등 덜 중요한 요청에 대한 인증정보로 사용합니다.

=> XSS 취약점이 있는 경우 탈취당할 위험성이 있습니다.

 

- Referrer Header

Referrer Header는 HTTP 요청이 가는 위치 정보를 포함합니다. (요청을 보낸 URL)

=> <meta name='referrer' content='no-referrer'>를 삽입해 Referrer Header를 전송하지 않게 할 수 있습니다.

=> JS로 변조가 가능합니다.

=> 다른 인증정보와 함께 추가적인 인증정보로 사용합니다.

 

CSRF GET Method

서버에 요청을 보내는데 인증 정보가 없고, GET 메서드로 요청이 가능하다면 서비스를 요청하는 링크를 생성해 피해자가 접근하도록 만들 수 있습니다.

ex) http://attack.com/mypage_update.php?pw='1234'  => 링크에 접근하면 비밀번호가 1234로 변경됨

 

CSRF POST Method

POST 메서드의 경우 URL에 파라미터를 포함할 수 없기 때문에 form태그 혹은 js를 이용해서 데이터를 전송해야 합니다. 그렇기 때문에 XSS 취약점을 찾아 연계해서 사용해야 합니다.

 

CSRF와 XSS 연계

XSS는 클라이언트 측 스크립트를 삽입하는 공격입니다. 그렇기 때문에 form 태그 혹은 JavaScript를 삽입하여 사용자의 의지와 상관없이 서버에 요청을 보내도록 만들 수 있습니다.

 

 시나리오

1. 스크립트가 삽입된 게시글에 접근하면 CSRF가 가능한 링크에 접속해(GET Method) 비밀번호가 변경됩니다.

2. 게시글에 접근하면 숨겨진 form 태그와 JS를 통해 CSRF 취약점이 있는 서비스로 POST 요청을 보내 원하는 서비스를 실행시킵니다.

3. iframe 태그를 삽입해 csrf token을 받아와서 탈취한 뒤 서비스로 요청을 보낼 때 포함시킵니다.

 

공격자가 만든 서버에서 취약점을 일부러 만든 뒤 피해자가 접근하게 만들어 다른 도메인(ex 네이버, 구글)의 계정 정보를 변경하거나 탈취하는 것은 뒤에서 설명할 SOP/CORS가 방지합니다.
그래서 같은 도메인인 CSRF 취약점이 있는 사이트에서 XSS 취약점을 찾는 것입니다.

---

 SOP ( Same-Origin Policy)

 

같은 출처가 아닌 데이터에는 JavaScript로 접근을 못하게 하는 브라우저 정책입니다.

 

탄생 이유

XSS나 CSRF 취약점을 이용해 다른 도메인에 접근해 사용자의 정보를 탈취하는 것을 방지하기 위함입니다.

 

같은 출처란

스키마, 도메인, 포트가 모두 동일한 경우에 같은 출처로 취급됩니다.

ex)

http://naver.com

스키마://도메인:포트

 

단점

유연성이 없어 확장성이 매우 떨어집니다.

사이트끼리 정보를 주고받는 과정이 매우 불편하거나 불가능해집니다.

---

 CORS ( Cross Origin Resource Sharing )

 

SOP의 유연성 없는 정책을 보완하기 위해 몇 가지 규칙을 지키면 다른 출처의 도메인에서도 JavaScript를 이용해서 데이터에 접근이 가능하도록 하는 정책입니다.

 

CORS의 HTTP 헤더

CORS의 규칙은 HTTP 헤더를 통해 명시됩니다.

 

 ACAO ( Access Control Allow Origin )

데이터에 접근이 가능한 Origin(도메인)을 응답합니다. ACAO에 포함된 도메인에서만 JavaScript를 이용해 데이터에 접근이 가능합니다.

ACAO 과정
1. 클라이언트가 서버에 요청을 보낼 때 헤더에 Origin이 포함됩니다.
2. 서버가 Origin을 확인하고 미리 정의한 리스트에 있는지 확인합니다.(화이트 리스트)
=> 허가한 목록은 개발자가 직접 설정해야 합니다.
3.1. 허용된 도메인인 경우 응답에 ACAO헤더를 포함합니다.
ex) Access-Controll-Allow-Origin: domain.com
3.2. 허용되지 않은 도메인인 경우  브라우저가 차단합니다.
=> 서버에서 응답이 오기는 하지만 브라우저에서 차단하기에 JS로 접근이 불가능합니다.

 

ACAO는 개발자가 일일이 허용할 도메인을 추가해줘야 하기 때문에 매우 불편해서 *(모두 허용)를 사용하는 경우가 있습니다.

=> 사실상 SOP가 없는 것과 같기 때문에 매우 위험합니다.

 

 ACAC ( Access Control Allow Credentials )

교차출처(다른 도메인) 요청 시 자격증명(ex 쿠키)을 포함한 요청을 서버가 허용하는지 응답하는 헤더입니다.

ACAC 과정
1. 클라이언트가 서버에 요청을 보낼 때 헤더에 credentials : 'include'를 포함시켜야 합니다.
2. 서버에서 Access-Control-Allow-Credentials : true or false를 헤더에 포함해 응답합니다.

 

ACAC가 true일 경우 ACAO를 *로 설정할 수 없기 때문에 요청의 Origin Header를 그대로 ACAO에 넣는 경우가 있습니다.

=> SOP가 없는 것과 같기 때문에 매우 위험합니다.

---