티스토리 뷰
Developer Tools의 두 번째 퀴즈는 Proxy 툴이 없을 때 간이적으로 패킷을 확인하기 위해 자주 사용하는 방법인 Network 기능을 이용하는 부분이다.
나 또한 개발자와 리뷰 미팅을 진행할 때, 자주 사용하는 크롬 기능이다.
해당 퀴즈는 Go 버튼을 눌렀을 때, networkNum 값을 확인인하여 제출하는 문제이다.
그럼 Go 버튼을 눌러보자. 그럼 Network 탭에는 해당 페이지에서 발생한 여러 패킷들을 확인할 수 있는데, 그 중 해당 버튼을 눌렀을 때 발생했던 패킷을 확인해보니, 지문에서 확인해야 한다고 언급한 networkNum 값이 전달되고 있는 것을 확인할 수 있었다.
실제 Proxy 툴에서도 해당 패킷이 그대로 전달되었던 것을 확인해보면 Developer Tool이 정확하고 패킷 요청 및 응답을 확인하는데 충분히 좋은 툴인 것을 알 수 있다.
그럼 여기서 확인한 값을 전달해보면, 해당 퀴즈도 통과한 것을 알 수 있다.
그럼 해당 퀴즈가 어떻게 구현되었었는지, networkNum이 어떻게 생성되었고 어떻게 검증되고 있는지 소스 기준에서 다시 한번 확인해보자.
우선 Go 버튼을 눌렀을 때 어떻게 networkNum을 전달했었는지 확인하기 위해 클라이언트 코드부터 확인해보면, Go 버튼을 클릭하면 스크립트를 통해 랜덤한 값을 생성한 뒤 hidden field에 저장해 두는 것을 알 수 있다.
또한 생성한 networkNum을 검증은 어떻게 하고 있는지 확인해보면, networkNum과 유저 입력값(num)을 모두 파라미터로 전달받아 두 값이 같은지 비교를 하고 있다.
이를 보면, 해당 퀴즈는 굳이 네트워크 패킷을 확인하지 않고, Go 버튼을 클릭 후 networkNum의 값을 Element 기능을 통해 확인할 수 있다.
또는 Proxy를 통해 number와 network_num 파라미터를 직접 동일한 값으로 변조하여 생성된 networkNum과 상관없이 퀴즈를 통과도 할 수 있을 것이다.
클라이언트에서 생성한 인증값은 위와 같은 두 가지 공격방법으로 우회가 되기 때문에, 이전 페이지에서 사용한 것처럼 User Session 데이터에 저장된 값을 활용하여 인증이 되어야 보다 안전하게 인증 로직이 구현될 것이다. 물론 이전 페이지의 기능은 생성한 인증값을 클라이언트에 리턴하고 있기 때문에 취약한 것은 동일하지만, 생성 후 응답값으로 클라이언트에 제공하지 않는다면 기본적인 인증로직으로 사용될 수 있을 것이다.
'Web Analytics > WebGoat' 카테고리의 다른 글
(WebGoat) A1. Broken Access Control - Hijack a session (0) | 2024.03.08 |
---|---|
(WebGoat) General - CIA Triad (0) | 2024.03.06 |
(WebGoat) General - Developer Tools #1 (0) | 2024.03.05 |
(WebGoat) General - HTTP Proxies (0) | 2024.03.02 |
(WebGoat) General - HTTP Basics (0) | 2024.03.02 |
- Total
- Today
- Yesterday