문제분석 & 풀이
admin이 입력된 폼이 있다.
제출하면 admin이 아니라고 뜬다.
개발자도구를 이용해서 코드를 봤지만 특이사항은 없는 것 같다.
admin이라고 써있는 값을 guest라고 바꿔서 전송을 해보니 "hello guest" 라는 문구가 뜨는 것을 확인할 수 있다.
개발자도구를 키고 쿠키를 확인하면 userid 라는 쿠키가 있다.
userid 쿠키의 값은 암호문 형태였다.
맨 끝 부분에 %3D가 있는 것을 토대로 url 인코딩이 됐다는 것을 알 수 있다. %3D는 url 디코딩하면 "="이다.
여기서 마지막에 "="이 붙은 것을 토대로 base64 인코딩 데이터라는 것을 알 수 있다. "="는 base64 인코딩 과정에서 패딩으로 사용되는 문자이기 때문이다.
쿠키값을 url → base64 디코딩 순서로 변환했다.
[그림]과 같이 나온다.
아직까지는 암호문 형태고 이 값이 userid를 의미한다. 아마도 처음에 입력한 guest와 관련된 의미를 내포할 것이다.
guest는 5자리이고 암호문의 길이도 160자리다.
160/5 = 32 자리가 나온다.
32자리는 md5 해싱 결과다.
즉, 의심해 볼 수 있는 것은 "guest" 각 자리마다 md5 해싱이 이뤄져서
32 * 5 = 160자리가 암호문이 됐다고 추측해볼 수 있다. (이 과정까지 도달하기위해서 여러가지 시도를 해봤다.)
확실하게 MD5가 맞는지 확인하기 위해 "g" 만 MD5로 해싱해서 userid의 앞 32자리와 매칭이 되는지 확인했다.
결과로 B2F5FF47436671B6E533D8DC3614845D 가 나왔으며 동일한 것을 알 수 있다.
그렇다면, userid가 암호화되는 과정을 다음과 같이 설명할 수 있다.
ex) admin
1. "admin" 각 자리를 MD5로 해싱한다.
2. 해싱결과를 소문자로 치환한다.
3. base64 인코딩한다.
4. url 인코딩한다.
5. 암호문 완성
순서대로 "admin"을 암호화해서 쿠키로 넣고 새로고침해보자.
