말도많고 탈도많은 쿠키!! 어떻게 사용하면 잘사용 하는걸까요?
앞으로 나오는 document.cookie등은 자동으로 "no_"앞에 가 붙습니다
Unicorn3에서 보안상 필터링하게 되어있기 때문입니다 앞에 "no_"가 없는것으로 간주하시면 됩니다
① 쿠키취약점
쿠키로 인증하는 사이트에 접속하여 로그인한 후 쿠키값 확인을 해봅니다
로그인 하지 않은 상태라면 다음과 같이 세션 아이디만 나오게 되며
로그인 한 상태라면 다음과 같이 쿠키이름과 쿠키값을 쌍으로 정보가 출력됩니다
관리자 아이디가 goodbug 라고 가정하고 이 아이디로 조작하기 위해서는 다음과 같이 입력합니다
그럼 프롬프트창이 하나 나타나며 이 부분에 다음과 같이 입력합니다
어떤 쿠키이름이 아이디를 나타내는 것일까요?
몇가지 없으니 가장 유력한 이름부터 하나씩 해보면 됩니다
다시 javascript:alert(document.cookie) 를 통해 쿠키값을 확인합니다
UID가 goodbug로 변경이 되었습니다
즉 내계정을 통해 goodbug로 로그인한것과 동일한 효과를 가져왔습니다!!
만약 쿠키로만 인증하는 방식이라면 타계정의 접속이나 관리자 화면으로 쉽게 들어갈 수 있습니다
② 쿠키를 이용한 SQL Injection
쿠키를 이용하여 일반 로그인 화면이나 관리자 화면을 통화할 수 있습니다
SQL Injection이 어느정도 알려졌기 때문에 로그인 폼으로 부터 넘어온 아이디나 비밀번호 정보들을
일정 값들로 치환하는 경우를 볼 수 있습니다
즉 '나 ", -, \ #등의 SQL Injection에 활용되는 문자들을 무력화 시키곤 합니다
하지만 이역시 쿠키 SQL Injection을 통해 간단히 통과할 수 있습니다
마찬가지 방법으로 자신의 계정으로 로그인 하여 쿠키를 생성 한 후 다음과 같이 값을 변경합니다
관리자 화면은 화면마다 아이디를 이용해 인증을 할것입니다
하지만 이 관리자 아이디를 쿠키로 읽어온다면 아마 많은 허점이 생길겁니다
보통 쿠키로 부터 읽어온 값은 '나 --등은 체크하지 않죠
그래서 인증 관련된 부분은 항상 "특정문자를 치환+Statement" 보다는 "PreparedStatement"를 사용해야 합니다
③ 쿠키취약점 보안 및 결론
-. 쿠키에 값을 구울때는 그 값을 "암호화" 하여 저장하고, 다시 읽어올때는 "역암호화"하여 사용합니다
-. 로그인시에 IP도 쿠키에 같이 구워버리고, 데이터베이스에도 저장하며, 항상 실제 아이피와 비교하여 사용합니다
-. 쿠키는 웹서버가 클라이언트에 남겨놓은 정보입니다
그래서 쿠키는 클라이언트가 마음대로 조작하는것이 가능하기때문에 서버는 어떤일이 일어나는지 검사해야 한다는 것입니다
ps. 대형사이트에서는 IDS에 걸릴수 있으니 주의하세요
=============================================
본문서는 자유롭게 배포/복사 할수 있지만
이문서의 저자에 대한 언급을 삭제하시면 안됩니다
저자 : GoodBug (unicorn@jakartaproject.com)
최초 : http://www.jakartaproject.com
=============================================
