
WebWolf를 통한 이메일 기능
먼저 간단한 과제를 수행하여 WebWolf로 이메일을 읽을 수 있도록 하고, 먼저 WebWolf를 시작하세요(여기를 참조하세요). 아래 재설정 페이지에서 username@webgoat.org 로 이메일을 보냅니다(@ 뒤에 있는 부분은 중요하지 않습니다). WebWolf를 열고 이메일을 읽고 이메일에 제공된 사용자 이름과 비밀번호로 로그인하세요.
요약
1. 비밀번호 재설정을 하여 username@webgoat.org 로 이메일을 보냅니다.
2. WebWolf를 열고 이메일에서 제공하는 사용자 이름과 비밀번호로 로그인해라.

비밀번호 재설정을 하기 위해서 먼저 로그인 아랫부분에 Forgot your password?을 클릭해 줍니다. 그러면 위와 같은 비밀번호 재설정을 위한 이메일을 입력하라는 필드가 나옵니다. 여기에는 해당 사용자의 계정으로 이메일을 작성하면 됩니다. @뒷부분은 아무 값도 상관없어 보입니다.

WebWolf를 새 탭에서 열어서 로그인해 줍니다. 메일에 들어가 보면 이메일이 하나 와있습니다. 해당 이메일을 열어보면 안에는 새로운 비밀번호가 평문으로 전달된것을 볼 수 있습니다.

재설정된 평문 비밀번호를 복사해서 문제를 해결할 수 있습니다.

두 번째 문제를 번역기로 해석해 보니
보안 질문
많은 웹사이트에서 비밀번호를 잊어버렸을 때, 회원가입 시 설정한 보안 질문에 답하도록 요청하곤 하는데 이는 과거부터 지금까지 여전히 보안상의 문제가 되고 있습니다. 대개 질문 목록이 고정되어 있고, 답변의 선택지가 제한적인 경우가 많기 때문입니다.
이 기능을 안전하게 사용하려면 사용자가 직접 질문을 만들고 답변도 직접 입력할 수 있어야 합니다. 그래야 사용자들이 서로 같은 질문을 공유하지 않게 되어 공격자가 예측하기 더 어려워집니다.
중요하게 기억해야 할 점은, 이러한 보안 질문의 답변 역시 데이터베이스에 비밀번호를 저장할 때와 동일한 수준의 보안 조치를 적용해야 한다는 것입니다. 만약 데이터베이스가 유출되더라도, 공격자가 보안 질문의 답변을 이용해 비밀번호를 재설정할 수 없어야 합니다.
최근 사용자들이 SNS에 너무 많은 정보를 공유하고 있어 보안 질문을 비밀번호 재설정에 활용하는 것이 점점 더 어려워지고 있습니다. (좋은 보안 질문에 대한 참고 자료: http://goodsecurityquestions.com/)
요약
고정된 질문의 위험성: 질문 목록이 정해져 있으면 공격자가 답을 추측하기 쉽습니다. 따라서 사용자가 직접 질문과 답을 생성하게 하여 예측 가능성을 낮춰야 합니다.
비밀번호와 동일한 암호화: 보안 질문의 답변은 비밀번호만큼 중요하므로, DB 저장 시 반드시 암호화(해싱 등) 처리를 하여 유출 시에도 보호되어야 합니다.
개인정보 노출 주의: SNS를 통해 개인 정보가 많이 공개되는 환경에서는 흔한 질문(출신 학교, 반려동물 이름 등)은 보안 수단으로서의 가치가 낮아지므로 주의가 필요합니다.

문제를 확인해 보니
사용자가 비밀번호 찾기 질문에 올바르게 답변하면 비밀번호를 찾을 수 있습니다. 하지만, 이 '비밀번호 잊음(Forgot Password)' 페이지에는 계정 잠금 메커니즘(Lock-out mechanism)이 없습니다. 계정 잠금 메커니즘은 질문에 대한 답변의 시도 횟수를 의미합니다. 예를 들면 계속해서 보안 질문을 틀리면 계정이 잠기면서 다른 방법으로 계정을 복구하여야 합니다. 그렇다면 이번 문제는 답변을 입력할 때 횟수 제한이 없으므로 무차별 대입 공격을 시도하면 좋을 거 같습니다.

문제에서 제시한 사용자의 이름은 webgoat이며 가장 좋아하는 색깔은 red라고 했으니, 비밀번호는 재설정을 한번 해봤습니다. 아래 메시지를 보니 너는 이미 webgoat로 로그인되어 있으니 다른 계정을 찾으라고 합니다.

webgoat와 red를 입력했을 때 요청에는 어떤 값이 담기는지 확인해 봐야겠습니다. 특이점은 보이지 않는 걸 보니 무작위 대입 공격을 한번 시도해 봐야겠습니다. 제가 왜? 무작위 대입 공격을 시도하려는 이유는 문제에서는 보안 질문을 고정된 질문의 형태(좋아하는 색깔)로 사용했습니다. 즉, 대답할 수 있는 답변이 어느 정도 정해져 있습니다. ex) black, green, white, blue…. 등등 그러므로 이와 같은 근거를 바탕으로 brute-force 공격을 시도해 보는 게 좋다는 생각을 한 겁니다.

이제 무작위 대입 공격을 하기위한 사전 준비를 해봅시다. 먼저 공격하고자 하는 사용자는 Tom으로 정했습니다. 꼭 Tom이 아니어도 상관없습니다. 그리고 무작위 대입 공격을 위한 범위를 지정해 줍니다. 우리가 무작위 대입 공격을 하려는 대상은 securityQuestion 파라미터입니다.

공격에 필요한 페이로드를 추가해 줍니다. add 버튼 옆에 공간이 하나 있죠? 몇 가지 안 되는 하나하나 수작업으로 색깔을 넣어줍시다. 색깔을 입력하고 add 버튼을 누르면 위에 사진과 같이 하나씩 쌓이게 됩니다.

공격이 끝나고 length를 기준으로 정렬을 해보았습니다.

해당 페이로드의 응답을 확인해 보니 문제를 해결했다는 피드백을 받았네요.

문제로 돌아와서 tom계정으로 좋아하는 색깔인 purple을 입력하면 해당 문제가 해결된걸 볼 수 있습니다.

세 번째 문제를 번역기로 해석해 보니
보안 질문의 문제점
보안 질문이 처음에는 괜찮은 인증 방법처럼 보일 수 있지만, 몇 가지 큰 문제점을 가지고 있습니다.
"완벽한" 보안 질문이란 타인이 맞히기는 어렵지만, 본인은 기억하기 쉬워야 합니다. 또한 답변이 변하지 않고 고정되어 있어야 합니다. 하지만 이 조건들을 모두 만족하면서 누구에게나 적용될 수 있는 질문은 사실상 거의 없습니다.
만약 보안 질문을 설정해야 한다면, 실제 사실대로 답변하지 않는 것을 권장합니다. 이 문제에 대해 더 자세히 알아보기 위해 간단한 과제를 준비했습니다. 아래 목록에서 흔히 쓰이는 보안 질문 중 하나를 선택해 보세요. 여러분이 고른 질문이 왜 생각보다 안전하지 않은지 그 이유를 보여줄 것입니다.
두 가지 질문의 문제점을 확인하면 이 과제는 완료된 것으로 표시됩니다.
요약
이상적인 질문의 부재: 보안 질문은 '추측 불가'와 '기억 용이성'을 동시에 만족해야 하지만, 실무적으로 이런 질문은 찾기 매우 어렵습니다.
답변의 진실성 지양: 보안을 강화하려면 질문에 대한 답을 실제 사실(예: 진짜 출신 초등학교 이름)이 아닌, 자신만 아는 별도의 암호처럼 설정하는 것이 안전합니다.
실습 목표: 제공된 공통 질문 리스트 중 2개 이상을 선택하여, 각 질문이 왜 공격자에게 쉽게 노출될 수 있는지(SNS 정보 수집 등) 그 이유를 학습하는 것이 목표입니다.

문제를 확인해 보니
보안 질문에서 사용되는 것이 무엇인지 나와 있는 거 같습니다.



이번 문제는 보안 질문에 대한 2가지 이상 문제점을 확인하면 해결이 가능한 문제입니다. 여러 질문을 한번 선택해 보시고 해당 질문은 왜 부적합한지에 대한 답을 아래 메시지를 확인하시면 좋을 거 같습니다.

네 번째 문제를 번역기로 해석해 보니
비밀번호 재설정 링크 생성하기
비밀번호 재설정 링크를 만들 때는 다음 사항을 반드시 확인해야 합니다.
무작위 토큰(Random Token)이 포함된 고유한 링크여야 합니다.
단 한 번만 사용 가능해야 합니다.
제한된 시간 동안만 유효해야 합니다.
무작위 토큰이 포함된 링크를 보내는 것은 공격자가 사용자 계정을 차단하여 웹사이트에 단순한 서비스 거부(DoS) 공격을 가하는 것을 방지합니다. 또한, 링크는 한 번만 사용할 수 있어야 공격자가 비밀번호를 다시 변경하는 것을 막을 수 있습니다. 타임아웃(만료 시간) 설정은 공격 가능 시간을 제한하기 위해 필수적이며, 활성화된 링크가 남아있는 것은 공격자에게 많은 기회를 열어주는 것과 같기 때문입니다.
요약
예측 불가능성 (Unique Token): 추측할 수 없는 무작위 토큰을 사용하여 공격자가 링크를 임의로 생성하거나 타인의 계정을 잠그는 행위를 방지합니다.
일회성 (One-time Use): 링크가 한 번 사용된 후에는 즉시 만료되도록 설계하여, 이미 노출된 링크를 통한 재공격을 차단합니다.
유효 기간 설정 (Expiration): 링크의 수명을 짧게 제한(예: 1시간 이내)하여 공격자가 정보를 가로채거나 악용할 수 있는 시간적 창구(Attack Window)를 최소화합니다.

문제를 확인해 보니
'Tom'(tom@webgoat-cloud.org)의 비밀번호를 우리가 원하는 것으로 재설정하고, 그 비밀번호를 이용해 Tom으로 로그인하라는 문제 같습니다. Tom은 항상 비밀번호 재설정 이메일을 받으면 그 즉시 비밀번호를 변경한다고 합니다.

일단 저의 계정으로 비밀번호 재설정이 오는지 확인을 해보겠습니다. 사용자계정@webgoat.org으로 보내시면 됩니다. 아래 메시지를 보니 해당 이메일로 전송했다고 합니다. 확인하러 가봅시다.

WebWolf로 로그인하고 mail에 들어가 보면 위와 같이 비밀번호 재설정을 위한 링크를 하나 던져줍니다. 링크를 클릭해 들어가 줍니다.

링크를 눌렀더니 오류가 나옵니다. 검색을 해보니 소스코드를 최신으로 변경해야 한다고 합니다.
주소 : https://raw.githubusercontent.com/WebGoat/WebGoat/refs/heads/main/src/main/java/org/owasp/webgoat/lessons/passwordreset/ResetLinkAssignment.java
해당 문제의 소스코드는 위에 주소에 있습니다.

명령어 : rm src/main/java/org/owasp/webgoat/lessons/passwordreset/ResetLinkAssignment.java
위에 명령과 같이 입력해서 기존의 소스코드를 지워주세요.

명령어 :
wget https://raw.githubusercontent.com/WebGoat/WebGoat/refs/tags/v2023.4/src/main/java/org/owasp/webgoat/lessons/passwordreset/ResetLinkAssignment.java
위와 같이 두 번째 명령어를 입력해 주세요. 새로운 소스코드를 받는 겁니다.

명령어 : mv ResetLinkAssignment.java src/main/java/org/owasp/webgoat/lessons/passwordreset/
이제 다운받은 소스코드를 원래 제자리로 이동해줘야겠죠? 위와 같은 명령어를 입력해서 옮겨주세요.

명령어 : ./mvnw spotless:apply && ./mvnw clean install -DskipTests && ./mvnw spring-boot:run
이제 적용한 파일을 업데이트 해줘야합니다 위의 명령어를 입력해주세요. 그리고 WebGoat를 다시 실행해 주세요.

다시 WebWolf로 돌아와서 이메일에 있는 링크를 눌러주면 위와 같이 정상적으로 나오게 됩니다.

주소를 확인해 보니 사용자를 쉽게 유추할 수 없는 값을 사용하여 공격자로부터 무작위 대입 공격으로 다른 사람의 비밀번호 재설정을 방어하고 있는 거 같습니다.

WebWolf에는 사용자의 요청에 관해서 확인할 수 있습니다. 그렇다면 이번에는 WebGoat에서 보내는 요청을 WebWolf로 바꿔서 요청하면 어떻게 될까요?

이번에는 한번 Tom의 계정으로 비밀번호 초기화 링크를 보내봅시다.

그다음 비밀번호 초기화를 중간에서 가로챈 다음 WebWolf에다가 요청을 보내보겠습니다.

역시 WebWolf에서는 사용자에 대한 요청을 기록하기 때문에 가로챈 요청을 WebWolf로 보내면 해당 사이트에서 사용자에 대한 요청으로 인지하고 이를 기록할 거라고 생각했습니다. URI 부분을 확인해 보면 우리가 처음 자신의 계정으로 초기화를 진행했을 때 링크를 통해 들어가면 나오는 알 수 없는 값에 대해서 알게 되었습니다. 즉, Tom의 비밀번호 초기화 요청을 가로채면 당연히 서버는 해당 사용자가 가지고 있는 고유한 이메일을 바탕으로 알 수 없는 값들을 만들었을 테고 서버는 이를 링크로 만들어서 재설정을 요청한 이메일로 메일을 보내게 될 것입니다. 그 링크가 바로 해당 사용자의 재설정 값에 해당하는 값이 들어있는 이번 문제의 핵심입니다.

처음에 우리의 이메일로 보낸 재설정 페이지를 다시 들어가서 이번에는 뒷부분에 사용자를 특정하는 알 수 없는 값을 지우고 Tom의 값으로 변경합니다. 그리고 비밀번호 1234로 재설정해 보겠습니다.

비밀번호가 성공적으로 변경되었다는 알림이 나왔습니다. 이제 문제로 돌아가서 확인해 보겠습니다.

재설정한 비밀번호로 Tom의 이메일로 로그인을 시도해 봤더니 로그인이 성공하면서 이번 문제가 해결되었습니다.
이번 실습에서는 비밀번호 재설정에 대한 방법들이 오히려 취약점을 만들어 공격에 당하는 문제들에 대해서 알아봤습니다.