A3 – 크로스 사이트 스크립팅 (XSS): Stored XSS, Reflected XSS, DOM based XSS, 예방법, 예상 피해
A8 – 크로스 사이트 요청 변조 (CSRF)
1. XSS (Cross Site Scripting)
- 정의
XSS는 어플리케이션에서 브라우저로 전송하는 페이지에서 사용자가 입력하는 데이터를 검증하지 않거나,
출력 시 위험 데이터를 무효화 시키지 않을 때 발생한다. (OWASP 참조)
즉, 공격자가 브라우저에서 실행될 수 있는 악성 스크립트를 웹 서버에 삽입했고, 사용자가 이를 요청해 자신의 브라우저에서 실행되게 될 때
중성화 시키지 않음으로써 발생하는 공격을 의미함.
- 웹 사이트에 악성 스크립트를 포함할 수 있는 쉬운 방법으로 많이 선호되며, OWASP Top 10 2013에서도 3번째로 높은 위험으로 랭크되어 있음.
- 조직 내에 다양한 보안 솔루션이 도입됨에 따라 공격자는 사용자의 합법적인 인터넷 이용을 악용하는 공격 방식으로 공격방법을 변경함.
- 사용자가 정상적인 웹 사이트에 접속하거나 웹 메일을 읽는 과정에서 공격자가 심어놓은 악성 스크립트가 읽혀지게 되어
PC의 오작동, 정보 탈취 등이 일어나게 함.
- XSS 공격은 HTTP 프로토콜을 사용하는 과정의 취약점을 이용한 것으로써 웹 서버로부터 클라이언트(웹 브라우져)에게 전달되는 데이터에
악성 스크립트가 포함되어 사용자의 클라이언트에서 실행되면서 사용자가 공격을 당하게 하는 것.
이 때의 악성 스크립트는 공격자가 미리 웹 서버에 삽입해논 것임.
* HTTP 프로토콜
클라이언트(웹 브라우져)가 웹 서버로 요청하면, 웹 서버는 요청을 분석하여 요청된 자원(서버에 있는 이미지, HTML 문서, 스크립트 등)과 헤더를 클라이언트에게 응답하는 과정을 위한 표준 규약.
- 보통 자바스크립트에서 발생하지만 VB 스크립트, ActiveX 등 클라이언트에서 실행되는 동적 데이터를 생성하는 모든 언어에서 발생이 가능 함.
- 종류: Stored XSS, Reflected XSS, Dom based XSS
2. Stored XSS
- 공격자가 웹 서버에 악성 스크립트를 포함하는 페이지(게시글, 사용자 프로필, 댓글 등)를 미리 저장해 놓고,
이를 클라이언트가 요청하면 전달하여 클라이언트가 실행하는 과정에서 공격당하게 하는 방법.
- 형태 예
보통 게시판에 게시글을 작성할 때 텍스트 또는 이미지 등을 입력하지만 <script>~</script>와 같은 태그를 입력한다.
사용자가 다른 사람이 작성한(<script>와 같은 태그를 포함하는) 글을 클릭하면 서버는 요청에 대한 응답으로 게시들의 내용을 전송해준다.
사용자의 브라우져는 전송받은 데이터를 읽어서 창에 띄우면서 <script> 태그를 실행하게 된다.
예를 들어<script> alert(document.cookie) </script> 와 같은 태그라면 사용자의 쿠키를 보여주는 것이 실행된다.
"alert(document.cookie)" 이것 대신 악성 코드를 넣으면 공격을 당하게 되는 것이다.
3. Reflected XSS
- 스크립트가 포함된 공격 URL을 다른 웹 사이트나 이메일로 보내서 다른 사용자가 클릭 하도록 유도함.
대게 인코딩을 해서 사용자가 쉽게 못 알아채게 함.
- 보통 서버는 클라이언트의 요청에 대해 정확한 응답이 어려우면 요청된 값을 그대로 HTML 문서에 넣어 응답하는데 이를 이용한 것.
- 예 (KISA 문서 참고)
클라이언트 요청 URL: http://www.xxx.ca/yy/?zz=<script>alert(document.cookie)</script>&namu=0
서버 응답:
<body> <div id="pageTitleTxt">
<h2><span class="highlight">Search Results</span><br />
zz: "<script>alert(document.cookie)</script>"</h2>
</body>
위의 예를 보면 클라이언트의 요청를 서버가 그대로 반사시킨 것을 알수 있다.
- 공격 형태: 주로 공격자가 사용자에게 악성 URL을 배포(이메일 등과 같은 수단을 이용)하여 사용자가 클릭하도록 유도하여 공격함.
이러한 공격으로 반사시킨 웹 사이트의 사용자 정보 등이 공격자에게 넘어갈 수 있음.
4. DOM based XSS
- DOM(Document Object Model)은 HTML 및 XML 문서에 접근방법을 정의하는 모델로써 HTML 문서를 계층적으로 보면서 컨텐츠를 동적으로 변경할 수 있다.
- 사용자의 브라우저가 HTML 문서를 파싱하는 과정에서 DOM 생성의 일부로 실행되면서 공격을 당하게 됨. (DOM 환경에서 악성코드가 실행 됨)
- Stored XSS, Reflected XSS가 서버 측의 응답 페이지에 악성코드가 포함되어 사용자의 브라우져가 이를 실행하면서 공격을 당하게 하는 것이라면,
DOM 기반 XSS는 서버와는 상관없이 브라우져에서 발생한다.
- 공격 형태
DOM 기반의 XSS 취약점이 있는 브라우져 사용자를 대상으로 "http://www.server.com/page.html?name=<script>alert(document.cookie)</script>"과
같은 악의적인 URL을 보내 사용자가 클릭하면 파싱과정에서 <script>태그를 수행하게 됨.
5. XSS 공격에 의한 피해
- 쿠키 정보/세션 ID 노출
세션 쿠키는 사용자가 웹사이트를 읽거나 방문하는 동안에만 임시로 메모리에 존재하는쿠키이며,
쿠키 생성 시 만료 기간이 설정되어 있지 않은 경우에 세션쿠키가 만들어 진다. (브라우져 종료시 세션 쿠키는 삭제 됨)
웹 애플리케이션이 세션 ID를 쿠키에 포함하는 경우 XSS 공격을 통해, 클라이언트의 합법적인 세션 ID를 획득하여 불법적으로 정상 사용자로 가장할 수 있음.
- 시스템 관리자 권한 획득
공격자가 웹 서버에 다양한 악성 데이터를 포함시켜 놓은 후, 사용자의 브라우저가 악성 데이터를 실행하는 경우,
브라우저에 있는 제로데이 취약점 또는 패치되지 않은 취약점을 공격하는 공격 코드가 실행되면서 사용자 시스템이 통제될 수 있음.
- 악성코드 다운로드
XSS 공격은 악성 스크립트 자체로만으로는 악성 프로그램을 다운로드 할 수 없지만,
사용자가 악성 스크립트가 있는 URL을 클릭하도록 유도하여 악성 프로그램을 다운로드 받는 사이트로 리다이렉트(redirect) 하거나,
트로이목마 프로그램을 다운로드하여 설치할 수 있음.
6. XSS 보안 대책
- 방화벽을 통해 예방하고 있지만 대부분의 방화벽이 시그니쳐 기반의 XSS 공격만을 탐지하고 있어서 특정 문자열을 탐지하는 기술은 쉽게 우회가 됨.
개발자들이 발생가능한 모든 위험한 문자를 필터링하고 인코딩하는 것은 현실적으로 불가능함.
- 입/출력 값 검증 및 무효화 방법
XSS 공격이 <script> 태그를 사용하므로 태그 문자를 필터링하고, 서버에서 클라이언트로 전송 시 문자를 인코딩함.
예: "<"는 HTML의 "<"로 변경. 이렇게 하면 사용자는 <script>가 <script>로 보이지만 HTML 문서에서는 <script>로 나타나
브라우저에서 일반 문자로 인식하고 스크립트로 해석되어 실행되지는 않는다.
CSS 태그의 속성에도 악성 코드가 삽입 가능하다.
예: <DIV STYLE="background-image: url(javascript:alert(document.cookie))">
<iframe src="악성 URL" width="0" height="0" frameborder="0"></iframe>
속성 값 역시 인코딩을 통해 공격을 방어해야 하낟.
- 보안 라이브러리 사용
AntiXSS: MS에서 개발한 XSS 예방 라이브러리
OWASP ESAPI: OWASP에서 오픈소스로 개발한 라이브러리
- JAVA기반 웹 어플리케이션의 경우, web.xml에 필터를 선언하여 모든 파라미터가 해당 필터를 거치도록 함.
서버나 DB에 저장된 데이터를 사용자의 웹페이지에 뿌려줄 때에도 필터링 해야함.
흔히 일부 태그 및 속성만 막는데, 반대로 일부 태그 및 속성만 허용하게 하는 것이 좋음.
* 참고
1. 2013.11 KISA 크로스 사이트 스크립팅(XSS) 공격 종류 및 대응 방법
7. CSRF(XSRF, Cross Site Request Forgery, 사이트간 요청 위조)
- 공격자가 의도한 행위를 사용자도 모르게 사용자가 하는 것.
- XSS 공격은 악성 스크립트가 클라이언트에서 실행되는데,
CSRF는 사용자 직접 악성 스크립트를 서버에 요청하는 것이 차이점.
- 사용자가 인증한 세션이 계속 유지되어 정상적 요청과 비정상적 요청을 구분 못하는 것 이용.
- on-site 요청은 공격자가 입력한 스크립트를 웹 사이트 방문자가 실행하는 것.
CSRF라고 불리는 cross-site 요청 변조는 웹사이트에 악성 스크립트를 입력하고 해당 사이트 방문하는 사용자가 스크립트에 의해 특정 행동을 하게 만드는 것.
- 예
① 게시판에 자동으로 글을 쓰게 하는 스크립트를 삽입하여 사용자가 글을 읽는것만으로 자동으로 글이 써지게 함.
② 쇼핑몰에서 자동으로 특정 물품들을 장바구니에 담을수 있는 스크립트를 삽입하여 사용자가 글을 읽는것만으로 자동으로 특정 물품들이 장바구니에 담아지게 함
③ 쇼핑몰에서 자동으로 담긴 장바구니에 대해 자동으로 주문하게 하는 스크립트를 삽입하여
사용자가 글을 읽는것만으로 자동으로 장바구니에 있는 특정물품들이 주문되게 됨.
- 공격이 사용자를 통해 이루어지기 때문에 공격자의 IP 추적이 불가능 함.
- 공격 과정
① 서버에 CSRF 공격 코드 등록
② 사용자가 서버에 페이지 요청하면 CSRF 코드가 포함된 페이지가 응답 됨.
③ 사용자도 모르게 CSRF 코드가 실행되어 서버에 요청이 감.
- 보안 대책
GET 방식 보다는 POST 방식을 사용.
사용자 세션 검증 및 재인증 또는 사용자 구분 방법 도입.
댓글 없음:
댓글 쓰기