'Content-Type'에 해당되는 글 4건

  1. 2014.10.13 Apache HTTP Server 서비스 거부 취약점
  2. 2014.02.10 Apache Tomcat 서비스 거부 취약점 보안업데이트
  3. 2009.10.28 인코딩을 통한 XSS필터 회피 기술
2014.10.13 09:34

Apache HTTP Server 서비스 거부 취약점


아파치 소프트웨어 재단의 Apache HTTP Server에 영향을 주는 서비스 거부 취약점 발표[1]개요

  • 공격자는 HTTP 헤더를 특수하게 조작해 취약한 시스템에 요청할 경우, 서비스 거부를 유발시킬 수 있으므로 사용자의 주의가 요구됨


설명

  • HTTP 헤더의 ‘Content-Type’ 항목 값을 변조해 서비스 거부를 일으킬 수 있는 취약점(CVE-2014-3581)
  • modules/cache/cache_util.c의 cache_merge_headers_out 함수에서 부적절한 코드로 인한 서비스 거부 취약점 발생


해당 시스템

  • 영향 받는 소프트웨어
  • Apache HTTP 서버 2.4.10 및 이전 버전


해결방안

  • Apache HTTP 서버 2.4.10 및 이전 버전 사용자
  • Apache 소스코드 중 cache_util.c를 다운받아 컴파일 후 사용[2]


용어 정리

  • Apache HTTP Server : 아파치 소프트웨어 재단에서 개발한 웹 서버


기타 문의사항

  • 한국인터넷진흥원 인터넷침해대응센터: 국번없이 118


[참고사이트]
[1] http://secunia.com/advisories/61539/
[2] http://svn.apache.org/viewvc?view=revision&revision=1627749


Trackback 0 Comment 0
2014.02.10 20:17

Apache Tomcat 서비스 거부 취약점 보안업데이트


개요

  • 아파치 소프트웨어 재단은 Apache Tomcat에 영향을 주는 서비스 거부 취약점을 해결한 보안 업데이트를 발표[1][2]
  • 공격자는 HTTP 헤더를 특수하게 조작해 취약한 시스템에 요청할 경우, 서비스 거부를 유발시킬 수 있음


설명

  • HTTP 헤더의 ‘Content-Type’ 항목 값을 변조해 서비스 거부를 일으킬 수 있는 취약점(CVE-2014-0050)


해당 시스템

  • 영향 받는 소프트웨어
    • Apache Tomcat 7.0.0 - 7.0.50 버전
    • Apache Tomcat 8.0.0-RC1 - 8.0.1 버전


해결 방안

  • Apache Tomcat 7.x 버전 사용자
    • Apache Tomcat 버전을 7.0.51 버전으로 업그레이드
  • Apache Tomcat 7.x 버전 사용자
    • Apache Tomcat 버전을 8.0.2 버전으로 업그레이드


용어 정리

  • Apache Tomcat : 아파치 소프트웨어 재단에서 개발된 웹 애플리케이션 서버


기타 문의사항

  • 한국인터넷진흥원 인터넷침해대응센터: 국번없이 118


참고사이트

[1] http://tomcat.apache.org/security-7.html

[2] http://tomcat.apache.org/security-8.html


Trackback 0 Comment 0
2009.10.28 14:47

인코딩을 통한 XSS필터 회피 기술

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로 설정된 것을 볼 수 있다.

<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">

출처 : youngsam.kr

Trackback 0 Comment 0