웹 해킹 공부 일기장 9 - 1 (CSRF 정리)

저번 시간에 CSRF에 대해 알아보았습니다.

CSRF란? 피해자가 서버로 임의의 요청을 보내게하는 공격이었습니다.

 

CSRF 공격을 하기위한 절차를 정리해보겠습니다.

1. 중요한 요청 식별

서버에 보내는 요청 중 중요하다고 생각하는 요청들을 식별합니다.

예를 들어, 비밀번호 변경 요청과 같이 요청이 중요하다고 생각되는 것을 확인합니다.

 

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

예를 들어, 비밀번호 변경 요청을 미리 만들어서 해당 요청을 보내기만하면 비밀번호가 변경되는지 확인합니다.

즉, 다른 추가 데이터의 요청이 필요한지 확인합니다.

 

일단, 2번까지 가능하다면 CSRF 취약점이 존재한다고 할 수 있습니다.

 

3. GET 방식 체크

요청을 처리하는 방식이 GET 방식으로 처리가 가능한지 확인합니다.

예를 들어, 비밀번호 변경 요청이 POST 방식이라도 GET 방식으로 바꿔서 요청을 보내보며 GET 방식으로도 비밀번호를 변경 가능한지 확인합니다.

 

>> 여기서 가능하다면, 해당 요청을 링크로 제작하여 링크에 접속하게만 하면 접속한 피해자들은 비밀번호가 변경될 것입니다.

 

4. POST 방식 체크

요청을 처리하는 방식이 POST 방식으로만 처리가 가능한지 확인합니다.

비밀번호 변경 요청이 GET 방식으로는 처리가 안되고 POST로만 처리가 가능하다면 XSS 취약점을 해당 웹 서버에서 찾습니다.

그리고 XSS 취약점과 연계하여 POST방식으로 비밀번호 변경 요청을 보내어 CSRF 공격을 실시합니다.

 

 >> 이때 사용할 수 있는 방법은 앞에서 정리해놓았습니다.

<form> 태그 사용, CSRF 공격에 대한 응답을 무시할 경우 <iframe> 태그를 사용합니다.

 

대응 방안

 

CSRF 공격이 발생하는 이유?? 

요청 데이터를 공격자가 알고 미리 세팅할 수 있어서 발생하는 것 같습니다.

만약, 요청 데이터를 공격자가 미리 공격 포맷을 만들어 놓을 수 없다면 해당 요청을 보내도 요청을 처리하지 못 할 것입니다.

 

이때 사용하는 것이 CSRF Token 입니다. 이 토큰은 랜덤한 값으로 요청을 보낼때 해당 값을 같이 보내줘야 요청을 처리할 수 있게합니다.

 

비밀번호 변경을 할 경우 마이페이지를 불러와 마이페이지에서 변경할 비밀번호를 입력하고 비밀번호를 변경할 것입니다.

마이페이지를 불러올 때 변경할 비밀번호를 입력할 <form> 태그 내에 CSRF Token을 같이 웹 서버에서 제공하고 사용자는 받은

CSRF Token을 함께 보내 웹 서버에서 올바른 토큰이면 요청에 대한 처리를 해줍니다.

<form action="" >
    <input type="text" name="password" value="1234"/>
</form>

<form action="" >
    <input type="text" name="password" value="1234"/>
    <input type="hidden" name="csrf_token" value="랜덤한 값"/>
</form>

 

예를 들어 첫번째처럼 처리될 비밀번호 변경을 <input> 태그로 CSRF Token 도 같이 받는 것입니다.

hidden으로 처리되기 때문에 일반 사용자들은 있는 지도 모르고 사용하는 것입니다.

 

하지만, 이 CSRF Token도 XSS 취약점을 만나면 우회가 가능했습니다.

<iframe> 태그로 해당 페이지를 가져오면 CSRF Token도 같이 부여받을 것이고 그 값을 포함시켜 요청을 보내면 됩니다.

 

결국 CSRF Token도 해결방안이 되지 못합니다.

 

그래서 CSRF 공격이 발생하는 이유를 다시 생각을 해보니 

원래 요청을 보내는 페이지가 아닌 다른 페이지에서 요청을 보내는 것들은 정상적인 요청이 아닌 것을 확인할 수 있습니다.

즉, 정상적으로는 마이페이지에서 비밀번호 변경 요청을 보내야하는 데 게시판의 XSS 취약점을 통해 요청을 보내고 있었습니다.

 

그렇기 때문에 해당 요청에 대한 처리를 하기위해 올바른 페이지에서 요청을 보냈나?? 확인할 필요가 있습니다.

확인을 할 수 있는 것이 Referer 헤더입니다.

 

Referer 헤더에는 어느 페이지에서 요청을 보냈는 지 포함되어 있습니다.

그렇기 때문에 마이페이지가 아닌 다른 곳에서 보낸 요청에 대해서는 비밀번호 변경 요청을 처리하지 않을 수 있습니다.

 

그럼 Referer 헤더를 사용하면 CSRF 공격을 원천적으로 막을 수 있을까요??

Referer 헤더를 올바르게 사용하면 CSRF 공격을 원천적으로 막을 수 있습니다.

하지만!! 해당 헤더에 대해 올바르게 처리해야합니다.

예를 들어, 만약 Referer 헤더를 지우고 Referer 헤더가 없을 경우에는 그냥 요청에 대해 처리하는 경우있을 수 있다고 합니다.

엥?? 왜 그렇게 개발을 했지? 할 수 있는데 이건 개발 특성인데 예외처리라는 것이 있습니다. 예외가 발생했을 경우 개발하고 유지하는 사람이 계속 바뀌는 개발의 특성으로 어떤 오류가 발생할 지 모르기 때문에 예외가 발생했을 경우 그냥 처리해버리게 만든 경우가 있습니다.

 

그렇기 때문에 Referer 헤더가 없는 경우 그냥 처리하자!! 오류발생하면 귀찮아 지니.. 라고 개발할 경우 해당 헤더를 지우고 요청을 보내버리면 CSRF 공격을 그대로 이어갈 수 있는 것입니다.

 

Referer헤더를 지우는 방법은 

<meta name="referer" content="no-referer"> 만 XSS 공격시 같이 입력해주면 됩니다.

 

그럼 CSRF 공격의 근본적인 대응 방안은 없는 걸까요?

요청을 보낼 때 인증정보를 같이 포함시켜 보내도록 해야합니다.

비밀번호 변경 요청에서 이전 비밀번호를 입력하도록하면 공격자는 미리 공격 포맷을 만들어 놓을 수 없기때문에 공격을 할 수 없습니다.

이렇게 요청을 보낼때 같이 인증정보를 입력받아야합니다. 이것이 CSRF 공격의 근본적인 대응방안이 됩니다.

 

또!!! 하지만 우리가 모든 요청에 비밀번호 입력받고 전화번호 인증하고 이럴 수가 없습니다.

그렇기 때문에 해당 요청의 중요도에 따라 앞에서 설명한 대응방법들을 적용시켜줍니다.

 

비밀번호 변경 같이 중요한 요청은 인증정보도 함께 입력받고,

게시글 쓰기 같은 요청들은 CSRF Token 정도로 요청을 처리할 수 있습니다.

 

이렇게 CSRF 공격에 대한 정리를 해보며 대응 방안까지 알아보았습니다.

모든 요청에서 가능한 공격이다 보니 대응하는 방법도 요청에 중요도에 따라 공격에 대응해야 합니다.