[Web Security] Chapter 3 - Cross-Site Scripting Attack (XSS)

The Cross-Site Scripting Attack

Cross-Site Scripting Attack(XSS)란, 공격자가 자신의 악성코드를 목표 웹사이트에 주입하여 해당 웹 사이트 사용자의 브라우저가 악성코드를 실행하도록 하는 공격이다.

악성 코드는 웹 사이트로부터 전달되기 때문에, 신뢰된 코드로 간주된다. 따라서 XSS 공격은 다음과 같이 사용자 세션 안에서 할 수 있는 모든 행동이 가능하다.

• 페이지의 내용 읽기/쓰기

• 웹사이트의 쿠키 읽기

• 사용자를 대신해 요청 보내기 ...

자바 스크립트 코드를 삽입할 수 있는 모든 입력 필드는 XSS의 공격 표면(Attack Surfaces)이다.

• 브라우저는 웹 사이트에서 받은 코드(스크립트)를 정상적인 코드로 간주

• 웹 사이트로 부터 받아온 코드는 현재 페이지에서 사용되는 다른 스크립트들과 동일한 권한(Origin)을 부여받음

Non-persistent (Reflected) XSS Attack

웹 사이트가 사용자의 입력을 받는 반응형 페이지(Reflective)인 경우를 살펴보자.

공격자가 입력값에 JavaScript 코드를 주입할 경우, 해당 악성 코드 실행 결과가 그대로 웹 페이지에 반영(Reflect)된다.

원래 웹페이지의 URL은 다음과 같다.

http://www.example.com/search?input=word

여기서 word는 사용자 입력값에 해당하며, 공격자는 다음과 같이 스크립트를 삽입한 URL를 이용하여 사용자가 클릭하도록 유도한다.

http://www.example.com/search?input=<script>alert("attack");</script>

피해자가 위 링크를 클릭할 경우 HTTP 요청이 www.example.com 서버로 전송되며, 브라우저는 스크립트가 실행(Reflect)된 결과 페이지를 출력한다.

Persistent(Stored) XSS Attack

Persistent XSS Attack는 공격자가 전송한 악성 스크립트를 서버가 저장하고 있는 경우이다.

따라서 사용자가 해당 웹 사이트를 이용하는 과정에서 스크립트가 포함된 데이터를 받을 경우, 스크립트가 실행되며 공격받는다.

사용자가 전송하는 데이터에는 JavaScript 코드가 포함될 수 있다. 웹 사이트(서버)가 사용자의 데이터를 제대로 정제(sanitize)하지 않을 경우, 스크립트가 포함된 데이터가 서버에 저장되어 해당 스크립트가 다른 사용자의 브라우저에 전달되어 실행될 수 있다.

Damage Caused by XSS

• Web Defacing(웹 훼손) : 자바 스크립트 코드는 DOM API를 활용하여 페이지 내부의 DOM 노드에 접근이 가능하다. 따라서 삽입된 자바 스크립트 코드는 페이지 내용을 임의로 변경 가능하다.

  • 페이지의 내용을 가짜로 위조, 페이지의 이미지를 다른 이미지로 변경

• Spoofing requests(요청 위조) : 삽입된 자바 스크립트 코드는 사용자를 대신하여 서버에 HTTP 요청을 보낼 수 있음

• Stealing information(정보 탈취) : 삽입된 자바 스크립트 코드는 피해자의 민감한 정보를 훔칠 수 있음

  • Cookies, 웹 페이지에 저장된 개인 정보, 웹 애플리케이션에 의해 로컬에 저장된 데이터 등

Self-Propagation XSS Worm

XSS 코드를 웹 페이지에 방문한 사용자들의 웹 페이지에 악성 코드 사본을 저장하도록 구성할 수 있다.

따라서 감염된 페이지를 다른 사용자가 방문하면, 해당 사용자도 감염되며 코드는 계속해서 확산될 수 있다.

XSS 공격 전파 방식에는 두 가지 대표적인 방식이 존재한다.

• DOM approach : 자바 스크립트 코드는 DOM API를 통해 자기 자신의 코드를 복사하여 DOM에 가져올 수 있다.

  • 페이지에 JavaScript 코드가 포함되어 있다면, 그 코드는 트리 안의 하나의 객체로 저장되어 있음

  • DOM API를 통해 트리 상의 각 노드에 접근 가능하므로 해당 코드를 담고 있는 노드를 알고 있다면 코드 복사가 가능

• Link approach : 자바 스크립트 코드는 <script> 태그의 src 속성을 사용해서 웹 페이지에 외부 링크 형태로 포함될 수 있다.

  • 외부 URL로부터 스크립트를 가져오는 코드가 존재

  • 해당 URL에 해당하는 스크립트 내에 XSS Attack을 위한 코드를 작성

  • 이 방식은 더 짧고 은폐하기 쉽기 때문에 공격자에게 보다 유리

Counter measures

이러한 XSS 공격을 대응하기 위한 대응책에는 무엇이 존재할까?

• Filtering : 사용자 입력에서 XSS 코드를 제거하는 방식

  • <script> 태그 외에도 코드를 삽입할 수 있는 다양한 방식이 존재하기 때문에 현실적으로 어려움

  • JavaScript 코드를 필터링할 수 있는 오픈소스 라이브러리를 활용하는 것이 바람직(jsoup)

• Encoding : HTML Markup을 대체 표현으로 바꾸는 방식

  • JavaScript 코드가 포함된 데이터를 브라우저로 보내기 전에 인코딩하면, 해당 스크립트는 브라우저에서 실행되지 않고 문자로 표현됨

  <script>alert('XSS')</script> // conver to
  &lt;script&gt;alert('XSS')

Content Security Policy(CSP)

XSS의 근본적인 문제점은 데이터와 코드가 섞여 있는 것(코드가 인라인으로 삽입)이다.

이를 해결하기 위해 인라인 스크립트를 허용하지 않고 링크 방식(외부 스크립트 파일)만을 허용하여 데이터와 코드를 강제로 분리시키는 방식을 CSP라고 한다.

CSP는 지정된 출처(Origin) 외의 스크립트는 실행을 차단하므로 XSS를 방지할 수 있다.

위 경우, 총 세 가지 Origin에서 불러오는 스크립트를 허용한 것이다.
self, example.com, https://apis.google.com

다음과 같이 Inlined Code를 일부 허용하는 방식도 사용될 수 있다.

nonce(Number used once)란, 매번 바뀌는 일회용 난수 문자열로 CSP 헤더에 지정한 nonce와 일치하는 스크립트 태그만 실행을 허용한다.

XSS 공격자는 서버가 발급한 정확한 nonce값을 알지 못하기 때문에, 스크립트를 삽입하더라도 브라우저에서 실행되지 않는다.

CSP Bypass

콜백 함수에 Cookie 정보를 가져오는 스크립트가 삽입되어 있는데, JSONP 방식의 경우 해당 콜백 함수를 그대로 실행하기 때문에 XSS가 실행된다.

CSRF vs XSS

Q1. CSRF와 XSS의 주요 차이점은 무엇인가?

CSRF와 XSS는 모두 Cross-Site라는 표현을 포함하고 있는 공격이다.

XSS는 공격자가 악성 스크립트를 웹 페이지에 삽입하여 피해자의 브라우저에서 해당 스크립트가 실행되도록 유도하는 공격이다.

CSRF는 서버가 동일 사이트 요청과 외부 사이트 요청을 구분하지 못하는 취약점을 이용해 HTTP 요청을 조작하는 공격 방식이다.

따라서 XSS는 클라이언트를 직접 공격(쿠키 탈취, 페이지 내용 변조 등)하고, CSRF는 사용자의 권한을 이용하여 서버에 보내는 요청을 조작하는 공격이라는 차이점이 있다.

Q2. CSRF 공격에 대한 대응책을 XSS 방어에도 사용할 수 있을까?

두 방어 기법은 일반적으로 다르다.

비밀 토큰(Secret token)이나 SameSite Cookie는 서버가 요청의 출처를 확인하고, 사용자가 의도하지 않은 요청을 차단하기 위한 방식이다.

즉 Origin 확인을 통해 서버에 들어온 요청을 차단하거나 허용하는 방식이므로 CSRF 방어에는 효과적이다.

XSS는 브라우저에서 악성 스크립트가 실행되도록 유도하는 공격이므로 요청의 출처를 확인하는 것은 적절한 대응책이 아니다.

XSS를 효과적으로 방지하기 위해선 스크립트 실행을 제어하는 방식(CSP, HTML 인코딩 등)을 활용하는 것이 보다 적절한 대응책이다.