[기록일지] 📚 13주차 (CSRF 대응 / 우회)

CSRF 대응 및 우회

CSRF는 피해자가 서버로 임의의(공격자가 원하는) 요청을 보내게 만드는 공격이다.

CSRF 공격의 절차는 다음과 같다.

CSRF 공격 절차

1. 중요한 요청 식별

(중요하다고 생각되는 요청을 식별하는 것이 중요하다.)

 

2. 그 요청을 만들 수 있는지 체크

(인증 정보가 있는지 확인하고, 없다면 CSRF 취약점으로 이용 가능하다.)

 

3. GET Method 체크

(POST Method라면 GET Method로 바꿔서 보내보고 되는지 확인한다.)

POST Method로만 처리되도록 구현 한다고 방어되는 것은 아니다.

 

대응 - POST Method

4. CSRF 공격(with POST Method)

> XSS 취약점이 있는지 확인
> POST Form Tag를 활용

요청 데이터를 공격자가 미리 세팅할 수 있다는 것이 위험한 것이다. 즉 파라미터를 이미 알고 있다는 것인데 이에 대하여 대응하기 위해서는 토큰을 추가할 수 있다.

 

대응 - CSRF Token

공격자가 미리 세팅할 수 없는 값을 추가한다는 것이다.

토큰은 해당 페이지에 접속 해야만 생성되는 랜덤한 값으로서 위조할 수 없는 값이 된다.

1. <hidden> - random 값 생성
2. DB or Session에 저장
3. 해당 페이지에 접속할 때마다 넣어서 보내줌.

 

5. CSRF 공격 (Bypass CSRF Token)

다만 해당 공격은 XSS 취약점이 존재해야만 우회가 가능하다.

XSS
> iframe

 

대응 - Referer

referer 헤더(header)를 이용하는 방법이 있다.

referer 헤더는 '이 요청이 어느 페이지에서 요청한 것인가?' 를 확인하는 것으로서, 특정 페이지에서 온 요청만 받겠다! 라고 선언하는 것이다.

해당 대응에 대한 우회 방법은? 없다!

Referer를 제.대.로 체크했을 때 우회가 불가능 하다는 것이다.

하지만 referer를 제대로 체크하는 것은 쉽지가 않다.

---

잘못된 예외 처리

만약에 에러가 발생한다면? 우리가 어떻게 처리할 것인가에 대하여 생각해 보아야한다.

일반적으로는 try catch를 이용하여 에러가 발생 했을때 어떤식으로 처리할지 결정하게 된다.

처리 방법

서비스를 중단하는 방법과 vs 눈 감아주는 방법

일반적으로 생각하면 당연히 서비스를 중단하는 방법이 맞다고 생각할 수 있다. (보안상) 하지만 에러가 발생하는 족족 서비스를 중단한다는 것은 무리가 있다.

그러면 코드를 고치면되는게 아닐까? 라고 생각할 수 있다.

하지만 코드를 잘못 만지면 다른 곳에서 문제가 발생할 수 있다는 것이다. 내가 지금 작성하는 코드가 서버에 어떤 영향을 끼칠지 모르기 때문인데 이 이유는 한 사람이 모든 코드를 다 짜는것이 아니고, 여러 사람이 수정 보완하기 때문이다.

또한 최초 개발자가 계속해서 관리하는 것이 아니고 유지보수는 따로이 진행되는 경우가 많기 때문에 시스템을 전부 파악하는 것은 불가능에 가깝고, 에러 발생 시 모든 것을 막아 버리면 다른 곳에서 문제가 발생할 수도 있기 때문에 서비스를 중단하는 것이 아니고 눈감아 주는 경우가 많다는 것이다.

위와 같은 이유를 생각하며 아래를 살펴보자.

ex)  비밀 번호 변경(feat. CSRF Token)

1. 비밀번호가 변경되는 마이페이지에만 CSRF 토큰을 만들어주었다.
2. 그런데 알고 보니 개인 시크릿 페이지에서도 비밀번호 변경 기능이 지원되고 있었다.
(비밀 번호 변경 요청이 CSRF Token 설정을 한 페이지 이외에서도 가능했던 경우)

change_pass.php 라는 비밀번호를 변경하는 과정에서 CSRF Token을 검사한다면?

CSRF Token을 설정해둔 페이지에서는 변경 요청이 가능하지만, 기존에 변경 기능이 지원되었던 곳인데 미처 확인하지 못하고 CSRF Token이 누락된 곳이 있다면? 해당 페이지에서 보내는 변경 요청은 불가능해진다는 것이다.

그래서 많은 개발자들이 '눈감아 주기'를 선택한다는 것이다.

 

Bypass CSRF Token (feat. 눈감아주기)

csrf_token 파라미터가 없으면? csrf 토큰을 검사하지 않는다. 라는 방식을 취하는 경우도 허다하다는 것이다.

즉 파악하지 못한 다른 요청에 영향을 줄까봐 , 빡세게 잡지 않는다는 것이다.

그래서 csrf token이 존재하더라도 해당 파라미터를 빼고 요청을 해보면되는 경우가 있다는 사실을 인지하자!

Referer 또한 마찬가지이다.

 

CSRF 공격 (Bypass Referer, feat 눈감아주기)

그래서 referer를 없애고 보내는 경우에 될 수 있다는 것을 인지하자.

<meta name="referrer" content="no-referrer">

위의 메타 태그를 이용하면 referer를 지우고 보낼 수  있고, 이 방식으로 우회가 될 수 있다. 이 방법으로도 우회가 되지 않는다면 referer가 제대로 구현되어 있다는 것이고, 그렇다면 우회되지 않는 것이다.

---

근본적인 대응 방법

'Referer Check' 가장 확실한 방법은 referer 체크를 제.대.로 하는 것이다.

하지만 CSRF 취약점이 발생하는 근본적인 원인을 생각해보면 요청의 파라미터를 미리 세팅할 수 있어서 발생하는 것인만큼 미리 세팅할 수 없게만 만들면된다.

즉 인증정보를 넣으면 된다는 것이다.

 

인증 정보 추가

하지만 모든 곳에서 인증을 추가적으로 진행한다면? 이는 귀찮음을 넘어서서 이용시의 짜증을 유발할 수 있다는 사실을 인지해야 한다.

그러므로 개발자의 입장에서 판단 했을 때 민감한 정보를 처리하는 경우에만 넣어야한다.

본인 인증 / 휴대폰 인증 / 2차인증 / 비밀번호 인증

ex) 개인정보 변경 페이지

기존 비밀번호를 함꼐 입력받는 방식을 취함으로서 기존 비밀번호는 미리 세팅할 수 없는 값이므로 대응책이 될 수 있다.

---

질문 환영, 수정 및 보완에 대한 지적 환영