애드센스4



Java Runtime UTF-8 Decoder Smuggling Vector 보안 정보

http://www.securiteam.com/securitynews/5YP0E0AQ0W.html

여성구씨의 연구결과는 최근 외국에서 다양한 형태의 연구를 촉발하고, 지속적으로 인용되고 있는 듯...
UTF-7 XSS에 대한 블랙햇 발표자료에도 CVE-2008-2938이 인용되고 있고... ㅋㅋ...

인코딩 이슈는 재미있고 난해한 주제임에 틀림이 없다.
여성구씨가 아파치 톰캣 프로젝트에 해당 이슈에 대해 버그 리포트를 보냈을 때, 개발자가 이미 유사한 이슈가 얼마전 제기된 적이 있으며-아마 OuTian의 이슈를 지칭하는 듯-해당 문제들은 아마도 톰캣의 문제라기 보단 Java쪽의 버그이기 때문에 그쪽에서 해결해줘야 하지 않겠느냐는 응답이 온적이 있는 것으로 기억이 난다. 기억이 가물거리긴 한데...

물론 나중에 다양하게 논의하는 과정에서 톰캣의 문제인 것으로 판명은 났으나, 숙련된 톰캣 개발자도 해당 이슈가 유니코드처리와 관련된 Java쪽의 문제인지, 톰캣 자체 구현상의 문제인지 구분하기 어려울만큼 해당 주제는 난해하다.

위의 JRE UTF-8 decoder 발표 자료는 Java쪽의 인코딩 문제에 대한 집대성 자료로 손색이 없지만, 이 문제와 관련해 잊지말아야할 중요한 것은 Java만 해당 문제를 겪는게 아니라는 점이다. 인코딩을 처리해야 하는 모든 장비, Programming Language는 동일한 문제를 떠안고 있다.

예를 들면 http://shiflett.org/blog/2005/dec/google-xss-example 의 UTF-7 XSS 예제 코드를 보자. 2005년에 발표된 내용이지만, 여전히 해당 코드는 PHP에서 잘 돌아간다. Perl, Python, Ruby 등 다른 언어 역시 마찬가지다.

웹과 관련한 표준 쪽을 보면 이 문제와 관련해... 정말... 한숨이 나온다.

트랙백

이 글과 관련된 글 쓰기 (트랙백 보내기)
TrackbackURL : http://swbae.egloos.com/tb/1881292 [도움말]

덧글

댓글 입력 영역


애드센스7