HTML 출력에 들어가는 Content-Type의 charset을 변조함으로써, XSS 공격에 사용되는 문자열이 XSS차단필터에 의해서 걸리지 않도록 하는 검사회피기술이다.
예를 들어서, 원래의 XSS 공격 문자열이 <script>alert("XSS")</script> 라고 하자. 그런데, XSS차단필터가 <script>와 같은 문자열을 차단하기 때문에, 이 공격은 성공할 수 없다.
그런데, 만약 서버의 응답 HTML의 Content-Type 선언에서 charset을 변경시킬 수 있다면, 이 XSS차단필터를 통과할 수 있다.
예를 들어, 아래와 같은 문자열은 XSS차단필터에서 보면, 전혀 의미가 없는 문자열일 뿐이다.
%A2%BE%BCscript%BEalert(%A2XSS%A2)%BC/script%BE
그렇지만, 위의 문자열을 US-ASCII charset으로 디코딩을 하면 전혀 얘기가 달라진다. US-ASCII는 7비트만을 사용하기 때문에, 위의 의미없어 보이는 문자열은 다시 원래의 XSS공격 문자열로 디코딩되어 사용자의 브라우저에서 실행될 수 있다.
이렇게 되는 과정을 조금만 더 살펴보자.
위의 문자 중에서 %BC를 2진수로 풀어보면, 10111100 이다. 그런데, US-ASCII에서 7비트만을 사용하므로, 최상위 1비트를 무시하면, %BC는 00111100으로 해석되고 이것은 >문자가 되는 것이다.
이 공격 방법은 현재 Internet Explorer에서 동작하는 것으로 확인이 된다. 그리고 서버의 응답에서 Content-Type 선언의 charset을 변경시킬 수 있어야만 한다.
이 공격 방법이 포스팅된 블로그의 실제 예제를 한번 살펴보자.
이 링크는 별 문제없고, 코드도 실행되지 않는다.
그런데, 이 링크에서 charset을 UTF-8에서 US-ASCII로 변경하게 되면 다른 결과를 보여준다. 소스보기를 해보면, Content-Type선언의 charset이 US-ASCII로 설정된 것을 볼 수 있다.
출처 : youngsam.kr
예를 들어서, 원래의 XSS 공격 문자열이 <script>alert("XSS")</script> 라고 하자. 그런데, XSS차단필터가 <script>와 같은 문자열을 차단하기 때문에, 이 공격은 성공할 수 없다.
그런데, 만약 서버의 응답 HTML의 Content-Type 선언에서 charset을 변경시킬 수 있다면, 이 XSS차단필터를 통과할 수 있다.
예를 들어, 아래와 같은 문자열은 XSS차단필터에서 보면, 전혀 의미가 없는 문자열일 뿐이다.
%A2%BE%BCscript%BEalert(%A2XSS%A2)%BC/script%BE
그렇지만, 위의 문자열을 US-ASCII charset으로 디코딩을 하면 전혀 얘기가 달라진다. US-ASCII는 7비트만을 사용하기 때문에, 위의 의미없어 보이는 문자열은 다시 원래의 XSS공격 문자열로 디코딩되어 사용자의 브라우저에서 실행될 수 있다.
이렇게 되는 과정을 조금만 더 살펴보자.
위의 문자 중에서 %BC를 2진수로 풀어보면, 10111100 이다. 그런데, US-ASCII에서 7비트만을 사용하므로, 최상위 1비트를 무시하면, %BC는 00111100으로 해석되고 이것은 >문자가 되는 것이다.
이 공격 방법은 현재 Internet Explorer에서 동작하는 것으로 확인이 된다. 그리고 서버의 응답에서 Content-Type 선언의 charset을 변경시킬 수 있어야만 한다.
이 공격 방법이 포스팅된 블로그의 실제 예제를 한번 살펴보자.
이 링크는 별 문제없고, 코드도 실행되지 않는다.
그런데, 이 링크에서 charset을 UTF-8에서 US-ASCII로 변경하게 되면 다른 결과를 보여준다. 소스보기를 해보면, Content-Type선언의 charset이 US-ASCII로 설정된 것을 볼 수 있다.
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
출처 : youngsam.kr
728x90
댓글