WebGoat 분석 - 회원가입

WebGoat를 이용하기 위해서 회원가입 후 로그인 한 사용자에게 서비스를 제공하고 있다. 실제 회원가입은 상당히 다양한 보안 아키텍쳐가 고려되어야 한다. 구현방식에 따라 회원가입 기능을 통해 계정정보를 탈취하거나, 타인의 계정정보를 더 이상 사용할 수 없도록 할 수도 있다. 

 

우선 WebGoat의 회원가입을 처리하는 서비스로직을 찾아보자. 현재 WebGoat에서 사용하는 회원가입 View URL은 "/registration" 이다. 코드를 확인해보면 실제 가입 프로세스 로직은 "/register.mvc"를 확인할 수 있다.

RegistrationController

 

해당 로직을 보면, 전달받은 계정정보를 Validate 확인 후 특별한 에러가 발생하지 않는다면, 회원가입 처리를 완료 후 로그인하는 것으로 보인다. 그럼 validate 처리는 어떻게 진행이 되어야 하는지 확인해보면 아래 코드와 같다.

UserValidator

 

 

validate 처리는 계정명이 기존에 사용되고 있지 않는지 확인하고, 2번의 패스워드가 동일한 값인지 확인하는 부분만 존재하는 매우 간단한 계정정보 검증방법이다.

 

여기서 회원가입 프로세스를 통해 현재 가입된 사용자의 계정명을 탈취할 수 있다.

해당 로직에는 요청에 대한 특별한 요청횟수를 제한하고 있지 않기 때문에, Brute Force 공격을 통해 실제 존재하는 계정명을 대량으로 탈취가 가능할 것이다. 실제 계정정보 탈취 과정에서 존재하는 계정에 대해서만 탈취를 하게 될 것이기 때문에, 계정정보 탈취에 매우 유리한 정보를 제공하게 되는 것이다.

 

해당 기능에서는 일반적인 username을 계정명으로 사용하고 있기 때문에, 계정명에 대한 소유자 검증을 하지 않아도 된다. 그렇지만 만약 email이나 전화번호를 계정명으로 사용해야 한다면, 회원가입하려는 email 및 전화번호가 요청자의 소유인지 점유인증 과정이 함께 진행되어야 한다.

 

UserForm

 

계정정보 클래스를 보아도 패스워드 정책 적용 검증 또한 하지 않고 있다.

현재 WebGoat에서 사용하는 패스워드 정책은 단순히 패스워드의 최소/최대 길이에 대해서만 제한하고 있다. 이는 유저에게 간단하거나 유추가 가능한 패스워드를 사용할 수 있도록 하기 때문에, 계정명 탈취 이후에도 패스워드까지 쉽게 탈취에 이용될 수 있다.  공격자가 패스워드를 탈취할 수 없도록 하기 위해서는 안전한 패스워드가 사용될 수 있도록 패스워드 정책을 수립하고, 해당 정책이 적용된 패스워드인지 여부를 서버측 코드에서 검증 후 회원가입이 진행될 수 있도록 구성되어야 한다.

 

실제 계정을 등록하는 메서드를 확인해보자

UserService

 

해당 로직에서는 다시한번 계정명이 기존에 사용되는지 확인을 하고, 결과와 상관없이 회원정보를 저장처리 하고 있다. 해당 로직에서는 단순히 이벤트 추적을 위한 로그 성 데이터 기록으로만 활용되고 있는 것으로 보인다.

 

그런데 이전 로직에서 계정명이 존재하는지 확인하고, 다른 함수에서 계정정보를 저장하고 있다. 이는 데이터의 체크와 사용 시간의 차이에 의해 Race Condition이 발생할 수 있는 부분이 있다. 일반적인 취약점은 아니지만, 동일한 시간에 동일한 계정명으로 회원가입을 시도하게 되었을 때, 동일한 계정정보가 함께 저장될 수 있다. 이는 부인방지에 대한 리스크가 매우 커지기 때문에, 반드시 Race Condition을 고려하여 설계되어야 하며 그에 따라 보안개발이 적용되어야 한다. 되도록 단일 프로세스 및 Singleton 방식으로 구현되는 것이 좋을 것 같다.

 

마지막으로 실제 데이터를 저장하는 코드를 확인해 보자

WebGoatUser

 

계정정보 과정에서 패스워드는 안전한 해시 알고리즘을 사용한 일방향 암호화 후 저장되어야 한다. 그런데 현재 서비스에서는 특별히 패스워드를 해시를 하지 않고 저장하고 있다. 이는 DB에 접근 가능한 이용자 또는 내부 공격자 등에게 DB를 통해 계정정보가 노출되는 것을 방지하기 위해 다양한 컴플라이언스에서 이야기 하고 있는 부분이다. 패스워드 정보가 노출되는 것을 방지하기 위해서, SHA-256이상의 해시 알고리즘이 사용되어야 하며, 이 과정에서 PBKDF2 또는 Bcrypt와 같은 안전한 알고리즘이 함께 사용되어야 한다. 또한 해시 특성 상 해시 충돌을 최소화 하기 위해 salt 값을 적용하여 이러한 리스크를 회피해야 한다.

 

아마도 테스트를 목적으로 하는 서비스이니 만큼, 다양한 테스트 계정이 필요하므로, 회원가입 과정에서 패스워드에 대한 보안을 적용하지 않도록 설계된 것으로 보인다. 하지만 실제 서비스를 개발 및 제공하기 위해서는 위에서 언급했었던 보안 요구사항들을 적용하여 안전하게 구현되어야 할 것이다.