Become a Good Analyst

Developer Tools의 두 번째 퀴즈는 Proxy 툴이 없을 때 간이적으로 패킷을 확인하기 위해 자주 사용하는 방법인 Network 기능을 이용하는 부분이다. 나 또한 개발자와 리뷰 미팅을 진행할 때, 자주 사용하는 크롬 기능이다. 해당 퀴즈는 Go 버튼을 눌렀을 때, networkNum 값을 확인인하여 제출하는 문제이다. 그럼 Go 버튼을 눌러보자. 그럼 Network 탭에는 해당 페이지에서 발생한 여러 패킷들을 확인할 수 있는데, 그 중 해당 버튼을 눌렀을 때 발생했던 패킷을 확인해보니, 지문에서 확인해야 한다고 언급한 networkNum 값이 전달되고 있는 것을 확인할 수 있었다. 실제 Proxy 툴에서도 해당 패킷이 그대로 전달되었던 것을 확인해보면 Developer Tool이 정확하고 패..

WebGoat의 General 항목의 세 번째는 Develop Tools 사용방법에 대한 내용이다. 특히 개발자들이 자주 사용하는 크롬의 개발자 툴을 자세히 이야기 해주고 있다. 해당 내용에서는 2개의 퀴즈가 존재하는데 순서대로 확인해보겠다. 첫 번째 퀴즈는 크롬 개발자 툴에서 Console을 이용하여 특정 스크립트 함수를 실행하고, 이를 통해 생성된 값을 확인하는 퀴즈였다. 여기서 우선 Submit을 눌렀을 때 어떻게 값을 확인하고 있는지 소스코드를 확인해보자 소스코드를 확인해보면, 입력값(successMessage)와 User Session에 저장된 randValue가 같은 값인지 확인하는 것을 알 수 있다. 이를 보면 어디선가 User Session에 randValue를 설정하는 코드가 있을 것을 ..

General의 두 번째 페이지에서는 본격적으로 Proxy 사용방법에 대해서 이야기 해주는 페이지이다. 특히 OWASP ZAP Proxy에 대한 사용방법을 상세하게 알려주고 있으니, Proxy 사용에 익숙하지 않은 분들은 이 페이지를 읽어보면 많은 도움이 될 것 같다. 나는 이미 Burp를 사용하고 있기 때문에, 빠르게 퀴즈 부분으로 넘어가 보았다. 해당 요청을 처리하는 함수 내용을 확인해보면 POST method인 경우, 요청을 실패했다고 응답처리 하고 있고, 다음으로 x-request-intercepted 라는 헤더값과 changeMe라는 파라미터를 가져와서 값이 Null 인지 여부를 확인하고 있다. 특히 헤더값는 true인지 여부와 changeMe는 “Requests are tampered easi..

WebGoat에 로그인하면 소개, 기본내용, 그리고 OWASP Web Top10과 관련된 실습내용을 확인할 수 있다. 이제 차례대로 하나씩 진행해보면서 WebGoat를 분석해 보고자 한다. 가장 먼저 General > HTTP Basics 을 확인해보면 Proxy를 이용하여 요청 및 응답을 확인이 필요하다고 하며, 응답값에 사용되는 HTTP Request 파라미터, 쿠키 등을 확인해보라고 이야기 하고 있다. 해당 내용을 확인하고 나면 간단한 퀴즈를 보여준다. 퀴즈는 현재 페이지에서 제공하는 요청기능에 대해서 어떤 HTTP Method를 사용하고 있고, 이때 Magic Number가 무엇인지 물어보고 있다. 해당 요청을 처리하는 Controller의 함수를 확인해보면, answer, magic_answer..

WebGoat에서 발생하는 요청/응답을 확인하기 위해 Proxy를 설정하고, Burp로 패킷을 확인하고자 하는데, WebGoat의 패킷을 확인할 수 없었다. 우선 기본적으로 WebGoat와 Proxy가 사용하고 있는 Port가 8080으로 동일했기 때문에, Proxy를 8888 포트로 변경하고, Burp에서도 Proxy listener를 새로운 포트로 설정하였다. Port를 변경하였으나 여전히 WebGoat의 패킷을 확인할 수 없었다. 여기서 문제는 WebGoat가 Loopback IP로 접근하였기 때문에, 기본적으로 Loopback IP로 접근 시 Proxy로 패킷이 전달되지 않는 것이 문제였다. 이런 경우, WebGoat를 Internal IP로 접속하면 되는 것을 확인하였으나, Internal IP..

WebGoat에서 사용 중인 UserDetailsService에서 User 정보를 조회가 가능할 때 리턴되는 엔티티 클래스 정보를 보면, ROLE은 2개로 구분되어 있는 것을 알 수 있다. 그렇지만 Spring Security의 보안필터 구성을 보면 요청에 따른 권한적용 여부가 포함되어 있지 않았으므로, 권한에 따른 기능을 분리하지 않은 것으로 보인다. Controller나 Service에서 유저의 권한을 확인할 수도 있기 때문에 ADMIN 권한으로 검색해보았지만 특별히 권한에 따라 기능 및 데이터를 제한하지 않는 것을 알 수 있다. 이후 기능 확인과정에서 Admin 서비스가 있거나, Admin 서비스로 분류가 필요한 기능이 확인된다면, 해당 서비스가 권한검증없이 기능 및 데이터가 제공될 수 있다는 것을..

서비스를 분석할 때 가장먼저 하는 것이 어떻게 인증이 처리되고 있는지를 보고 있다. 개발 프레임워크나 아키텍쳐에 대한 정보없이 코드리뷰를 하는 경우에는 Login이나 Auth 등의 키워드를 이용하여 정보를 수집하지만, 현재 WebGoat는 SpringSecurity를 사용하고 있기 때문에, @EnableWebSecurity 어노테이션을 검색하여 보안설정 정보부터 확인한다. 보안설정 파일에서 (1) Filter 적용, 보안구성의 보안필터 내용, (2) 사용자명을 검색하기 위한 UserDetailsService, (3) 패스워드 검증을 위한 PasswordEncoder 정보를 확인한다. 보안필터 내용을 확인해 보면, 어떤 요청에 대해서 인증이 필요한지 확인할 수 있다. 현재 WebGoat는 메인페이지, 리소..

WebGoat를 이용하기 위해서 회원가입 후 로그인 한 사용자에게 서비스를 제공하고 있다. 실제 회원가입은 상당히 다양한 보안 아키텍쳐가 고려되어야 한다. 구현방식에 따라 회원가입 기능을 통해 계정정보를 탈취하거나, 타인의 계정정보를 더 이상 사용할 수 없도록 할 수도 있다. 우선 WebGoat의 회원가입을 처리하는 서비스로직을 찾아보자. 현재 WebGoat에서 사용하는 회원가입 View URL은 "/registration" 이다. 코드를 확인해보면 실제 가입 프로세스 로직은 "/register.mvc"를 확인할 수 있다. 해당 로직을 보면, 전달받은 계정정보를 Validate 확인 후 특별한 에러가 발생하지 않는다면, 회원가입 처리를 완료 후 로그인하는 것으로 보인다. 그럼 validate 처리는 어떻..

인증받은 유저에게 서비스를 제공할 경우, 해당 세션은 탈취나 재사용 등을 통해 인증도용으로 사용되지 않도록 보안로직을 적용해야 합니다. 여기서 로그아웃 기능은 명시적으로 기능을 제공하여 유저가 더 이상 서비스를 이용하지 않았을 때, 세션이 바로 만료될 수 있도록 해야 합니다. WebGoat는 SpringSecurity를 사용하고 있고, 현재 로그아웃을 별도 로직을 구현하지 않고 로그인과 같이 또한 Spring Security에서 제공하는 기능을 사용하고 있습니다. 로그아웃 처리 과정에서 중요하게 보아야 하는 부분은 세션을 바로 만료처리하는지 여부입니다. 로그아웃 시 세션을 만료처리 하지 않는다면, 이미 세션ID가 탈취되어 재사용될 경우, 해당 세션은 아직 살아있기 때문에 기존 유저의 세션 인증 도용이 가..

WebGoat docker image를 실행하고 서비스에 접속하면 가장 먼저 로그인 기능을 확인할 수 있습니다. 애플리케이션 보안에서 가장 중요한 것은 역시 인증 및 인가이기 때문에, WebGoat에서 제공하는 취약한 코드외에 실제 로그인 과정에서는 어떠한 방식으로 구현되어 있고, 그 과정에서 인증을 우회할 수 있는 부분은 없을지 확인하였습니다.. Login 페이지에 대한 URL을 확인해보니, "/WebGoat/login" 이였습니다. 소스코드에 가서 /WebGoat/login 을 검색해보니 특별히 검색되는 코드가 존재하지 않습니다. "/WebGoat"는 Controller에서 공통으로 지정해 두었을 수도 있기 때문에 이번에는 "/login"으로 검색해 보았습니다, 검색되는 파일이 꽤 존재하는데 이 중에..