Insecure Direct Object References
1)
현재 로그인 된 계정 외에 다른 계정의 프로필을 보고, 이를 수정하면 되는 문제이다.
View Profile 버튼을 클릭했을 때 보내는 패킷이다. 현재는 이 패킷에 대한 응답으로 500에러를 보내고 있었다.
이번 섹션에서 나온 이론을 보면 프로필을 송수신할 때 Restful 방식을 따른다고 하였다.
그래서 일단 처음에 보냈던 요청 패킷 URL에서 userId 부분을 현재 로그인된 계정의 ID로 수정하여 보내보았고, 이번에는 에러 대신 실패 문구가 응답으로 왔다. 만약 세션 ID를 통해 사용자를 구분하는 것이 아니라면, 단순히 userId 부분을 브루트 포스 공격을 했을 때 다른 사용자의 프로필을 조회할 수 있을 것이다.
Intruder를 통해 userId 부분을 브루트 포스 공격을 하였고, userId가 2342388인 계정의 프로필이 조회되었다. 이제 이 프로필을 수정해보자. REST 방식에서는 PUT 메소드가 데이터의 조회 및 수정에 사용된다.
문제 상에서 아래 View Profile 버튼을 클릭했을 때 보내는 패킷을 인터셉트하여 위와 같이 수정했다. 프로필 수정을 요청하는 것이므로 PUT 메소드로 변경하고, userId를 조회했었던 다른 계정의 ID 값을 넣고, 바디 데이터로 json 형태의 프로필 데이터를 넣었다. 이 때 문제에서 요구한대로 role 값을 낮추고, color 값을 red로 변경했다. 물론 json 형태의 데이터를 보내는 것이므로 Content-Type 헤더 값도 json으로 변경해야 한다.
Missing Function Level Access Control
1)
웹 페이지 상에 드러나지 않고 숨김 설정 되어 있는 메뉴 항목을 찾아내는 것이 문제이다. 일단 개발자 도구로 소스를 살펴보기로 했다.
style 속성값이 none으로 되어 있는 div 태그를 발견했고, 그 아래에 리스트로 users, config 메뉴가 각각 있었다. 이 메뉴명을 입력하면 통과할 수 있다. 여기서 나온 url은 다음에 나올 문제에서 도움이 될 것이라는 메시지가 응답으로 표시된다.
2)
이전 문제와 같이 노출된 정보를 통해 현재 로그인된 계정의 해시값을 구하면 되는 문제이다.
일단 페이지 상에 이전처럼 숨겨져 있는 요소가 있는지 확인해보았지만 존재하지 않았다.
이전 문제의 정답이 이번 문제에 대한 힌트가 될 수도 있다는 메시지를 던져 주었기에 /config 페이지가 존재하는지 확인해 보았지만 404 에러를 리턴해주었다.
반면에 /users 페이지는 500 에러를 리턴해주었다. 이 페이지에 어떤 정보가 있을 것으로 예상되었기에 일단 Repeater를 통해 요청 패킷을 조작해보기로 했다.
원래는 GET 메소드로 요청 패킷을 보내는데, POST로 변경하니까 415 에러를 리턴했다.
415 에러 메시지는 클라이언트에서 보낸 데이터 형식을 서버에서 지원하지 않아 처리 거부에 대한 응답 코드였다. 서버에서 온 응답 패킷을 보면 accept 헤더가 application/json으로 되어 있었다.
Content-Type 헤더의 값을 application/json으로 하여 전송하니 400 에러 코드를 리턴했다. 요청 패킷을 보낼 때 무언가 더 데이터가 필요한 것으로 보인다. 일단 POST 메소드이기 때문에 바디 데이터도 추가해서 보내보았다.
빈 json 데이터를 추가해서 보내보니 200 정상 응답 코드를 리턴해주었다. 그렇다는 건 이 패킷을 통해 어떤 바디 데이터를 구성해서 보내주어야 서버에서 처리하여 리턴해줄 것이라고 예상할 수 있지만, /users url로 어떤 데이터를 보내야할지 추측해야했다.
경로가 /users이므로 사용자 계정에 관련된 페이지로 추측할 수 있는데, webgoat에 로그인할 때 요청 패킷에 보내는 아이디와 패스워드 파라미터명이 각각 usersname, password이었기 때문에 이 파라미터로 값을 지정해서 보내보기로 했다.
이번에는 응답 바디 데이터에 각종 정보가 리턴되었는데, role 파라미터에 사용자 권한으로 보이는 값이 설정되어 있는 것으로 보아선 계정 추가가 된 것으로 예상되어 입력했던 계정 정보로 로그인을 해보았다.
실제로 입력했던 계정 정보로 로그인을 해보니 로그인이 되었고, 계정 정보를 보니 Role에 User 라고 되어 있었다. 그렇다면, 관리자 권한도 있지 않을까 생각되었다.
이전에 받았던 응답 패킷을 참고하여 요청 패킷 바디 데이터에 role 파라미터 값을 추가했는데, 사용자는 WEBGOAT_USER 였기 때문에 관리자는 WEBGOAT_ADMIN이 아닐까 생각이 되어 이렇게 보내보니 정말 그런 권한이 부여된 계정이 생성되었다고 리턴 패킷을 보내주었다.
해당 계정으로 로그인하면 권한이 admin으로 부여되어 있음을 알 수 있다.
이제 /users 페이지로 접근하면 어떤 정보들이 노출될 것이라고 생각했지만, 에러 페이지는 그대로였고, 찾아보니 최신 버전(8.1.0)에서는 해당 페이지에 대한 접근이 오류로 인해 정상적으로 풀이가 되지 않는다고 한다... 따라서 버전을 다운그레이드해서 다시 시도해보았다.
원래 /users 페이지는 위와 같이 사용자 권한을 가진 계정은 WebGoat에 등록되어 있는 계정수를 알려주고 있었다. 이전처럼 admin 권한을 부여한 계정을 생성해서 다시 로그인 해보았다.
admin 권한을 가진 계정으로 로그인한 후 /users에 접근하면 위와 같이 해쉬값을 구할 수 있게 된다.
