앵하니의 더 나은 보안
restAPI 환경에서 XSS는 왜 동작하지 않는걸까? 본문
서론
API 환경에서의 XSS를 시도해서 무난하게 성공한적이 있는가?
분명히 burp의 response에서는 스크립트 태그 값 <, > 이 평범하게 찍혀나오는데,
이상하게 브라우져로 펼쳐지기만 하면 각각 <, >으로 치환돼서 보인다.
물론 <, >가 필요없는 곳에서는 동작할 수 있지만, 그런환경을 아직 본적이 없다.
그래서 왜 그런지 진상 규명 실시하고 어떻게 해야할런지, 어떻게해야 동작시킬 수 있는지 한번 알아보자
본론
HTML 파일에서의 XSS 동작
일단 아래 HTML 파일을 작성해 테스트에 사용해보자
<html>
<title>XSS Test</title>
<body>
<h1>XSS test</h1>
<script>alert("XSS test")</script>
</body>
</html>
그리고 실행하면 당연히 XSS test alert를 확인할 수 있다.
이는 브라우저의 document 영역에 xss 스크립트 구문이 존재하기 때문인데
그렇다는 말인즉, api 환경에서는 브라우저의 document 영역에 xss 스크립트 구문이 존재하지 않는다라는 말이 되겠다.
한번 확인해보자.
TXT 파일에서의 XSS?
API에서 확인한다더니 txt는 갑자기 왜? 라고 할 수 있는데, 당장 테스트해볼 수 있는 api 환경이 없어서 비슷한 상황을 연출하기 위해 txt파일을 사용하겠다.
아까 작성했던 HTML 파일의 확장자를 txt로 변경한 후, 크롬브라우저에 끌어놓아 스크립트가 동작하는지 확인한다.
그러면 스크립트가 동작하지않고, 작성한 스크립트가 그대로 브라우저에 노출되는데
이건 왜그런걸까?
바로바로 content-type이라는 응답 헤더때문이다.
content-type을 통해 브라우저는 해당 파일이 html을 기준으로 해석해야하는 파일인지, 아니면 그냥 화면에 보여줘야하는 파일인지 판단해 펼쳐준다.
그래서 txt로 파일확장자를 바꾼 파일의 content-type이 text/plain로 설정돼, 실제로 크롬 브라우저의 docuement 영역에서는 각각 스크립트 태그 문자 <, >가 아니라 <, >로 치환된다.
이 같은 이유로 api 서버의 통신을 통해 XSS가 힘들어진다.
왜? api 서버 통신은 content-type이 application/json으로 표기되는데 text/plain과 마찬가지로 몇몇 특수문자를 HTML ENTITY 형태로 치환해 브라우저에 펼쳐주기 때문에.
자 그럼 api 환경에서도 <, > 태그를 사용한 XSS 취약점이 존재할 수 있을까?
물론 있다.
어떻게? 바로 response header, 그러니까 content-type을 건드릴 수 있는 구조면 된다.
Content-Type Bypass
Hidden Parameter
type혹은 contentType 또는 기타 파라미터를 통해 content-Type을 변경할 수 있는경우
여러타입을 처리해야하는 CDN 서버같은 대상에서 종종 발견된다.
예시)
https://test.com/test?type=html&payload=<script>alert("test")</script>
특히 이런 파라미터들은 숨겨져있는 경우도 많이 있어서, burp의 ParamMiner혹은 zap의 Fuzzing을 사용해 파라미터를 획득해야한다.
WAS, G/W, Proxy, Server 설정
어플리케이션이 아니라 WAS 등 다른 서버가 Content-Type을 결정하는 경우
접근하는 확장자 변경을 시도했을때 확장자에 따라 Content-Type이 변경되는 경우
예시)
- /xss.json?.html
- /.html/../xss.json
- /xss.json/1.html
으로 path를 조작하고, 실제 exploit은 파라미터 값으로 전달하면 content-type이 변조될 수 있다.
DOM Include가 있는경우
DOM XSS가 존재할 경우 application type과 관계없이 exploit이 가능하다.
예시)
GET /page#widget=/vuln?query=%22%3E%3Csvg/onload=alert(45)%3E HTTP/1.1
'보안 기술 > WEB' 카테고리의 다른 글
| REST API 환경 웹 서버에서의 기존 취약점 탐구 (1) | 2024.02.06 |
|---|---|
| TLS 1.3 (0) | 2023.11.05 |
| HTTP 보안헤더 (0) | 2023.10.12 |
| HTTPS(SSL/TLS) 세션 성립 과정 (0) | 2023.10.08 |
| SSRF (0) | 2023.10.01 |
