이 포스팅은 2024.05.25에 작성되었습니다.
JWT토큰에 대해 공부하며 XSS라는 웹사이트 공격방법을 알게되었다.
JWT토큰을 보관할 때 XSS 고려하지않으면 스크립트가 실행되어 토큰이 탈취될 위험이 있다. 아무리 CSRF등의 공격을 잘 방어해도, XSS가 뚫리면 나머지가 아무 소용이 없기 때문에 꼭 방어해야한다.
이번 포스팅에서 XSS의 개념과 방어하는 방법에 대해 자세히 알아보려고 한다.
XSS(Cross-site Scripting)
악의적인 사용자가 공격하려는 사이트에 script를 넣는 방법
XSS는 SQL injection과 함께 웹 상에서 가장 기초적인 취약점 공격 방법이다.
XSS공격이 성공하면 사이트에 접속한 사용자는 공격자가 삽입한 코드를 실행하게 되며, 의도치 않은 행동을 수행하거나, 쿠키&세션 토큰 등 민감한 정보를 탈취당할 수 있다.
예를 들면, <script>alert("XSS")</script> 와 같은 스크립트를 게시판 등에 삽입하여 다른 사용자가 실행하도록 만들 수 있다. 스크립트를 통해 해당 사이트에서 사용되는 모든 쿠키, 세션 토큰 또는 기타 민감한 정보에 액세스할 수 있기 때문에 사이트 개발자는 이를 꼭!! 대비해야한다.
XSS의 종류
XSS는 공격방법에 따라 Stored XSS, Reflected XSS, DOM Based XSS로 나뉜다.
Stored XSS
사이트 게시판이나 댓글, 닉네임 등 스크립트가 서버에 저장되어 실행
일반적으로 악의적인 사용자의 입력이 데이터베이스 등 서버에 저장될 때 발생한다. 이 때 브라우저에서 안전하게 랜더링하지 않을 경우, 사용자가 악성스크립트가 포함된 데이터를 읽으면 해당 스크립트가 실행된다.
Reflected XSS
URL 파라미터(GET방식)에 스크립트를 넣어 즉시 스크립트를 만드는 방식
오류 메시지, 검색 결과, 사용자의 입력을 웹 애플리케이션이 즉시 사용자에게 반환할 때 발생한다. (서버저장x, 사용자의 입력을 브라우저에서 렌더링)
Reflected XSS의 경우 HTML5 및 기타 브라우저 자체에서 이 공격을 차단하는 경우가 많아 상대적으로 공격을 성공시키기 힘들다고 한다. (서버로 전송되지 않음)
DOM Based XSS
클라이언트 측에서 사용하는 피해자 브라우저의 DOM "environment"을 수정한 결과로 공격 페이로드가 실행되는 XSS 공격
클라이언트 측 코드가 예기치 않은 방식으로 실행되도록 한다.
페이지 자체(HTTP 응답)는 변경되지 않지만 DOM 환경에서 발생한 악의적인 수정으로 인해 페이지에 포함된 클라이언트 측 코드가 다르게 실행된다.
더 자세히 알아보고 싶다면 OWASP사이트1 / OWASP사이트2 를 참고하길 바란다.
이 세가지 유형의 XSS는 명확하게 분류되지 않으며, stored와 dom based를 동시에 가질 수도 있다고 한다. 그래서 XSS의 유형을 위와 같은 3가지 방법이 아닌 Server XSS와 Clicent XSS로 나누기도 한다.
Server XSS는 악성 스크립트를 포함한 데이터가 HTTP 응답에 포함될 때 발생하며,
Client XSS는 신뢰할 수 없는 사용자의 데이터를 이용하여 안전하지않은 javascript 호출로 DOM을 업데이트할 때 발생한다.
XSS 공격예시
자바스크립트를 사용하여 공격하는 경우가 많으며, 단순하고 기초적인 방법이지만 많은 웹사이트들이 XSS에 대한 방어 조치를 해두지 않아 공격을 받는 경우가 많다고 한다.
(OWASP TOP 10에도 XSS는 항상 등장한다)
공격에 대한 예시는 다음과 같다.
- 여러 사용자가 접근하는 게시판에 코드를 삽입하여 해당 게시글을 읽은 사용자들의 브라우저에서 해당 코드를 실행하도록 함
: 이 경우 쿠키값이 해커의 홈페이지로 넘어갈 수 있음(세션 하이재킹) - 사용자의 페이지를 변조하여 데이터를 삽입함
- 이용자의 위치를 이동시켜 개인정보를 탈취
- 닉네임에 코드를 심어 스크립트를 실행시킴
Text-only 게시판이 아닌 HTML 태그를 사용할 수 있는 게시판의 경우 취약점이 있을 수 있다.
(나무위키의 경우도 초반에 스크립트 태그와 이벤트 속성도 막지 않았으나 이후 모두 수정되었다고 한다)
공격해보기
https://www.w3schools.com/html/tryit.asp?filename=tryhtml_basic
이 사이트에서 html을 실행해보면서 XSS를 실행시켜볼 수 있다.
1. script 태그 삽입
만약 게시판 내용에 script가 포함되어 있다면 그대로 실행된다.
(벨로그에도 해당 script를 넣어봤는데 실행이 되지 않는걸 보니 막아둔 것 같다.)
2. a태그 링크로 삽입
a태그 링크를 클릭하면 해당 스크립트가 실행된다. javascript:를 필터링하는 경우가 많아 많은 사이트에서 막는다고 한다.
(벨로그에서는 javascript:로 시작하는 링크의 경우 클릭이 안된다. 막아둔 것 같다. https:// 로 시작하는 사이트의 경우는 클릭이 된다. XSS , 사이트링크)
다음과 같이 HTML 인코드하여 난독화하는 방식으로 scsipt 태그를 실행할 수도 있다고 한다. (벨로그는 당연히 안된다. XSS)
3. iframe태그를 이용한 스크립트 실행
iframe태그는 현재 HTML 문서에 다른 문서를 포함시킬 때 사용한다.
이 태그 src속성에 javascript:로 시작하는 악성스크립트를 넣음으로써 스크립트를 실행할 수 있다.
4. 이벤트 속성
이렇게 이미지 태그를 넣으면 이미지를 보기만해도 스크립트가 실행된다. (벨로그는 역시 막아뒀다)
XSS의 위험성
XSS 공격으로 인해 다음과 같은 피해가 발생할 수 있다.
-
쿠키 정보 및 세션 ID 획득
: 공격자가 사용자 세션을 하이재킹하고 계정을 탈취할 수 있다 -
시스템 관리자 권한 획득
: 회사 등 조직의 개인 PC가 해킹될 경우, 조직 내부로 악성코드가 이동하여 중요 정보가 탈취될 수 있다.
: 공격자가 보도 자료나 뉴스 항목을 수정할 수 있도록 허용하는 XSS 취약점은 회사의 주가에 영향을 미치거나 소비자 신뢰도를 떨어뜨릴 수 있다(콘텐츠 스푸핑) -
악성 코드 다운로드 url 노출
: 원하지 않는 다른 사이트로 리디렉션 되거나, 원하지 않는 파일이 다운로드 되는 경우도 있다.(트로이 목마 프로그램 설치 등) -
거짓 페이지 노출
: 관련 없는 페이지를 표시하여 사용자의 개인정보가 유출될 수 있다.
XSS 방어방법
XSS는 웹 애플리케이션의 입력과 출력에서 데이터를 검증하거나 인코딩하지 않는 경우 많이 발생한다. 그렇기 때문에 데이터를 입력받을 때와 출력할 때 모두 필터링하고, 클라이언트에도 막을 수 있을만한 수단을 구성해놓는 게 좋다.
방법을 크게 분류해보면 다음과 같다.
1. 입력 필터링
2. 출력 필터링
3. 쿠키의 보안 옵션 사용
4. 콘텐츠 보안 정책 사용
입력 필터링
1. 직접 만들기
적당한 XSS 필터를 만든 뒤, 모든 입력이 필터를 거치도록 하는 것만으로도 좋은 효과를 볼 수 있다고 한다. 주로 <와 >문자를 < >라는 HTML문자로 바꾸어 단순 문자로 인식되게 필터링한다.
물론 HTML태그와 각종 스타일을 적용시켜야 하는 사이트에서는 다른 방법을 찾아봐야한다. 이 경우에는 스크립트 태그와 이벤트 속성, javascript: 링크만 제대로 막아주어도 상당수를 막을 수 있다.
(더 꼼꼼하게 막기 위해서는 일부 태그 및 속성만 허용하도록 하는 게 좋다)
2. 라이브러리 사용
기존의 라이브러리를 가져다 사용하는 것도 좋은 방법이다. 예시로는 OWASP Antisamy, Naver Lucy XSS filter, ESAPI 등이 있다.
혹은 BBCode를 사용할 수도 있다. BBCode는 전자 게시판에 글을 작성하는 데 쓰이는 가벼운 마크업 언어이며, 대부분의 위키에서도 이 방법을 사용한다. 만들기도 다른 방법에 비해 편하고, 안전성도 높은 편이기 때문에 가장 추천되는 방법이라고 한다.
출력 필터링
HTML5부터 iframe의 sandbox 옵션으로 iframe 내의 자바스크립트, 폼과 같은 것의 제한이 가능해졌다. 하지만 구버전의 웹 브라우저라면 호환이 되지 않아 스크립트가 그대로 실행되거나, 설령 그게 아니더라도 웹 브라우저에서 취약점이 발견될 경우, 이런 방법이 뚫릴 수 있다.
쿠키의 보안 옵션 사용
쿠키 생성시 '보안 쿠키'라는 파라미터를 지정하면 TLS 상에서만 사용하게 할 수 있으며, HTTP ONLY라는 파라미터로 웹 브라우저상에서만 쓸 수 있게 할 수도 있다.
JWT 토큰을 쿠키에 저장하는 경우 많이 사용하는 방법이다.
콘텐츠 보안 정책(CSP) 사용
스크립트 실행에 대한 정책(조건)을 설정해 알 수 없는 스크립트가 실행되는 것을 예방할 수 있다.
원래는 외부 서버의 스크립트 파일이 script 태그나 iframe 등 사이트에 로드가 되면 스크립트가 실행되지만, CSP를 설정해 출처가 자기 서버인 스크립트만 실행되도록 할 수 있다.
더 알아보기
OWASP(The Open Worldwide Application Security Project)는 오픈소스 웹 애플리케이션 보안 프로젝트이며, 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점을 연구한다.
https://owasp.org/www-community/attacks/xss/
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
이 사이트에서 굉장히 좋은 정보를 많이 얻을 수 있어서 더 알아보고싶으신 분은 참고하면 좋을 것 같다. XSS 방지 치트시트도 있어서 참고하면 XSS를 더 안정적으로 예방할 수 있을 것이다!
조사하다보니 XSS와 관련한 내용이 생각보다 많아서 다 정리하지 못했다. 다음에 시간이 되면 조금 더 깊게 조사해보려고 한다.
참고자료
https://namu.wiki/w/XSS
https://4rgos.tistory.com/1
https://owasp.org/www-community/Types_of_Cross-Site_Scripting
https://owasp.org/www-community/attacks/xss/
https://velog.io/@layl__a/%ED%98%BC%EA%B3%B5-XSS-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EC%A7%80-%EC%98%88%EC%8B%9C%EB%A1%9C-%EC%82%B4%ED%8E%B4%EB%B3%B4%EC%9E%90
