다른 인증 메커니즘의 취약점
대부분의 웹사이트는 기본적인 로그인 기능 외에도 사용자가 계정을 관리할 수 있도록 다양한 추가 기능을 제공합니다. 예를 들어, 사용자는 일반적으로 비밀번호를 변경하거나 비밀번호를 잊어버렸을 때 재설정할 수 있습니다. 하지만 이러한 기능은 공격자가 악용할 수 있는 취약점을 내포하기도 합니다.
웹사이트들은 일반적으로 로그인 페이지에서 잘 알려진 취약점을 피하기 위해 주의를 기울입니다. 하지만 관련 기능 또한 마찬가지로 안전하게 보호하기 위해 필요한 조치를 취해야 한다는 사실을 간과하기 쉽습니다. 특히 공격자가 자신의 계정을 만들어 추가 페이지에 쉽게 접근할 수 있는 경우에는 더욱 중요합니다.
사용자 로그인 상태 유지
흔히 볼 수 있는 기능 중 하나는 브라우저 세션을 종료한 후에도 로그인 상태를 유지하는 옵션입니다. 이는 보통 "로그인 상태 유지" 또는 "로그인 상태 유지"와 같은 문구가 있는 간단한 체크박스 형태로 제공됩니다.
이러한 기능은 일반적으로 "로그인 상태 유지" 토큰을 생성하여 영구 쿠키에 저장하는 방식으로 구현됩니다. 이 쿠키를 확보하면 로그인 절차 전체를 우회할 수 있으므로, 쿠키를 추측하기 어렵게 만드는 것이 바람직합니다. 그러나 일부 웹사이트는 사용자 이름과 타임스탬프와 같은 고정 값을 예측 가능한 방식으로 조합하여 쿠키를 생성합니다. 심지어 비밀번호를 쿠키에 포함시키는 경우도 있습니다. 이러한 방식은 공격자가 자신의 계정을 만들 수 있는 경우 특히 위험합니다. 공격자는 자신의 쿠키를 분석하여 생성 방식을 추론할 수 있기 때문입니다. 생성 방식을 파악한 후에는 다른 사용자의 쿠키를 무차별 대입 공격하여 계정에 접근하려고 시도할 수 있습니다.
일부 웹사이트는 쿠키가 어떤 방식으로든 암호화되어 있으면 고정된 값을 사용하더라도 추측할 수 없다고 가정합니다. 제대로 암호화된 쿠키라면 가능할 수도 있지만, Base64와 같은 단순한 양방향 인코딩으로 쿠키를 "암호화"하는 것은 전혀 보호 효과가 없습니다. 단방향 해시 함수를 사용하는 적절한 암호화 방식조차도 완벽한 보안을 보장하지는 않습니다. 공격자가 해시 알고리즘을 쉽게 파악할 수 있고 솔트가 사용되지 않은 경우, 단순히 단어 목록을 해싱하여 무차별 대입 공격으로 쿠키를 탈취할 수 있습니다. 쿠키 추측에 대한 제한이 적용되지 않으면 이러한 방식으로 로그인 시도 횟수 제한을 우회할 수 있습니다.
공격자가 자신의 계정을 만들 수 없더라도 이 취약점을 악용할 수 있습니다. XSS와 같은 일반적인 기법을 사용하여 공격자는 다른 사용자의 "로그인 유지" 쿠키를 탈취하고 이를 통해 쿠키 생성 방식을 추론할 수 있습니다. 웹사이트가 오픈 소스 프레임워크를 사용하여 구축된 경우, 쿠키 생성에 대한 핵심 정보가 공개적으로 문서화되어 있을 수도 있습니다.

Burp가 실행 중인 상태에서 '로그인 상태 유지' 옵션을 선택 하고 본인 계정에 로그인하세요 . 이렇게 하면 stay-logged-in쿠키가 설정됩니다.


개발자 도구 패널에서 이 쿠키를 살펴보면 Base64로 인코딩되어 있음을 알 수 있습니다. 디코딩된 값은 wiener:51dc30ddc473d43a6011e9ebba6ca770입니다.


아래와 같은 방법으로도 디코딩할 수 있다.
(우: 디코딩을 지원하는 홈페이지, 좌: 버프 스위트 내 디코더)

이 문자열의 길이와 문자 집합을 분석해 보면 MD5 해시일 가능성이 높다는 것을 알 수 있습니다. 평문이 사용자 이름이므로 비밀번호의 해시일 가능성이 큽니다. 비밀번호를 MD5로 해시하여 이를 확인해 보세요. 이제 쿠키의 구조를 다음과 같이 알 수 있습니다.
base64(username+':'+md5HashOfPassword)
1. 문자열의 길이 (가장 결정적)
MD5로 만들어진 결과물은 어떤 입력값을 넣어도 **항상 128비트(bit)**의 고정된 길이를 가집니다. 이를 우리가 읽기 쉬운 16진수(Hexadecimal)로 표현하면 무조건 32글자가 됩니다.
비밀번호가 '123'이어도: 32글자비밀번호가 'this-is-a-very-long-password'여도: 32글자질문하신 51dc30ddc473d43a6011e9ebba6ca770를 세어보시면 정확히 32글자인 것을 확인할 수 있습니다.
2. 사용된 문자의 범위 (Character Set)
MD5는 16진수 값을 사용합니다. 그래서 결과물에 나타나는 문자는 다음으로 제한됩니다.
숫자: 0 ~ 9알파벳: a ~ f (또는 대문자 A ~ F)
만약 문자열에 g, h, z 같은 알파벳이 섞여 있다면 절대 MD5가 아닙니다. 하지만 51dc30...을 보면 숫자와 a부터 f 사이의 문자들로만 이루어져 있죠.
3. 문맥과 관습 (Context)
쿠키 구조: 웹 취약점 실습이나 오래된 시스템에서 쿠키에 사용자 정보를 저장할 때, ID:Password 형태를 많이 씁니다. 이때 비밀번호를 그대로 노출하지 않기 위해 가장 흔하게 쓰는 방식이 MD5입니다.빠른 연산: MD5는 암호학적으로는 이미 취약해서(충돌 공격 등) 실제 보안용으로는 잘 안 쓰지만, 단순한 값 비교나 무결성 확인용으로 여전히 많이 보입니다.
계정에서 로그아웃하고, 최근 GET /my-account?id=wiener요청 에서 stay-logged-in쿠키 매개변수를 강조 표시하고 Burp Intruder로 요청을 보내세요.

Burp Intruder에서 stay-logged-in쿠키가 페이로드 위치에 자동으로 추가된 것을 확인하세요. 비밀번호를 단일 페이로드로 추가하십시오.

페이로드 처리 항목에 다음 규칙들을 순서대로 추가하십시오. 이 규칙들은 요청이 제출되기 전에 각 페이로드에 순차적으로 적용됩니다.
해시값:MD5

접두사 추가:wiener:

인코딩:Base64-encode

'이메일 업데이트' 버튼 은 인증된 상태로 '내 계정 ' 페이지 에 접속했을 때만 표시되므로 , 이 버튼의 유무를 통해 쿠키 무차별 대입 공격에 성공했는지 여부를 판단할 수 있습니다.설정 사이드 패널에서 문자열이 포함된 응답을 표시하는 grep 일치 규칙에 Update email을 추가합니다. 공격을 시작합니다.

생성된 페이로드가 사용자 계정 페이지를 성공적으로 로드하는 데 사용되었음을 확인하십시오. 이는 페이로드 처리 규칙이 예상대로 작동하고 사용자 계정에 대한 유효한 쿠키를 생성할 수 있었음을 확인시켜 줍니다.

다음과 같이 조정한 후 이 공격을 다시 시도하십시오.
id요청 URL의 매개변수를 wiener대신 carlos로 변경하세요.
쿠키의 세션을 삭제하세요.
접두사 추가 규칙을 wiener:대신 carlos:로 변경하세요.

공격이 완료되면 실험 문제가 해결될 것입니다. 응답에 Update email이 포함된 요청은 하나뿐이라는 점에 유의하세요 . 이 요청의 페이로드는 Carlos의 계정에 대한 유효한 stay-logged-in 쿠키입니다 .


추가. 만약 카를로스가 안뜬다면 직접 홈페이지에서 설정할 수도 있다.


극히 드문 경우지만, 쿠키에 저장된 사용자의 실제 비밀번호가 해시 처리되어 있더라도 평문으로 유출될 가능성이 있습니다. 잘 알려진 비밀번호 목록의 해시 처리된 데이터는 온라인에서 구할 수 있으므로, 사용자의 비밀번호가 이러한 목록에 포함되어 있다면 해시 값을 검색 엔진에 붙여넣는 것만으로도 간단하게 복호화할 수 있습니다. 이는 효과적인 암호화에 있어 솔트의 중요성을 보여줍니다.
'웹 해킹 > portswigger' 카테고리의 다른 글
| 버프스위트를 이용한 웹 해킹, 인증 취약점: 다른 인증 메커니즘의 취약점:비밀번호 재설정 (0) | 2026.04.29 |
|---|---|
| 버프스위트를 이용한 웹 해킹, 인증 취약점: 다른 인증 메커니즘의 취약점: 오프라인 암호 크래킹 (0) | 2026.04.27 |
| 버프스위트를 이용한 웹 해킹, 인증 취약점: 2단계 인증(2FA, Two-Factor Authentication)의 취약점 (1) | 2026.04.23 |
| 버프스위트를 이용한 웹 해킹, 인증 취약점: 비밀번호 기반 로그인의 취약점 ② (0) | 2026.04.21 |
| 버프스위트를 이용한 웹 해킹, 인증 취약점: 비밀번호 기반 로그인의 취약점 ① (0) | 2026.04.02 |