
첫 번째 문제를 번역기로 해석해 보니
2FA 비밀번호 재설정
인증 우회의 훌륭한 예로는 최근(2016년)의 예(https://henryhoggard.co.uk/blog/Paypal-2FA-Bypass) 가 있습니다. 그는 코드가 포함된 SMS를 받을 수 없었기 때문에 보안 질문이 포함된 대체 방법을 선택했습니다. 프록시를 사용하여 매개변수를 완전히 제거하고 승리했습니다.
요약
1. Paypal 웹 서비스의 발생한 인증 우회
2. 요청을 가로챈 뒤 그다음, 서버로 전송되는 데이터 중에서 보안 질문에 대한 답변 파라미터들을 완전히 삭제한 뒤 요청을 그대로 전송
3. 서버는 파라미터가 비어 있음에도 불구하고 이를 오류로 처리하거나 차단하지 않았습니다. 결과적으로 인증 절차를 그대로 통과

문제를 확인해 보니
비밀번호를 재설정했으나, 서비스 제공업체가 인식하지 못하는 지역이나 기기에서 접속을 시도했습니다. (예시 - IP가 다른 곳에서 로그인을 시도하면 발생) 이에 따라 본인 확인을 위한 추가 단계로 보안 질문(Security Questions)에 답해야 하는 상황입니다. 사용자는 현재 보안 질문을 어딘가에 백업해 놓거나 하지 않아 기억나지 않는 상황입니다.

임의의 값들을 넣어서 현재 요청에는 어떤 파라미터가 있는지 확인을 해보겠습니다.

먼저 문제에서 제시했던 방법대로 Paypal 보안 질문 우회에서 사용했던 요청을 가로챈 뒤 보안 질문을 제거하여 요청을 진행해 보겠습니다.

아쉽게도 보안 질문을 담은 파라미터인 secQuestion0, secQuestion1 을 제거한 후 요청을 시도해도 문제는 해결되지 않았습니다. 공격 결과로 보아 Paypal에서 시도했던 방법과는 조금 다른 거 같습니다. 그러면 어떻게 우회를 할 수 있을까요?


답은 생각보다 간단했습니다. secQuestion0, secQuestion1 파라미터를 secQuestion2, secQuestion3으로 수정해 요청을 보내면 문제를 해결할 수 있습니다.
이번 실습 문제는 개발자가 보안 질문 파라미터에 대한 검증을 제대로 하지않은 경우에 발생한 문제인 거 같습니다. 개발할 때 secQuestion파라미터가 2개 존재하는지에 대해서만 구현을 해놓아서 파라미터가 다르게 변경되어도 secQuestion파라미터가 2개 있으면 이를 진행하게 두어서 생긴 문제 같습니다. 만약 간단하게 보완한다고 하면 secQuestion파라미터명이 정확할 때만 다음으로 진행되게 해야 할 거 같네요.