XSS(Cross Site Scripting) 총정리

1. XSS의 개념

XSS(Cross Site Scripting)는 웹 응용 프로그램의 취약점으로, 웹 응용 프로그램을 대신하여 제3자가 사용자의 브라우저에서 스크립트를 실행할 수 있는 공격의 개념이다. 사이트 간 스크립팅은 현시대의 웹에 존재하는 가장 널리 퍼진 취약점 중 하나이다. 사용자에 대한 XSS의 공격은 계정 손상, 계정 삭제, 권한 상승, 멀웨어 감염 등과 같은 다양한 결과를 초래할 수 있을 것이다.

 

초창기에는 CSS라고 불렸는데, 지금의 XSS와 완전히 같은 양상을 보인 공격이라고는 할 수 없다. 처음에는 악성 웹사이트가 자바스크립트를 이용하여 다른 웹사이트의 응답을 iframe에 포함시켜 읽고, 스크립트를 실행하여 페이지 내용을 수정하는 방식이었다. 그때는 분명 CSS라고 부르던 시절이다. 사실 이 개념을 처음 공부할 때, 왜 Cross로 시작하는데 약어는 X로 시작하는지 의아했다. 근데 이유는 그냥 간단하다. 기존에 CSS라고 부르던 개념이 또 있었기 때문이다. Cascading Style Sheets와의 혼동을 피하기 위해 XSS라고 바꾼 것이다. 이때에 넷스케이프가 동일 출처 정책을 도입하고, 사이트 간 스크립팅이 교차 출처 응답 읽기를 가능하게 하는 것이 제한되면서 정의까지 바뀐 것이다. 그리하여 CSS에서 XSS로 새롭게 태어난(?) 이 공격은 웹사이트가 응답에 반응하기 전에 사용자로부터 제공받은 입력을 제대로 처리하지 않았을 때 발생 가능성이 커진다. 이러한 경우에 브라우저에 의해 실행되는 조작된 입력이 주어질 수 있는 것이다.

 

2. XSS의 종류

XSS는 크게 2가지 유형으로 분류할 수 있다. Reflected XSS와 Stored XSS로 말이다.

 

① Reflected XSS

실행하기 위해 매번 입력을 제공해야 하는 경우 이러한 XSS를 reflected라고 한다. 이러한 공격은 대부분 페이로드를 피해자에게 직접 전달함으로써 수행된다. 피해자는 페이로드가 포함된 요청이 있는 페이지를 요청하고 페이로드는 스크립트로 응답에 내장된다. reflected XSS의 예로는 검색 필드의 XSS가 있다.

 

② Stored XSS

페이로드가 포함된 응답이 페이로드 제출 없이 매번 방문할 때마다 스크립트가 실행되도록 서버에 저장되면 저장된 XSS로 식별되는 것이다. 저장된 XSS의 예로는 주석 스레드의 XSS가 있다. 차이는 결국 입력을 매번 제공해야 하는가, 따로 Stored해서 제공하지 않아도 되는가의 차이인 것이다.

 

한편, DOM 기반 XSS라는 다른 유형의 XSS가 있으며, 이것은 reflected거나 stored한다. DOM 기반 XSS는 사용자가 제공한 데이터가 적절한 검사 없이 DOM 개체에 제공될 때 발생한다.

 

3. XSS의 대응 방안

① 서버 측면: 입력 값 검증(서버에서 화이트 리스트 방식 필터링), 출력 값 인코팅(HTML 인코딩 출력), HTML 포맷 입력 페이지 최소화, 중요 정보 쿠키 저장 지양, 인증 강화(세션과 IP 통합하여 서버에서 인증), 스크립트에 의한 쿠키 접근 제한 등

 

② 클라이언트 측면: 주기적인 패스워드 변경, 브라우저 최신 패치, 링크 클릭 대신 URL 직접 입력, 브라우저 보안 옵션 등급 상향(쿠키 사용금지)

 

③ 기타: 사용자 입력 문자열에서 <, >, &, " 등을 replace와 같은 문자변환 함수나 메소드로 &lt, &gt, &amp, &quot로 치환, HTML tag 리스트 선정과 해당 태그만 허용(일종의 화이트 리스트 법칙), 보안성이 검증된 API를 사용해 위험한 문자열 제거

 

4. XSS에 안전한 JAVA 소스코드

XSS에 취약한 소스코드를 확인해 보면 name이라는 변수의 문자열을 받고 <p> 태그를 통해서 바로 출력한다. name 값에 자바 스크립트가 입력되면 그대로 실행된다. 즉, name 값에 "<script>alert("XSS Test");</script>"라고 입력하는 것이다.