

10x XSS on apple.com - nilsjuenemann
http://www.nilsjuenemann.de/2011/11/applecom-xss-gallery.html

======
lwhi
" _2011-09-08 storechat.apple.com

A cross-site scripting issue was addressed. We would like to acknowledge "some
stupid nerd" for reporting this issue._"

Made me smile.

------
absconditus
"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.

------
abailin
Apple's credit page for people who have reported potential security
vulnerabilities: <http://support.apple.com/kb/ht1318>

~~~
justinschuh
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.

------
kogir
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.

~~~
fmavituna
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.

------
bobbles
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

~~~
MattBearman
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.

~~~
bobbles
Thanks for the explanation

------
brlewis
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.

~~~
tripzilch
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.

~~~
brlewis
Could you demonstrate that for me please?

Here's a simple little page that is vulnerable to XSS but not to CSRF:

<http://brlewis.com/demo/xss-csrf.html>

It works by GET or POST, so it should only take you a minute to craft a link
that you can post right here in HN that makes that page pop an alert up in my
browser.

~~~
mkjones
This should work: <http://mkjon.es/xss.html> (note that your server seems to
hang if I put "<script>" in the GET params, but assuming that works and thus
the page is vulnerable to XSS like you intended, then this works). Just
pretend the <img /> tag is a script tag.

Of course, this is kind of cheating - I exploit the fact that there's a CSRF
bug on your web site. But that's kind of the point - just saying "oh well this
is an XSS but it doesn't matter because this other unrelated thing prevents
it" is bad security. It's entirely possible, even likely, that someone will
come along at a later date and change that other seemingly-unrelated thing,
having no idea that they're introducing a security hole in the process.

~~~
brlewis
Cool! I'll look into the CSRF bug. EDIT: Using a vulnerability in another demo
page _definitely_ is cheating. But I do like the hack.

To be clear, "oh well this is an XSS but it doesn't matter" is not something I
ever said. I only ever said that most of the screenshots in the article don't
by themselves demonstrate a vulnerability on Apple's web sites.

EDIT 2: There was another demo on my server that let you set arbitrary
cookies. This exploit relied on setting the JSESSIONID cookie. If a similar
exploit existed on Apple's web site, presumably this would defeat the purpose
of the exploit, since the target user would no longer be authenticated as
him/herself. I changed the cookie demo not to allow arbitrary cookie names,
just to prevent it interfering with other demos.

~~~
mkjones
Sorry, didn't mean to put words in your mouth. I just wanted to point out that
even when it seems like an XSS doesn't demonstrate a vulnerability, some of
your assumptions may be wrong and it actually does.

Security is hard, let's go shopping!

~~~
brlewis
Then I think we agree: These examples might or might not be vulnerabilities,
though from appearances two of them seem very likely to be.

