WebGoat - Insecure Direct Object References (IDOR)

첫 번째 문제 - Authenticate First, Abuse Authorization Later

첫 번째 문제를 번역기로 해석해 보니
접근에 대한 인증은 받은 상태지만 권한이 없는 사용자의 공격에는 취약하다. 이제 합법적으로 인증하는 것부터 시작하고, 그런 다음 권한을 우회하거나 남용할 수 있는 방법을 찾아보겠다.

이게 이번 문제들에 대한 핵심 같네요.

요약
1. 클라이언트는 특정 데이터 혹은 객체에 접근하려면 접근 권한이 필요하다.
2. 하지만 개발자가 접근제어를 미흡하게 구현해서 구멍이 생겼다.
3. 권한을 우회하거나 남용할 수 있는 방법을 찾아보자.

첫번째 문제는 이미 문제에서 답을 알려줬기 때문에 해당 ID와 PW를 입력해서 다음 문제로 넘어갈수있다.

두 번째 문제 - Observing Differences & Behaviors

두 번째 문제를 번역기로 해석해 보자면
AppSec의 공격적인 측면에서 일관된 원칙은 눈에 보이는 것에 대한 원시 응답과의 차이를 보는 것입니다. 즉, (이미 클라이언트 측 필터링 수업에서 언급했듯이) 원시 응답에는 화면/페이지에 나타나지 않는 데이터가 있는 경우가 많습니다. 아래 프로필을 확인하고 차이점에 유의하세요. 아래 텍스트 입력에서 서버의 응답에 있는 두 속성을 나열하지만, 프로필에는 위에 표시되지 않습니다.

요약
1. 화면에 보이는 값이 전부가 아니다.
2. 응답에 숨겨진 값을 찾아라.

Request

Rsponse

실제로 응답에 대한 답을 확인해 보니 View Profile을 눌렀을 때는 없던 숨겨진 값들이 존재하는 걸 볼 수 있습니다.

숨겨진 값
1. role
2. userId

응답에 숨겨진 값들을 넣어주면 다음으로 넘어갈 수 있습니다.

세 번째 문제 - Guessing & Predicting Patterns

세 번째 문제를 번역기로 해석해 보니

저희가 작업 중인 애플리케이션은 프로필에 이르기까지 RESTful 패턴을 따르는 것 같습니다. 많은 앱에는 상위 사용자가 다른 앱의 콘텐츠에 액세스할 수 있는 역할이 있습니다. 이 경우, 자신의 세션/인증 데이터가 누구의 프로필을 보고 싶은지 알려주지 않기 때문에 /프로필만 작동하지 않습니다. 그렇다면 직접 객체 참조를 사용하여 자신의 프로필을 명시적으로 볼 수 있는 패턴은 무엇이라고 생각하시나요?

자신의 프로필을 보려면 URL에 대체 경로를 입력하세요. 'WebGoat'으로 시작하세요 (즉, 'http://localhost:8080/'을 무시하세요)

요약
1. RESTful API는 REST 구조를 따르는 API로 HTTP URI Path를 통해 자원을 특정
2. 특정한 해당 자원에 대해 어떤 행동을 취할 것인지 HTTP Method로 정의
(GET - 조회, POST - 생성, PUT - 수정, DELETE - 삭제)
3. /profile 만으로는 '누구(who)'의 대한 프로필 정보가 부족하다
4. /WebGoat로 시작하는 URL을 작성해라

이번 문제는 패턴 추측과 예측해야 하는 것으로 보아 전에 풀었던 문제들을 생각해 보면서 문제에 접근해 보면 GET /WebGoat/IDOR/profile HTTP/1.1 요청을 통해 "Tom" 자신의 개인정보를 확인했다. 그렇다면 RESTful API는 특정 자원에 대해 요청할 수 있으니깐 우리는 더 자세하게 사용자 정보를 구분할 수 있는 값을 전달하면 특정 사용자를 조회할 수 있지 않을까? 앞서 두 번째 문제에서 "Tom"을 조회했을 때 나온 "userID" 값으로 요청한다면 어떻게 될까?

요청 메서드
WebGoat/IDOR/profile/2342384

"Tom"을 특정할 수 있는 값을 가지고 요청을 보냈더니 문제가 해결되었다.

네 번째 문제 - Playing with the Patterns

이번 문제를 번역기로 해석해 보자면

1. 이미 자신의 프로필을 볼 때 사용한 대체 경로를 사용하여 다른 사람의 프로필을 확인합니다. '프로필 보기' 버튼을 사용하여 요청을 가로채거나 수정하여 다른 프로필을 볼 수 있습니다. 또는 브라우저에서 수동 GET 요청을 사용할 수도 있습니다.

2. 기존 앱은 다양한 패턴을 따를 수 있지만, RESTful 앱(여기서 일어나는 일)은 종종 다른 기능을 수행하기 위해 방법을 변경하거나 본체를 포함하거나 포함하지 않는 경우가 많습니다. 그 지식을 사용하여 동일한 기본 요청을 받아들이고, 그 방법, 경로 및 본문(페이로드)을 변경하여 다른 사용자(버팔로 빌)의 프로필을 수정하세요. 역할을 더 낮은 것으로 변경하세요(높은 권한 역할과 사용자가 보통 낮은 숫자이기 때문에). 또한 사용자의 색상을 '빨간색'으로 변경하세요.

요약
1. 첫 번째 문제는 View Profile을 통해 다른 사람의 정보를 확인해라
2. 두 번째 문제는 확인한 타인의 정보를 수정해라
ex) role 값은 낮게 변경, color 값은 빨간색으로 변경

Step 1 - 다른 사람 프로필 조회

Request

첫 번째 View Profile을 눌러보면 위와 같은 요청을 전달하게 되는데 URL 뒷부분에 보면 %7BuserId%7D 인코딩된 값을 볼 수 있는데 해당 인코딩 값을 풀어보면 {userId} 라는 걸 알 수 있습니다.
디코딩(Decoding) = 컴퓨터언어를 사람이 이해하기 쉬운 언어로 변환
인코딩(Encoding) = 사람이 이해하기 쉬운 언어를 컴퓨터가 이해하기 쉬운 언어로 변환
%7B -> ' { ' = 디코딩
%7D -> ' } ' = 디코딩
' { ' -> %7D = 이렇게 중괄호를 인코딩한 값들이 %7B, %7D 입니다.
그렇다면 뒷부분이 GET /WebGoat/IDOR/profile/{userId} 이런 값으로 요청한다는 뜻이니 뒷부분에 userId값을 넣어서 다른 사람을 조회해 보면 될 거 같다.

userId - 2342388

userId값을 +1씩 증가하다 보니 해당 userId=2342388 값에 존재하는 다른 사람이 나오게 됩니다.

타사용자 Buffalo Bill 정보
{
role=3,
color=brown,
size=large,
name=Buffalo Bill,
userId=2342388
}
이제 다른 사람의 정보를 조회하는 데에 성공했으니, 마지막으로 수정을 수행해 봅시다.

Step 2 - Buffalo Bill 정보 수정하기

수정하기 위해서는 PUT메서드를 사용하면 됩니다. 수정할 정보는 role, color 값을 문제에서 제시했던 role은 낮게 3->2, color는 brown->red로 바꿔주면 되겠습니다. 전달할 값은 본문에 위치해서 보내주면 됩니다.

중요

여기서 중요한 점은 요청으로 보낼 본문의 타입입니다. 어떤 형태로 값을 보내야 하는지 가장 중요합니다. 본문에 수정할 정보가 어떤 형태인지 모른다면 제대로 수정이 이루어질 수 없을 겁니다. 지금까지 우리는 요청을 보낼 때 응답에서는 Content-Type: application/json 라는 헤더로 해당 문서의 타입이 json형식으로 보내고 있음을 확인할 수 있습니다. 이걸 토대로 우리도 수정을 요청할 때는 본문에 수정을 원하는 값들을 보낼 텐데 이 값들의 형식이 json형식으로 보내면 되겠다는 것을 유추해 볼 수 있습니다.

피드백을 보니 "거의 가까이 근접했다. 현재 role 값을 더 낮춰라"라고 한 걸 보니 role 값을 1로 수정해서 다시 요청해 보겠습니다.

role 값 수정

role 값을 2->1로 수정하였습니다.

결과

role 값을 1로 수정한 응답을 확인해 보니 피드백에서 "잘했다, 너는 다른 사람의 프로필을 수정했다." 하고 결과물이 잘 바뀐 것을 확인할 수 있습니다.

마무리

이번 실습은 개발자의 미숙한 처리로 인해서 발생하는 IDOR(Insecure Direct Object References) - "불안정한 직접 객체 참조"가 가능했을 때 생기는 문제점들을 다뤘습니다.

긴 글 읽어주셔서 감사합니다.