1.        크로스 사이트 스크립팅 (XSS Cross-Site Script )

2.        영향을 받는 환경

3.        취약점

4.        보안 검증

5.        대비 및 방어책

 

1.        크로스 사이트 스크립팅

 

공격명

피해 내용

위험성

XSS(Cross site scripting)

XSS 공격에 의해 일반 유저 및 관리자 악성코드 감염 가능

Cookie Sniffing 공격으로 접근한 유저 및 관리자 권한 획득 가능

//

 

XSS로 더 잘 알려진 크로스 사이트 스크립팅은 사실 HTML인젝션의 한 부분이다. 취약점은 콘텐츠를 암호화나 검증하는 절차 없이 사용자가 제공하는 데이터를 어플리케이션에서 받아들이거나, 웹 브라우저로 보낼 때마다 발생하여 XSS는 가장 잘 알려지고 가장 치명적인 웹 어플리케이션 보안 문제점이다.

XSS는 공격자가 희생자의 브라우저에 스크립트를 실행할 수 있게 허용함으로써 사용자의 세션을 가로채거나, 웹 사이트 변조, 악의적인 콘텐츠 삽입, 피싱 공격 행위를 할 수 있고, 악의적인 스크립팅을 이용해 사용자의 브라우저를 가로챌 수 있다. 이러한 악의적인 스크립트는 대개 자바스크립트를 사용하지만 희생자의 브라우저에 의해 지원되는 어떠한 스크립팅 언어로도 이런 공격을 받을 수 있다. 쿠키는 사용자 이름, 암호, 신용카드 번호 등의 중요한 정보를 텍스트 형태로 저장하기 때문에 접근이 쉽다는 문제점이 있어 웹사이트와 관련된 가장 큰 취약점으로 크로스 사이트 스크립트(XSS) 공격이다.

 

2.     영향을 받는 환경

모든 웹 어플리케이션 프레임워크들은 크로스 사이트 스크립팅에 취약하다.

 

3.     취약점

 잘 알려진 크로스 사이트 스크립팅의 세 가지 형태는 반사, 저장, 그리고 DOM 인젝션이다. 반사된 XSS는 악용하기 가장 쉬우며, 페이지는 사용자에게 제공된 데이터를 직접 사용자에게 다시 돌려 줄 것이다:

echo $_REQUEST['userinput'];

저장된 XSS는 악의적인 데이터를 파일, 데이터베이스 또는 기타 백엔드 시스템에 저장한 다음에 마지막 단계에 여과하지 않고 사용자에게 보여주는 것이다. 이것은 다른 많은 사람들이 개인으로부터 입력된 정보를 이용하는 CMS, 블로그 또는 공개 토론장과 같은 시스템에서는 매우 위험한 것이다.

DOM을 이용한 XSS공격들은 HTML 요소보다 사이트의 자바스크립트 코드와 변수들을 조작하는 것이다.

다른 한편으로 공격은 세 가지 방식을 모두 혼합하여 할 수 있다. 크로스 사이트 스크립팅이 위험한 것은 공격하는 방식이 아니라 공격이 가능하다는 것에 있다. 표준화 되지 않거나 예기치 못한 브라우저의 성향은 포착하기 어려운 공격 벡터를 이끌어 낼 수도 있다. XSS은 잠재적으로 이러한 브라우저에서 사용하는 어떠한 구성 요소를 통해서도 수행될 수 있다.

공격은 보통 강력한 스크립팅 언어인 자바스크립트에서 구현된다. 자바스크립트 사용은 공격자가 새로운 요소들(악의적인 사이트로 자격 증명을 유출하는 코드를 로그인 페이지에 추가한 것)을 추가하는 것을 포함하여, 어떠한 주어진 페이지나 내부 DOM을 조작하거나, 페이지가 보여지고 표현되는 방법을 삭제 또는 변경하는 것을 허용한다. 자바스크립트는 비록 오늘날 피해 사이트가 AJAX을 사용하지 않음에도 불구하고 전형적으로 AJAX 기술을 사용하는 사이트에서 사용되는 XmlHttpRequest 사용을 허용한다.

XmlHttpRequest를 사용하면 브라우저의 동일 소스 개시 정책을 우회할 뿐만 아니라, 희생자의 데이터를 악의적 사이트로 전달하거나 브라우저가 열려 있는 동안 복잡한 웜과 악의적인 좀비 생성이 가능하다. AJAX 공격은 위험한 크로스 사이트 요청 변조 (CSRF) 공격을 이행하기 위해 꼭 드러날 필요도 없고 사용자의 상호 작용을 필요로 하지 않는다.

 

4.     보안 검증

목표는 어플리케이션 안의 모든 매개변수들이 유효한지 또는 HTML페이지 안에 포함되기 전에 암호화되는지를 검증하는 것이다.

자동적인 접근방법: 자동화된 침투 테스트 도구들은 매개변수 삽입을 매개로 한 반사된 XSS를 탐지하는 능력은 있으나 지속적으로 XSS를 찾는 데는 종종 실패한다. 특히, 삽입된 XSS 벡터의 결과를 권한 확인을 통해 방어되고 있다면 더더욱 그렇다(예를 들어, 사용자에 의해 관리자가 나중에서야 볼 수 있는 악의적인 데이터를 입력 하였을 때 등).

수동적인 접근방법: 통합된 검증과 암호화 메카니즘을 사용한다면, 가장 효율적인 보안 검증 방법은 코드를 확인하는 것이다. 만약 분산하여 구현되어 있다면 검증을 하는데 상당히 많은 시간이 걸릴 것이다. 대부분의 어플리케이션의 공격 범위가 상당히 크기 때문에 테스트를 하는데 많은 시간이 걸린다.

5.     대비 및 방어책

1) 악의적 명령어 실행(XSS) 취약점
- 사용자 입력값에 대해 유효성 검증한다.
- <script>문자열이 들어오면 <xxscript>나 다른 문자로 변환한다.
- <script>라는 문자열을 입력받지 못하도록 필터링 설정한다.
- <script> 태그 외에 다양한 기법을 이용해 공격하기 때문에 필터링 할 것들을 정해서 막는 Negative 방식 보다 입력 가능한 문자만 정한 뒤 그 외 정의된 문자가 아닐 경우에 필터링을 제한 하는 Positive 방식이 더 효율적이다.

2) 취약한 세션 관리
-
인증정보는 Cookie보다는, Session을 사용하는 것이 안전하다.
- Cookie
를 사용할 경우 반드시 암호화하고 위/변조 여부를 체크한다.

3) 악의적 명령어 주입(SQL Injection)취약점
- 사용자의 입력값에 대해 유효성 검증한다.
-
싱글 쿼테이션()이나, 대시(-), 세미콜론(;)과 같은 특수문자를 입력하지 못하도록 설정
- 필터링 규칙은 자바스크립트와 같은 클라이언트 사이드 스크립트 언어로 작성하면 우회할 수 있으므로 반드시 JSP ASP와 같은 서버 사이드 스크립트 언어에서 필터링 룰 적용한다.

4) Java : <bean:write ...> 같은 Struts 결과값 방식을 사용해라. 또는 <c:out ...> 내에 기본적인 JSTL escapeXML="true" 속성을 사용해라. 중첩되지 않는 <%= ... %> 을 사용하지 않는다 (이것은 적당한 결과값 암호화 방식에서 벗어난다.).

5) .NET : MSDN으로부터 자유롭게 사용이 가능한 Microsoft Anti-XSS 라이브러리 1.5를 사용해야한다. 이 라이브러리를 사용하지 않고 요청된 대상: usename.Text = Request.QueryString ("username") 을 직접적으로 폼 필드 데이터에 할당하지 않는다. .NET는 자동적으로 암호화된 출력 데이터를 조정한다.

6) PHP: 출력값이 htmlentities() 또는 htmlspecialchars()를 통과하였는지 확인한다. 또는 곧 발표 될 OWASP PHP Anti-XSS 라이브러리를 사용한다. register_globals이 비활성되지 않았다면 비활성화한다.

 

* 참고 사이트

1.
악용될 있는 컨텐츠 개선 방법(CERT 제공)

  
http://www.cert.org/tech_tips/malicious_code_mitigation.html

2.
크로스 사이트 스크립트 관련 정보(위키피디아 제공)

  
http://en.wikipedia.org/wiki/XSS

3. XSS
컨닝 페이퍼(ha.ckers.org 제공)

  
http://ha.ckers.org/xss.html

 

출처 : owasp_top_10_2007_korean-sdonghwi.pdf

 

Posted by secu153

댓글을 달아 주세요