7 ms·

10x XSS on apple.com

172 points by nilsjuenemann 15y ago

bobbles 15y ago
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
- o1iver 15y ago
  You can see from the dialog windows, that he could inject javascript.
  - itsnotvalid 15y ago
    Actually the dialogs are JavaScript provided by Apple, e.g. that prompt() on first screenshot.
    - marcomonteiro 15y ago
      No it's not. Look at the address bar. He injected that image tag with a value that would cause an error (the x value as opposed to a valid image url) which triggers the onerror javascript to execute. In this case it prompts the user but it could have been anything really.
      - itsnotvalid 15y ago
        I think you completely missed my point. I am simply pointing out prompt()is provided by Apple just like alert() provided by JS itself. Before coming to a conclusion that you can point to and say someone is wrong, please understand that not everyone here is a master of English.
        marcomonteiro 15y ago
        prompt() is a built in JavaScript function just like alert(). It isn't Apple specific, that's my point.
- MattBearman 15y ago
  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 15y ago
    Thanks for the explanation
brlewis 15y ago
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.
- jlongster 15y ago
  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.
  - brlewis 15y ago
    That attack fails if the page prevents CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...
    - jlongster 15y ago
      Not if the page simply a normal page that you would type in your URL. CSRF doesn't make sense there. I could send you a link to facebook.com with an embedded script.
      - brlewis 15y ago
        If the page accepts URL parameters or POST data, CSRF makes perfect sense.
        judofyr 15y ago
        > If the page accepts URL parameters … CSRF makes perfect sense. No, it doesn't. CSRF makes perfect sense when there is data on the server that is being modified by a request. A simple "search.php?query=…" doesn't need CSRF protection. If you're passing parameters that modify the server in the URL (instead of a part of the post data) you're using HTTP wrong and adding CSRF protection in the query string is the wrong solution.
abailin 15y ago
Apple's credit page for people who have reported potential security vulnerabilities: http://support.apple.com/kb/ht1318 http://support.apple.com/kb/ht1318
- justinschuh 15y ago
  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.
lwhi 15y ago
"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.
- deleted 15y ago
  [deleted]
absconditus 15y ago
"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.
kogir 15y ago
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 15y ago
  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.

172 points by nilsjuenemann 15y ago

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

o1iver 15y ago
You can see from the dialog windows, that he could inject javascript.
- itsnotvalid 15y ago
  Actually the dialogs are JavaScript provided by Apple, e.g. that prompt() on first screenshot.
  - marcomonteiro 15y ago
    No it's not. Look at the address bar. He injected that image tag with a value that would cause an error (the x value as opposed to a valid image url) which triggers the onerror javascript to execute. In this case it prompts the user but it could have been anything really.
    - itsnotvalid 15y ago
      I think you completely missed my point. I am simply pointing out prompt()is provided by Apple just like alert() provided by JS itself. Before coming to a conclusion that you can point to and say someone is wrong, please understand that not everyone here is a master of English.
      - marcomonteiro 15y ago
        prompt() is a built in JavaScript function just like alert(). It isn't Apple specific, that's my point.
MattBearman 15y ago
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 15y ago
  Thanks for the explanation

brlewis 15y ago

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.

jlongster 15y ago
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.
- brlewis 15y ago
  That attack fails if the page prevents CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prev...
  - jlongster 15y ago
    Not if the page simply a normal page that you would type in your URL. CSRF doesn't make sense there. I could send you a link to facebook.com with an embedded script.
    - brlewis 15y ago
      If the page accepts URL parameters or POST data, CSRF makes perfect sense.
      - judofyr 15y ago
        > If the page accepts URL parameters … CSRF makes perfect sense. No, it doesn't. CSRF makes perfect sense when there is data on the server that is being modified by a request. A simple "search.php?query=…" doesn't need CSRF protection. If you're passing parameters that modify the server in the URL (instead of a part of the post data) you're using HTTP wrong and adding CSRF protection in the query string is the wrong solution.

abailin 15y ago

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

justinschuh 15y ago
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.

lwhi 15y ago

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

deleted 15y ago
[deleted]

absconditus 15y ago

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

kogir 15y ago

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 15y ago
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.