WebGoat A1_IDOR

실행 후 가장 첫 화면은 IDOR에 관해 설명하는 화면이 나온다. IDOR은 Insecure Direct Object References의 약자로, 웹사이트가 클라이언트의 데이터에 접근할 때 발생한다.

위의 예시들과 같이 url에 사용자 정보를 그대로 받아들이고, 그 사용자에 대한 검증을 하지 않는 경우 등에 발생한다.

 

이는 데이터를 단순히 보는 것을 넘어, 타인의 데이터를 수정하거나 삭제하는 행위로까지 확장될 수 있는 심각한 문제로 이어질 수 있기에 항상 검증을 해야한다.

 

 

문제로 넘어가면 위와 같은 화면이 나온다. 위 페이지는 그냥 취약한 앱에 로그인하는 과정이다. 알려준대로 user에 tom을 적고 pass에 cat을 적으면 된다.

 

다음 페이지에는 가공되지 않은 응답 데이터와 화면에 실제로 보이는 것 사이의 차이를 살펴보는 단계이다. 화면이나 페이지에는 나타나지 않지만 서버가 보낸 원본 응답 데이터 안에는 포함되어 있는 정보를 확인한다.

버프스위트 프록시 인터셉트를 킨 후 프로필 버튼을 누르면 요청이 잡힌다. 이 요청을 repeater로 보내 응답을 보면 response에는 role과 userId가 추가로 보이는 것을 확인할 수 있다. 입력창에 role, userId를 입력하면 성공하게 된다.

 

다음 페이지는 관리자가 각 사용자마다의 정보를 보기위해서는 /profile이라는 주소만으로는 충분하지 않고, 추가적인 정보가 필요하다고 한다. 추가될 파라미터를 찾는 문제이다.

위의 버프스위트에서 프로필 정보를 불러오는 주소가 WebGoat/IDOR/profile 이었다. 그렇다면 뒤에 각 유저의 id를 붙인다면 유저마다의 정보가 나오지 않을까 싶다. 그래서 아까 찾은 tom의 userId인 2342384를 경로 제일 뒤에 붙였다. 제출을 하니 tom의 정보가 화면에 보였다.

 

 

첫 번째 문제는 다른 사람의 프로필을 확인하는 문제이다. 

 

repeater에서 Tom cat의 userId에서 하나씩 바꿔가며 요청을 보내보았다. Tom cat의 userId를 2342388로 올리니까 Buffalo Bill 이라는 사람의 정보가 보이면서 성공하게 되었다.

다음 문제는 다른 사람의 프로필을 바꾸는 것이다. 문제 설명은 오래된 애플리케이션은 각기 다른 패턴을 따를 수도 있지만, RESTful 애플리케이션(현재 다루는 앱)은 대부분 메소드만 바꾸거나하는 방식으로 서로 다른 기능을 수행하기 때문에 메소드, 경로, 본문을 변경해 다른 사용자인 Buffalo Bill의 프로필을 수정할 수 있다고 한다. 수정 사항은 권한(role)을 더 낮은 숫자로 변경하거나, 색상(color)을 red로 변경하는 것이다.

버프스위트의 프록시를 킨 다음 View profile 버튼을 누른 후, 받은 GET 메소드의 요청을 repeater로 보낸다. repeater에서 아까 보았던 tom의 데이터 형식인 JSON과 똑같이 JSON 형식의 Buffalo의 데이터를 뒤에 적고, color를 "red", role을 1로 바꿔주었다. 

그리고 데이터 수정을 요청하기 위해 GET을 PUT로 바꿔주고, 데이터의 종류가 JSON 형식의 데이터라는 것을 전하기 위해 Content-Type을 application/json으로 수정해주었다.

그 후 Send를 눌러보니 Buffalo의 role과 color가 바뀐 것을 확인할 수 있었다.

프록시 창으로 넘어와 아까와 같이 데이터를 수정한 다음, Forward 버튼을 눌러 보내주었다.

정보가 성공적으로 바뀐 것을 확인할 수 있다.