[Normaltic 웹해킹 입문] 6주차 CTF 문제풀이 - Authentication Bypass

🔥 [웹 해킹 스터디] 6주차 과제: 문제 풀이 & 취약점 정밀 분석

저번 주 숙제였던 문제들을 먼저 풀고, 6주차 내용을 복습하며 진도를 나가보려 한다.
본격적인 풀이에 앞서, 노말틱 님의 말씀을 되새기며 시작한다.

"고민하는 시간을 아까워하지 말자. 문제가 안 풀리는 답답함을 견디고 즐기자.
정답이 있는 것에서 찾는 거면 쉬운 거다.
현실에서는 정답이 있는지 없는지도 모르고 찾아야 하기 때문에..."

그리고 이번 스터디의 핵심 목표! 단순히 문제를 푸는 것에서 그치지 않고, "왜 문제이고, 어떻게 고쳐야 하는가?"까지 고민해보았다. 아래 풀이와 함께 보안 대책을 정리한다.

---

1. [1] Session 탈취

계정과 함께 탈취한 세션 ID를 제공해주고 사용해보라는 문제다.

풀이 과정

1. 먼저 주어진 계정으로 로그인을 해보니 쿠키에 PHPSESSID가 할당된 것을 확인했다.

1. 이제 탈취했다고 가정된 세션 정보를 Repeater를 이용해 주입해 본다.
2. 기존 내 세션 ID를 지우고, 문제에서 준 세션 ID로 바꿔치기해서 Send!

결과: 바로 플래그 획득 성공!

🚨 왜 문제인가? (취약점 원인)
세션 고정(Session Fixation) 또는 세션 관리 미흡 취약점이다.
공격자가 이미 사용 중인(혹은 탈취한) 세션 ID를 입력했을 때, 서버가 이를 검증 없이 받아들이고 해당 세션의 권한을 내어주었기 때문이다. 즉, "아이디/비번"이 아닌 "세션 ID"만으로도 인증을 통과시켜주는 것이 문제의 핵심이다.

🛡️ 어떻게 고쳐야 할까? (대응 방안)

• 세션 재생성 (Session Regeneration): 로그인 성공 시점에는 반드시 session_regenerate_id() 등의 함수를 사용해 기존 세션 ID를 파기하고 새로운 세션 ID를 발급해야 한다.
• 세션 타임아웃: 일정 시간 동안 활동이 없으면 세션을 만료시켜야 한다.
• 중복 로그인 방지: 동시 접속을 제어하여 탈취된 세션의 효력을 제한할 수 있다.

---

2. [2] Get admin

일반 계정(doldol)을 가지고 관리자(admin) 계정 권한을 획득해야 하는 문제다.

풀이 과정

1. 로그인 후 Request 패킷을 잡아보았다.
2. 파라미터에 id=doldol 처럼 아이디가 평문으로 넘어가는 것이 보인다.

   

3. Repeater에서 doldol을 admin으로 수정해서 전송해 보았다.

결과: 엥? 진짜 된다. 세션 검증 없이 파라미터만 믿고 처리하는 듯하다.

🚨 왜 문제인가? (취약점 원인)
파라미터 변조(Parameter Tampering) 및 부적절한 인가(IDOR) 취약점이다.
서버는 클라이언트가 보낸 데이터(여기서는 id=admin)를 절대 신뢰하면 안 된다. 현재 로직은 사용자가 누구인지(세션)를 확인하지 않고, 단순히 "Request에 적힌 아이디"를 기준으로 권한을 부여하고 있다.

🛡️ 어떻게 고쳐야 할까? (대응 방안)

• 서버 측 세션 검증: 클라이언트가 보낸 파라미터가 아니라, 서버 세션(Session)에 저장된 사용자 정보를 기준으로 권한을 확인해야 한다.
• 파라미터 사용 지양: 인증과 관련된 중요 정보는 URL이나 Body 파라미터로 주고받지 않는다.

 

---

3. [3] Pincode Bypass

핵미사일을 쏘고 싶다는데 비밀번호가 걸려있다. 건덕지가 안 보여서 고민하다가 URL을 다시 들여다봤음

풀이 과정

1. 현재 페이지가 step 1, 2 등으로 구성된 것 같아 URL에서 힌트를 얻음.
2. 혹시나 해서 URL 뒤를 /step3로 강제 변경하여 접속을 시도했다.

결과: 정답! 인증 과정 없이 바로 다음 단계 페이지가 열려버렸다.

🚨 왜 문제인가? (취약점 원인)
강제 브라우징(Forced Browsing) 및 접근 제어 누락이다.
웹 애플리케이션은 사용자가 'step 2'를 정당하게 통과했는지를 확인해야 하는데, 단순히 URL만 알면 누구나 접근할 수 있게 페이지별 권한 검증이 빠져 있다.

🛡️ 어떻게 고쳐야 할까? (대응 방안)

• 페이지별 세션 체크: 모든 중요 페이지(step3 등) 진입 시, 서버단에서 "이 사용자가 이전 단계를 완료했는가?"를 세션 값 등을 통해 확인해야 한다.
• 순차적 로직 강제: 이전 단계의 성공 토큰이 없으면 접근을 거부하도록 로직을 짠다.

---

4. [4] Admin is mine (Response 변조)

GET 방식으로 로그인을 시도하는데 Location 헤더도 없는데 리다이렉트가 된다? 수상함을 감지하고 분석 시작.

풀이 과정

1. 소스코드를 보니 login.js가 있고, "서버에서 result: ok를 주면 index.php로 보낸다"는 로직을 발견.

   

   

   

2. 즉, 서버가 아니라 브라우저(클라이언트)가 페이지 이동을 결정하고 있다.Burp Suite > Intercept > Response Intercept 기능을 켠다.

   

3. 로그인 시도 후 Response 패킷을 잡아 fail을 ok로 변조하고 Forward!

   

4. 로그인 페이지로 튕겨져 나왔지만(admin으로 로그인되면 즉시 login.php로 가도록 설정), Proxy History를 자세히 보니 index.php의 Response 안에 플래그가 숨겨져 있었다.

결과: 속이려는 의도가 다분했던 문제. 보이는 화면이 다가 아니다. 클리어!

🚨 왜 문제인가? (취약점 원인)
클라이언트 측 검증 의존 및 정보 노출 취약점이다.
1. 인증 성공 여부를 자바스크립트(클라이언트)에 맡겨버리면, 공격자가 응답을 변조하여 우회할 수 있다.
2. 권한이 없는 사용자에게도(로그인 페이지로 튕겨내더라도) HTML 소스코드 안에 중요 정보(플래그)를 포함해서 보냈다.

🛡️ 어떻게 고쳐야 할까? (대응 방안)

• 서버 측 검증: 인증 및 리다이렉션 로직은 반드시 서버(PHP, JSP 등)에서 Location 헤더를 사용해 처리해야 한다.
• 정보 은닉: 권한이 없는 사용자에게는 아예 데이터를 전송하지 말아야 한다. (HTML 주석이나 숨김 태그도 안전하지 않다.)

---

5. [6] Pincode Crack (Brute Force)

4자리 핀코드를 맞추는 문제. 0000~9999까지 대입하면 뚫릴 것 같다.

풀이 과정

1. GET 방식으로 otpnum을 전달한다.

   

2. Burp Intruder는 무료 버전에서 너무 느리므로, Python 스크립트를 작성해 무차별 대입(Brute Force) 공격을 수행했다. (제미나이 형님 도움 😉)
3. 약 10,000개의 요청을 보내고, 응답 길이가 다르거나 성공 메시지가 뜨는 핀코드를 찾았다

결과: 핀코드를 찾아 로그인 성공!

🚨 왜 문제인가? (취약점 원인)
무차별 대입 공격(Brute Force) 취약점이다.
사용자가 비밀번호를 수천 번 틀려도 서버가 아무런 제재를 가하지 않기 때문에, 시간만 있으면 언젠가 뚫리게 된다.

🛡️ 어떻게 고쳐야 할까? (대응 방안)

• 계정 잠금 (Account Lockout): 5회 이상 실패 시 10분간 입력 차단 등의 정책을 적용한다.
• CAPTCHA 도입: 자동화된 봇(Script)이 입력을 시도하지 못하도록 캡차를 사용한다.
• 지연 시간(Time Delay): 인증 실패 시 응답 속도를 의도적으로 늦춰 브루트 포스 속도를 저하시킨다.

---

📝 마치며

이번 숙제를 통해 다양한 웹 취약점을 직접 뚫어보고, "왜 뚫리는지"를 분석해 보았다.
결국 핵심은 "클라이언트(사용자)가 보내는 데이터는 절대 믿지 말고, 모든 검증은 서버에서 해야 한다"는 것이다. 다음 글에서는 Login Bypass 문제와 6주차 복습 내용을 다뤄보겠다!