"Compared to other companies Apple has a lot of deprecated (?) legacy applications running. It looks like a mingle-mangle of different programming languages, application servers, domains or hostnames and independently running services - with a lot of bugs."
Nearly every large corporation is similar in this regard.
Apple definitely credits vulnerability reporters appropriately, which is a good thing. However, I don't think that's the issue here. I think the point is that they leave a lot to be desired in terms of communication, response times, and time to patch.
Since he doesn't show the full URL in most of the images it's not possible to say for sure, but many of them appear to be a later stage in a multi-step process (registration, verifying email) to which you couldn't direct someone you wished to exploit.
If you have to enter bogus form input and make it to step 3, then while it technically is still XSS, it's not useful as an attack vector.
The others where an arbitrary user can be exploited by following a simple link (think I saw 2-3 of these) are real. CSRF protection won't help you there, since once I have JS running on your page I can insert iFrames or use XMLHTTP and read the CSRF tokens myself.
Depending on the application even if it's a multiple step operation, if the operation is purely based on session/cookies it's still possible to carry out a successful XSS attack.
Can anyone explain what I'm actually supposed to see here? Screenshots of some directory names dont really mean anything unless you already understand what they mean
Each of the screen shots shows the XSS vulnerability in action. IE: all of the alert/confirm pop-ups you see on the screenshot are not supposed to be there, they've been injected through an XSS vulnerability.
The assumption is if you can cause an alert to display, you can (probably) run AJAX requests and actually get some data/do some damage.
A page that lets you run arbitrary JavaScript in your own browser is not automatically vulnerable . For it to be a vulnerability you must be able to run arbitrary JavaScript in someone else's browser. If these pages protect against CSRF, most of them aren't vulnerable, expresslane being one case where I think you could get the JS to someone else without CSRF.
If the arbitrary JS is specified by a specially crafted URL or form POST, you can make the JS execute in someone else's browser as easily as getting someone to click on a very innocent-looking link.
And as soon as you can get someone to execute arbitrary JS on a particular domain, any CSRF protection will be useless because you practically control their browser. (You can even literally control their browser, if you use BeEF http://www.bindshell.net/tools/beef.html )
You can even completely hide the XSS happening by loading it into an invisible IFRAME, while the main page keeps the victim's attention occupied by playing the promised video of a cute kitten playing with a ball of string.
You could "share" link with your own javascript embedded in it that reads cookies and sends them to your logging server. Or customize the website so that when somebody types their password, it sends it to your logging server. If you can run custom javascript on a page, it's a security problem.
These screenshots show pretty textbook reflected XSS vulnerabilities, so I don't see why you think there's a CSRF vulnerability required for an exploit. Most of the targets are innocuous operations that aren't modifying any persistent state, so they wouldn't normally have CSRF protection. In particular, the search queries all appear to support direct-linking (notice the query string), which means they can't employ CSRF mitigations (because it would break the links).
(come on people, what's with all the downvotes? this is an interesting discussion! maybe the premise is incorrect but the answers are super informative)
Hey brlewis, even though we haven't managed to (completely/reliably) crack your CSRF example YET ... I hope you agree that it's better to not have an XSS in the first place rather than rely on CSRF to make it (way) more difficult, right?
[+] [-] lwhi|14 years ago|reply
A cross-site scripting issue was addressed. We would like to acknowledge "some stupid nerd" for reporting this issue."
Made me smile.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] absconditus|14 years ago|reply
Nearly every large corporation is similar in this regard.
[+] [-] abailin|14 years ago|reply
[+] [-] justinschuh|14 years ago|reply
[+] [-] kogir|14 years ago|reply
If you have to enter bogus form input and make it to step 3, then while it technically is still XSS, it's not useful as an attack vector.
The others where an arbitrary user can be exploited by following a simple link (think I saw 2-3 of these) are real. CSRF protection won't help you there, since once I have JS running on your page I can insert iFrames or use XMLHTTP and read the CSRF tokens myself.
[+] [-] fmavituna|14 years ago|reply
[+] [-] bobbles|14 years ago|reply
[+] [-] MattBearman|14 years ago|reply
The assumption is if you can cause an alert to display, you can (probably) run AJAX requests and actually get some data/do some damage.
[+] [-] o1iver|14 years ago|reply
[+] [-] brlewis|14 years ago|reply
[+] [-] tripzilch|14 years ago|reply
And as soon as you can get someone to execute arbitrary JS on a particular domain, any CSRF protection will be useless because you practically control their browser. (You can even literally control their browser, if you use BeEF http://www.bindshell.net/tools/beef.html )
You can even completely hide the XSS happening by loading it into an invisible IFRAME, while the main page keeps the victim's attention occupied by playing the promised video of a cute kitten playing with a ball of string.
[+] [-] jlongster|14 years ago|reply
[+] [-] justinschuh|14 years ago|reply
[+] [-] tripzilch|14 years ago|reply
Hey brlewis, even though we haven't managed to (completely/reliably) crack your CSRF example YET ... I hope you agree that it's better to not have an XSS in the first place rather than rely on CSRF to make it (way) more difficult, right?