XSS는 Cross Site Script의 약자로 서버의 응답에
공격자의 스크립트가 포함되어 사용자의 웹브라우저에서
스크립트가 실행되는 취약점을 말합니다.
XSS는 주로 사용자의 쿠키 혹은 세션 탈취 또는 사용자의 페이지 변조
등의 목적들을 위해 사용됩니다.
XSS는 공격자의 스크립트가 전달되는 방식에 따라
Stored XSS 와 Reflected XSS 등으로 분류됩니다.
Stored XSS
Stored XSS 는 공격자의 스크립트가 서버에 저장되어 있다가
사용자가 서버에 저장된 공격자의 스크립트를 조회하는 순간 발생하는
형태의 XSS 입니다.
대표적으로 악성 스크립트가 작성된 게시판을 조회할 때 스크립트가 실행되는
공격 방식이 있습니다.
공격자의 스크립트를 사용자가 조회해야 한다는 조건 때문에
Stored XSS의 파급력이 서비스 종류에 따라 달라질 수 있습니다.
Reflected XSS
Reflected XSS 는 공격자의 스크립트가 사용자의 요청과 함께
전송되는 형태의 XSS 입니다.
Reflected XSS 는 Stored XSS 와는 다르게 사용자의 요청 데이터에 의해
취약점이 발생하기 때문에 변조된 데이터가 사용자의 요청으로 전송되는 형태를 유도해야 합니다.
이를 위해 공격자는 특정 링크를 유도할 수 있으며 Click Jacking, Open Redirect 등의
다른 취약점들과 연계하여 Reflected XSS 를 발생시킬 수 있습니다.
Reflected XSS 의 대표적인 예시로는 서버가 편의를 위해
사용자의 입력을 아무런 검증없이 그대로 응답에 포함하는 경우가 있습니다.
Mitigations
XSS는 오래전부터 발생해 왔던 취약점이기 때문에 이를 방어하기 위해
많은 방안들이 생겨났습니다.
브라우저 단에서 방어할 뿐만 아니라 서버에서 또한 사용자의 입력을 올바르게
검증하는 방식으로 XSS를 방어해야 합니다.
1. Server-side Mitigations
XSS 취약점을 방어하기 위한 첫번째 방법으로는 사용자의 입력을
서버 단에서 검증하는 방법입니다.
사용자의 입력 값이 HTML 태그가 될 일이 없다면 꺽쇠 (<, >) 혹은
따옴표(", ') 와 같은 특수문자를 HTML Entity Encoding 을 이용하여
사용자의 입력이 HTML 태그로 인식되지 않도록 할 수 있습니다.
html entity encoding 적용 이후 alert(1)이 실행되지 않는 모습
2. HTTPOnly Flag
HTTPOnly Flag 는 쿠키 생성 시 설정할 수 있으며 서버 측에서 응답 헤더에
Set-Cookie 헤더를 전송해 자바스크립트에서 해당 쿠키에 접근하는것을 막을 수 있습니다.
이는 XSS 취약점이 발생하더라도 HTTPOnly Flag가 적용된 쿠키의 데이터가
공격자에게 탈취당하는 것을 방지 할 수 있습니다.
3. CSP - Content Security Policy
CSP를 이용하여 사이트에서 로드하는 리소스들의 출처를 제한할 수 있습니다.
CSP는 응답 헤더나 meta 태그를 통해 아래와 같이 선언하여 사용할 수 있습니다.
Content-Security-Policy: <directive>;예를 들어 default-src 'self' *.google.com 과 같이 설정된 CSP는
모든 리소스의 출처가 현재 도메인이거나, *google.com 도메인일 경우에만 허용합니다.
또한 script-src 를 선언하여 자바스크립트 코드의 출처를 제한할 수 있어
공격자가 작성한 임의의 자바스크립트 파일을 외부로부터 호출하거나
공격자가 직접 자바스크립트 코드를 작성하는 행위 등을 막을 수 있습니다.
이 외에도 많은 리소스 형식의 출처를 제한할 수 있으며 특히
script-src 'nonce-nonce_value' 와 같이 nonce 값을 설정하고
HTML 태그를 이용해 자바스크립트를 실행 할 때에 서버에서 생성한 nonce 값을
알아야만 실행할 수 있도록 제한할 수 있습니다.
