April 18, 2019

WebGoat write up(Insecure direct object references 4 Guessing & Predicting Patterns)

To comply with the rule, in this write up, some hints related to this challenge only will be mentioned.

룰을 준수하기 위해, 여기서는 챌린지와과 관련된 몇 가지 힌트만이 언급됩니다.

Guessing & Predicting Patterns
패턴 추측 및 예측.

View Your Own Profile Another Way
The application we are working with seems to follow a RESTful pattern so far as the profile goes. Many apps have roles in which an elevated user may access content of another. In that case, just /profile won’t work since the own user’s session/authentication data won’t tell us whose profile they want view. So, what do you think is a likely pattern to view your own profile explicitly using a direct object reference?

다른 방법으로 내 프로필 확인하기.
우리가 다루고 있는 이 어플리케이션은, 프로필 송·수신 시 RESTful 패턴을 따르는 것으로 생각된다. 많은 애플리케이션들이, 타인 정보에 접근할 수 있도록 하는, 권한 상승과 관련된 취약점을 가지고 있는데, 만약 이런 취약점이 있다면, 단순히 "/profile"이라는 주소만 사용해서는 개인 프로필을 볼 수 없다. 이는 세션이나 인증 데이터를 통해 어떤 프로필을 볼 것인지 명시하는 방식이 아니기 때문이다. 그렇다면, 직접 객체 참조를 통해 명시적으로 자신의 프로필을 보는 것은 어떤 패턴이라고 생각하는가?

the result of Insecure direct object references 4 Guessing & Predicting Patterns

By combining the "userId" with the private profile address that can be obtained from the previous challenge, specific user can be pointed out as expressed above. This is not the way to point users through session ID. If the session ID was used, it would have been developed so that users could be identified by accessing the same address, such as "/ profile".

이전 챌린지에서 확보할 수 있는 개인 프로필 주소와 "userId"를 조합하면 위와 같이 표현해서 특정 사용자를 지목할 수 있다. 이런 방식은 세션 ID를 통해 사용자를 지목하는 방식은 아니다. 세션 ID가 사용되었다면 "/profile"과 같이 동일한 주소에 접속해도 각 사용자를 구분할 수 있도록 개발되었을 것이다.