취약한 직접 객체 참조 공격

개요

"insecure Direct Object References"라고 불리며 대부분의 IDOR 취약점은 OWASP top 10의 A5 인 Broken Access Control 범주에 포함되어 있습니다. 서버 내부에 구현된 객체의 참조를 일반 클라이언트들 에게 허용하거나 노출시킬 경우 발생하는 취약점을 말합니다. DB를 참조하여 올바른 검증절차를 가지지 않으면 공격자는 허가 없이 직접 객체 참조를 하여 원하는 데이터 조작이 가능해집니다.

 

쉽게 얘기해 패스워드 변경, 초기화, 상품 구매 페이지에 구현되어있는 각각의 콘텐츠들이 서버 내부의 객체를 참조하지 않아 클라이언트가 보내는 값 ex) 상품 = 5000원 인 것을 상품 = 100 원으로 조작하여 이용이 가능해집니다.

 

공격포인트

(1) URL Prameter -> GET 방식으로 노출되는 변수 활용 또는 전달
(2) Body 영역에 포함된 매개변수 -> Body 영역에 노출되어있지 않다면 페이지 소스를 통해 유추
(3) html 소스

취약한 코드환경

  if(isset($_REQUEST["ticket_quantity"]))
{    
   if($_COOKIE["security_level"] != "2")
   {
     if(isset($_REQUEST["ticket_price"]))
       {
         $ticket_price = $_REQUEST["ticket_price"];
       }        
    }    
    $ticket_quantity = abs($_REQUEST["ticket_quantity"]);
    $total_amount = $ticket_quantity * $ticket_price;

ticket_price 값을 변조해서 보내도 올바른 요청인지 검증을 하지 않고 클라이언트 측에서 보낸 요청을 그대로 신뢰하고 있습니다.

안전한 코드 환경

 <form action= "/bWAPP/insecure_direct_object_ref_2.php" method= "POST">
  <p>How many movie tickets would you like to order? (15 EUR per ticket)</p>
  <p>I would like to order <input name= "ticket_quantity" value= "1" size= "2"
  type= "text"> tickets.</p>                    --> 취약할경우 ticket_price 매개변수를 노출시킴
  <button type= "submit" name= "action" value= "order">Confirm</button>
 </form>

매개변수에 ticket_price 가격을 드러낸 부분이 없습니다. 또한 서버 측에서 값을 받아와 DB에 전달될 때까지 사용자가 수정을 못하도록 대응하고 있습니다. 이외에도 임의의 토큰을 발행하여 상호 간에 인증절차를 한 번 더 거치게 되어도 방지할 수 있습니다.

 

테스트를 위해 취약 웹 어플리케이션 환경에서 진행해보았습니다.

 

현재 티켓 주문페이지에서 1개의 티켓당 15유로 정도의 가격으로 책정되어 있습니다. 페이지 소스코드를 확인해보면 ticket_price value = 15라는 코드가 확인되었습니다.

 

클라이언트가 보낸 요청을 그대로 신뢰하고 있으니 ticket_price=15라고 적혀있는 값을 " 1 " 로 변경해서 값을 1개 티켓의 값인 1유로로 조작할 수 있습니다.

 

성공적으로 1개의 티켓 가격을 1 EUR로 변경하여 주문할 수 있음을 확인하였습니다.

 

만약 개발자가 이러한 문제가 발생될 것을 미연에 방지하기 위해 ticket_price라는 매개변수를 body 영역에 포함시켜두지 않아 변수명 자체가 확인되지 못할 수도 있습니다.

 

하지만 html 소스 자체를 뒤지다 보면 body 영역에 포함시켜두지 않은 매개변수를 찾을 수 있고 찾은 변수를 그대로 뒤에 "&" 엠퍼센드 구분자로 추가하여 요청하면 값이 변경됩니다.

 

테스트했던 것처럼 상품의 금액을 조절할 수도 있지만, 이러한 점을 이용해 등록된 번호로만 인증이 가능한 환경에서 1회용 인증수단인 OTP의 수신번호를 원하는 번호로 조작하여 우회할 수 있습니다.

 

 

대응 방안(상단의 Secure SourceCode 참고)

(1) html 소스코드에 매개변수를 노출시키지 않도록
(2) 조작되면 안 되는 컨텐츠 영역은 모두 DB를 참조하여 올바른 값인지 비교하여 적용 (3) 값이 DB로 전달될 때까지 사용자가 수정을 못하도록
(4) 각 사용자들에게 값을 나눠준다면 token()을 부여하여 변조되지 않도록 유일 값 적용

OWASP top 10 범주에 속해있는 만큼 빈도수가 높은 공격 중 하나입니다.

 

국내 유명 쇼핑몰에서 실제로 발생했던 적이 있던 취약점입니다. 쇼핑몰을 확인해보면 가격 / 포인트 적용 / 할인% / 수량 등등 여러 값을 불러와 적용시키는 기능들이 많이 자리 잡고 있어 시도해볼 만한 포인트가 많습니다.

 

그렇기에 취약한 직접 객체 참조 취약점의 경우 어떠어떠한 공격이고 이런 피해가 발생한다.라고 정의 내리기에는 발생 가능한 범주가 너무 넓습니다.

사용자의 입력값을 받거나 보여주는 곳도 굉장히 다양하며 인증수단도 다양하기 때문입니다.

 

인증수단에 사용되는 변수라던가 루틴을 쉽게 노출해서는 안되고( 노출될 경우 공격자는 직접 객체에 참조가 가능한지 시도를 할 가능성이 높음 ) 기본적으로 2가지 의 인증수단을 적용해서 올바른 요청, 값이 맞는지 확인해야 됩니다.

 

개발단계에서도 이러한 각각의 영역에 대해 올바른 객체 참조를 하도록 DB에서 검증을 하는 것도 쉬운 일이 아닙니다. 하지만 이러한 문제를 예견하지 않고 조치를 하지 않는다면 대상 사이트는 큰 혼란에 빠질 가능성은 충분해 보입니다.