securityproof.net에 올린 글입니다.

[Q]
web cache poisoning, cross user defacement, 사용자의 민감한 정보를 가지고 있는 페이지의 hijacking, 그리고 고전적인 cross-site-scripting과 같은 다양한 공격을 가능하게 하는 새로운 어플리케이션 공격 기법으로 알려져 있습니다.

HTTP Response Splitting이란 무엇인가요?

[A]
SP님 덕에 이런 방법의 존재를 알게 되었네요…

http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf

가 좋은 참고자료입니다.

간단하게 예를들자면, 아래와 같은 index.jsp 코드에서

$redirect_url = “/lang.jsp?lang=” + getParameter(“lang”);
redirect to $redirect_url

보면 lang이란 파라미터를 검사하고 있지 않죠.

그럼, lang에다가 일단 응답을 넣어주고, 다시 HTTP Response를 생성시켜넣으면 됩니다. 방법은,

/index.jsp?lang=eng%0d%0aContent-Length%200%0d%0a%0d%0aHTTP/1.1%20200%20OK…

과 같이 하는거죠.

그러면 응답이 생성될 때,
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 15:26:41 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=foobar
Content-Length: 0

HTTP/1.1 200 OK
…

이렇게 나가게 된다는 것이죠.

결국, 공격자가 response를 2개 생성할 수 있다는 것입니다. 이것을 사용한 cache-poisoning의 경우엔, 캐시하는 측(프록시던지 클라이언트 브라우저던지)에서 이 2개의 응답을 보게하는거죠. 그러면서, 공격자가 2번째 응답을 완전히 제어할 수 있으므로 2번째 응답을 조작해서 캐시의 expire 하는 시점을 먼 미래로 하는게 기본아이디어입니다.

보통은 redirect하는 코드는 전부다 취약할 수 있다고 봐야하고요. 꼭 redirect하는 코드가 아니더라도, 만약에 404같은걸 띄우면서 원래의 url을 출력해준다면 얼마든지 404 not found 페이지를 조작한다던가 하는게 가능해지죠…

한가지문제는 %0d%0a를 넣어서 줄바꾸기 하는 부분인데요. 만약에 %0d%0a가 필터링 되버리면 공격이 통하지 않죠. 이에대한 해결책으로 제시되는것이 utf-7 인코딩하는 방법입니다. utf-8이야 걸러질테니까요. 특히 IE의 경우엔 utf-7도 잘 처리가 되고 있으니 인코딩 대상으로 적절하고요..