WebGoat 분석 - Authentication

서비스를 분석할 때 가장먼저 하는 것이 어떻게 인증이 처리되고 있는지를 보고 있다.

개발 프레임워크나 아키텍쳐에 대한 정보없이 코드리뷰를 하는 경우에는 Login이나 Auth 등의 키워드를 이용하여 정보를 수집하지만, 현재 WebGoat는 SpringSecurity를 사용하고 있기 때문에, @EnableWebSecurity 어노테이션을 검색하여 보안설정 정보부터 확인한다.

 

 

보안설정 파일에서 (1) Filter 적용, 보안구성의 보안필터 내용, (2) 사용자명을 검색하기 위한 UserDetailsService, (3) 패스워드 검증을 위한 PasswordEncoder 정보를 확인한다.

 

보안필터 내용을 확인해 보면, 어떤 요청에 대해서 인증이 필요한지 확인할 수 있다.

WebSecurityConfig.java

 

현재 WebGoat는 메인페이지, 리소스, 플러그인, 회원가입 등의 요청에는 보안요구 없이 요청을 허용해주고, 그외 나머지 요청에 대해서는 모두 인증된 사용자에게만 요청을 허용해주도록 구성되어 있다.

특별히 권한이 필요로 하는 페이지가 보안요구 제외 목록에 포함되어 있지는 않는 것으로 보인다.

 

다음으로 유저의 인증 과정에서 UserDetailsService가 어떻게 Username을 확인하고 있고, PasswordEnoder가 어떻게 패스워드를 검증하는지 확인해 보아야 한다.

 

UserDetailsService를 설정하기 위한 configure( or configureGlobal) 메서드를 확인해보니, UserDetailsService를 상속하는 UserService 클래스가 사용되고 있는 것을 알 수 있다.

WebSecurityConfig.java

UserService.java

 

UserService에서 유저정보를 검색하기 위해 loadUserByUsername을 재정의하고 있으며, 해당 코드에서는 데이터베이스를 통해 정보를 조회하고 이때 JPA를 사용하고 있는 것을 확인할 수 있다.

또한 유저조회 과정에서 다이나믹쿼리가 사용되지 않고 있기 때문에 쿼리변조를 통한 인증우회가 불가능한 것을 알 수 있다.

 

다음으로 패스워드 검증을 위한 PasswordEncoder 설정을 확인해보면, NoOpPasswordEncoder가 사용되고 있는 것을 확인할 수 있다.

WebSecurityConfig.java

 

NoOpPasswordEncoder는 패스워드를 해시 처리하지 않고 인코딩만 적용되고 있기 때문에, 패스워드가 평문으로 데이터베이스에 저장되고 있는 것을 알 수 있다.

패스워드는 일반적으로 안전한 해시함수를 사용하여 저장되어야 하며, 이때 BCrypt 또는 PBKDF2를 사용하는 것이 안전하다.

SpringSecurity의 PasswordEncoder에서도 BCryptPasswordEncoder, Pbkdf2PasswordEncoder 등 의 안전한 해시 인코더를 제공하고 있다. 만약 BCryptPasswordEncoder를 사용할 경우 강도계수는 2^x 만큼 라운딩을 처리하고, 여기서 x는 32bit integer가 사용되므로, x는 4~31 사이의 숫자가 사용되어야 한다.

 

이제 정상적으로 인증된 사용자에게는 SecurityContext를 통해 인증된 유저의 엔티티 세부정보가 저장되어 있을 것이다.

이후 컨트롤러나 서비스에서 유저의 인증여부, 권한정보, 유저정보 등을 확인해야 할 때에는 SecurityContext를 통해 확인할 수 있다.

 

현재 SecurityContextHolder에서 특별히 모드가 설정되어 있지 않기 때문에 기본 모드인 MODE_THREADLOCAL로 설정되어 있을 것이며, 이 경우 각 스레드별로 Security Context에 각자의 정보를 저장하게 될 것이다. 애플리케이션에서 각 요청이 개별 스레드를 갖고 요청이 되기 때문에, 별도의 비동기 메서드 처리가 없다면, 유저의 인증정보가 공유되지 않고 각각의 유저 인증정보를 확인할 수 있을 것이다.