Saturday, August 20, 2016

Bug hunting story - Apple - XSS

This one is so trivial that I still can't believe how did it get through QA approval, I'm not even mentioning how come those hundreds of security engineers working for Apple missed it.

http://support.apple.com/kb/index?page=search&product=&q='"><input autofocus onfocus="alert('XSS by Infern0_')">&src=support_site.kbase.search.searchresults

The only trick was that Apple's search engine has two APIs. One is located on apple.com and that one wasn't vulnerable. The second one was located on support.apple.com and this one was vulnerable.
So to find a bug you first had to enter something in apple.com search engine, follow redirect to 2nd API of support.apple.com and exploit search engine there.
+ You couldn't just enter the payload in the first API and wait for redirect, because dangerous characters were being encoded between APIs and it wouldn't have worked automatically.
So that was the trick, but if you're given a search engine to test, you test all the APIs that are being touched by functionality, no matter if it's complex redirects dance or single endpoint. You bash around and see how it behaves, so there is no excuse for such XSS to exist in production environment.
++ AFAIR there was a dumb filter blocking tags like <script>, that's why I used DOM events to trigger XSS.



My experience with Apple?
Decent. I received a human response within a few days, and the bug itself was fixed within 2 weeks. They are brief in responses but that's just fine.

No comments:

Post a Comment