(WebGoat) A2. Cryptographic Failures - Crypto Basics #1 Base64

WebGoat의 두 번째 도메인은 암호화와 관련된 내용이다.

여기서 다루어야 하는 내용은 후반부에 꽤 많은 내용이 있어, 나눠서 작성하려고 한다.

 

처음 이야기하는 부분은 인코딩과 관련된 내용이다.

 

Basic Authentication으로 전달되는 입력값을 통해 계정정보를 탈취하라는 퀴즈이다.

Authorization: Basic bXl1c2VyOm15cGFzc3dvcmQ=

 

Basic Auth는 계정정보를 암호화가 아닌 인코딩을 통해 전달하는 방법이기 때문에, 해당 인증값이 노출될 경우, 디코딩을 통해 계정정보를 확인할 수 있다. 간단히 해당 정보를 디코딩 해보면 예문에서 이야기 했던 계정정보와 똑같은 값을 확인할 수 있었다.

 

그럼 실제 문제로 나온 Basic Authentication을 동일한 방법으로 디코딩해보자.

 

 

나의 경우에는 현재 로그인한 계정명과 admin 이라는 패스워드가 사용되었던 것을 확인할 수 있었다.

 

 

소스코드를 확인해보니, 해당 페이지를 접근할 때 이미, BasicAuth와 관련되어 Password가 이미 설정되어 있었던 것 같다.

src/main/java/org/owasp/webgoat/lessons/cryptography/EncodingAssignment.java

 

페이지 접속 시 호출된 API

src/main/java/org/owasp/webgoat/lessons/cryptography/EncodingAssignment.java

 

그리고 이때 사용되는 패스워드는 5개 중 임의의 한개가 설정되는 것으로 확인되었다. 아마 이 포스트를 보고 따라하는 사람이 있다면, 내가 사용한 값이 그대로 보이지 않고 아래 패스워드 중 하나가 나타날 것이다.

src/main/java/org/owasp/webgoat/lessons/cryptography/HashingAssignment.java

 

 

 

위 문제를 통해 Basic Authentication의 위험성에 대해 확인할 수 있었다. 일반적으로 사용자 인증을 위해 Basic Authentication을 사용하게 된다면 본 퀴즈와 마찬가지로 디코딩을 통해 아주 쉽게 계정정보를 탈취할 수 있을 뿐 아니라, 인증을 위해 매번 계정정보를 전달해야 하므로, 계정정보 노출에 대한 리스크가 매우 높다. 때문에 일반적인 사용자 인증에서 Basic Authentication은 사용하지 않는다.

 

그렇지만 일부 서비스에서 Server-to-Server API 등을 제공할 때 다른 인증방식 제공 없이 오로지 Basic Authenticaion 만을 제공하는 경우가 있다. 이런 경우, 해당 서비스 제공 벤더와 협의를 통해 다른 안전한 인증방식을 사용해야 한다. 만약 이러한 협의가 불가능한 경우에는, 해당 인증값을 반드시 HTTPS를 통해 제공되어, 네트워크 구간에서 노출되지 않도록 다른 보안방안을 적용해야 한다.