CSRF(Cross Site Request Forgery) 취약점

개요

"Cross Site Request Forgery" 의 약자로 XSS의 취약점과 유사하게 사용자의 입력값 검증 및 사용자의 요청 시 세션 쿠키, 출발지 주소 등 올바르게 요청된 것인지 검증을 하지 않아 발생합니다.

공격 방식은 XSS와 유사하게 Reflect 방식과 Stored 모두 사용 가능합니다.

Reflect 기반이라면 보통 이미지 태그(img, iframe, embed src)와 링크 태그(a href)를 사용해 이미지에 링크를 삽입하는 등 GET 방식의 악성메일 형태로 전송하게 될 것이며, Store 방식도 iframe이나 script 태그를 이용해 코드를 삽입해둘 수 있습니다.
*Post 방식일 경우 "Form"을 이용하여 사이트를 이용하는 불특정 다수를 대상으로 진행할 수 있습니다.

공격자는 변조된 HTTP 요청을 삽입, 전송하게 됨으로써 클릭한 피해자가 자신의 인증된 계정으로 서버에 전달됩니다. 그렇기 때문에 만약 피해자가 높은 권한이 부여된 계정 상태라면 더욱 무언가를 삭제, 수정하기엔 쉬워집니다.

 

XSS와 다른 점

(1) Javascript 를 사용하지 않은 환경에서도 공격 가능
(2) Server 측을 타겟으로 요청(XSS는 클라이언트에서 공격이 이루어짐)
(3) CSRF는 공격자가 원하는 요청을 희생자의 권한으로 정상적인 요청인 것처럼 실행

취약한 환경

(1) Referer 헤더의 부제 및 검증 미흡
(2) CSRF 토큰의 부제
(3) 행위에 대한 Captcha 인증 부제
(4) 입력값을 검증하지 않는 HTML 폼

CSRF 공격을 성공하기 위해선 아래의 2가지 조건이 가능하다는 전제하에 진행됩니다.
첫째로 공격자가 원하는 행위가 로그인을 수행 후 진행되는 것이라면 마찬가지로 희생자도 로그인을 해둔 상태여야 합니다.

왜냐하면 이미 인증된 로그인 계정으로 유효한 HTTP 요청을 하기 때문에 서버 측에서는 올바른 행위라고 판단

* 하지만 랜덤 한 보안토큰이 존재할 경우 상호 간에 값이 틀리기 때문에 올바른 신원이 아니라고 판단

 

위처럼 몇몇 사용자들은 재로그인을 귀찮아하기에 이미 인증된 사이트는 닫지 않고 계속 유지시켜두는 분들이 있습니다. 이렇게 여러 사이트에 무차별적으로 신원이 인증된 상태에서는 CSRF 공격에 쉽게 노출됩니다.
*관리자 페이지의 경우 반드시 "세션 타임"을 지정하여 특정 행위가 없을 시 자동으로 로그인은 끊을 수 있도록 설정해야 됨

두 번째로 대상 페이지 내에서 불분명한 주소로부터 접근이 가능해야 됩니다. 자세한 건 아래에 설명하도록 하겠습니다.

 

대상 서비스의 crossdomain.xml을 보시면 웹 애플리케이션에 대해 다른 도메인들의 접근을 모두 허용하고 있습니다. 해당 접근이 미흡할 경우 XSS를 통해 사용자 인증을 탈취하거나 CSRF 같은 공격에 노출될 가능성이 높습니다.

 

두 번째로는 Referer 헤더의 부재입니다. 대상 서비스를 웹 프록시 도구를 통해 http 응답 헤더를 확인해보면 지정해둔 Referer 가 존재하지 않기 때문에 특정 행위가 어느 주소에 시작된 것인지 검증할 수가 없습니다.

 

패스워드 변경시 사용되는 매개변수를 파악하기 위해 정적 분석을 수행할 필요가 있습니다. 공격자는 다수의 사용자들의 패스워드를 변경시키기 위해 로그인 시 넘어가는 하위 도메인 주소를 파악해둡니다.

 

패스워드 변경 시 사용되는 매개변수를 확인하기 위해 웹 프록시 도구를 통해 확인했지만 body 영역에 노출되는 것을 제한해둔 상태라서 확인되지 않았습니다.

하지만 해당 페이지의 소스를 분석하다 보면 결국 어떤 매개변수를 통해 값을 전달하고 있는지 확인이 가능합니다.

 

필요한 매개변수를 모두 수집하고 공격자는 이미지 안에 공격자가 원하는 패스워드로 강제 변경되도록 코드를 삽입할 수 있습니다.

 

사용자가 이러한 이미지를 클릭하게 될 경우 링크 태그(a href)에 선언된 행위가 사용자의 권한으로 요청하기 때문에 서버 측에서는 악의적인 행위인지 알 수 없습니다.

또한 패스워드 변경 시 CSRF 행위를 막을 수 있는 "기존의 패스워드를 재입력" 하는 루틴이 존재한다 하더라도 "LIKE" 연산자인 %를 검증하지 않는다면 이 또한 쉽게 우회처리가 가능합니다.

 

사진을 보시는 것처럼 이미지를 클릭한 사용자의 패스워드가 쉽게 변경된 것을 확인할 수 있습니다.

 

사용자들이 패스워드가 변경된것을 눈치채지 않게 하기 위해 META 태그 중 "Refresh"를 추가적으로 사용하여 정상 페이지로 바로 돌린다면 쉽게 눈치채기 어렵습니다.

---

대표적으로 과거 "옥션"에서 발생한 약 1800만 명의 개인정보 유출 사건에서 공격된 기법 중 하나로 해당 "CSRF" 취약점을 사용해 높은 권한을 가진 계정들에게 코드가 삽입된 이메일을 사회공학적 기법과 융합하여 획득했었던 사건입니다.

 

위처럼 패스워드를 수정시킬 수 있는 방법도 존재하지만 이러한 방법 이외에도

(1) 무작위 게시글, 댓글 작성 
(2) 상품 주문 및 결제까지 연계
(3) 장바구니 및 위시리스트 추가, 삭제 
등

특정 행위에 대한 모든 것들이 가능해질 수 있기 때문에 사이트를 운영하는 개발자 분들이라면 반드시 여러 측면을 고려하면서 구현 개발을 해야 됩니다.

대응 방안

CSRF 취약점은 개개인의 안전한 인증체계를 거친다고 간단하게 막을 수 있는 취약점이 아닙니다.

어느 정도 사회 공장 학적인 기법도 사용되고 웹 애플리케이션 공격과도 연관이 있기 때문에 사용자의 행위에 대한 재검증을 하는 것은 물론이거니와 XSS, SQL 인젝션과 같은 입력 값 검증을 필수적으로 수행해야 됩니다.

POST기반 Referer 헤더 검증
 <!--동일 사이트에서 온 주소만 허용하고 그외에는 이전페이지로 돌리기-->
 &hhtp_host= getenv("HTTP_HOST");
 $referer     = getenv("HTTP_REFERER);
     if(!eregi ($http_host, $referer)) || $referer != "http://주소")
 {
	echo"<script>alert(\"접근이 잘못되었습니다.\"); history-go(-1)</script>";
     exit();

랜덤한 보안 토큰 생성
1.<!--행위가 이루어지는 페이지에 보안 토큰 코드 추가-->
<?
session_start();
$tokn=md5(uniqid(rand(),true));
$_SESSION['tokn']=$tokn;
...
?>
<form action='action.php' method='post'>
<input type=hidden name=toknvalue='<? echo $tokn?>'>

2.<!--보안 토큰이 POST 로 넘어오도록 구성-->
<?
session_start();
if(isset($_SESSION['tokn'])&&$_POST['tokn']==$_SESSION['tokn']){
....정상루틴수행....
}else echo "토큰 값 오류";
?>

사용자들이 입력하는 HTML 폼을 비활성 또는 입력값 검증
<!--발견된 문자를 지정한 문자로 변환-->
If($name=$_GET[‘ name’ ])
    $name=str_replace(“<”, “it,”, $name);
    $name=str_replace(“>”,”gt;”, $name);
    $name=str_replace(“=”,”equals;”, $name);
    $name=str_replace(“/”,”sol;”, $name);
    $name=str_replace(“;”,”semi;”, $name);
    $name=str_replace(“"”,”quot;”, $name);
    $name=str_replace(“+”,”plus;”, $name);
    Echo $name;

Crossdomain 접근 설정
 <!--허용하는 도메인 또는 IP만 접근하도록 설정-->
 <?xml version="1.0"?>
 <cross-domain-policy>
    <allow-access-from domain="*주소입력.com" />
    <allow-access-from domain="www.주소입력.com" />
    <allow-access-from domain="IP입력" />
 </cross-domain-policy>