[보안] XSS(사이트 간 스크립팅)

XSS란, 웹사이트 관리자가 아닌 이가 악성 스크립트를 삽입하여 개인정보를 유출하거나 악성코드를 실행하는 공격 기법이다. 이전 글의 SQL 인젝션과 유사한 공격 기법인데, Javascript 구문을 넣어서 탈취한다는 차이가 있다.

SQL 인젝션과 유사하다는 말은, 동일하게 유효성 검사를 통해 필터링해야 한다는 것이다. 더불어 웹사이트에서 동적으로 변하는 속성에 대해 DOM(Document Object Model) 구조 변경 시 검증이 필요하다.

XSS는 크게 3가지로 나뉜다.

1. Stored XSS : 서버에 저장하여 공격
2. Reflective XSS : 동적으로 생성되는 응답 페이지 작성 시 공격(링크를 눌렀을 시 공격)
3. DOM XSS : DOM 구조 변경 시 공격

이러한 공격은 정규식을 이용한 입출력값의 유효성 검사, HTML 인코딩(태그), XSS Filter, DB 조회결과의 유효성 검사, DOM 구조 변경 시 검증이 필요하다.

* DOM : HTML 문서의 모든 요소에 접근법을 정의한 API로, 최상위 요소는 Documnet이다. 만약 입력값을 text 노드로 처리(HTML 인코딩)하면 태그 공격이 동작하지 않는다.

CSRF(크로스 사이트 요청 위조) : 공격자를 대신하여 공격하는 기법이다. 즉, 실제 사용자가 요청하지 않은 요청을 권한을 가져와 요청하는 것이다.
-> 이는 실제 사용자의 요청인지 검사가 필요한데, CSRF Token을 사용하고, 함께 CAPCHA나 재인증을 사용한다.

화면 요청(GET) -> 화면+토큰 응답
요청+데이터+토큰 -> 유효성 검사 후 응답

위 과정을 거치면서 실제 사용자가 요청한 것인지 검증한다.

가장 간단한 예를 하나 들고 글을 마무리하도록 하겠다. 지난 SQL 인젝션이 SQL 구문을 넣어 쿼리 시에 탈취하는 것이었다면, 이는 코드를 삽입한다고 생각하면 간단하다.

<script type="text/javascript">
	alert("Hi");
</script>

HTML 사이에 이러한 태그가 들어가면 저 alert("hi");가 실행될 것이다. 지금은 예시이므로 알림창 뿐이지만, 다른 일들도 가능하기 때문에 위험하다. 그러므로 보통은 정규식과 HTML 인코딩을 통해 태그의 입력은 동작하지 않도록 한다. 다만 Stored XSS에서는 게시글과 같은 것을 통해 저장하여 실행시킬 수 있으므로, DB에서 조회결과에서 유효성 검사를 다시 해주어야 한다.