Comments on: Apple.com XSS http://blog.phishme.com/2008/05/applecom-xss/ Posts about innovative phishing ploys, social engineering techniques, and the latest hacks. PhishMe is your one stop blog for the latest in anti-phishing and security news. Sat, 04 Feb 2012 10:16:28 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Jash Sayani http://blog.phishme.com/2008/05/applecom-xss/comment-page-1/#comment-3189 Jash Sayani Thu, 26 Jun 2008 02:40:35 +0000 http://blog.phishme.com/?p=114#comment-3189 TAMPERING WITH THE URL...... THIS IS COOL! :) TAMPERING WITH THE URL……

THIS IS COOL! :)

]]> By: MikeA http://blog.phishme.com/2008/05/applecom-xss/comment-page-1/#comment-3159 MikeA Sat, 24 May 2008 13:18:34 +0000 http://blog.phishme.com/?p=114#comment-3159 4. Here is the kinda far fetched part: you need to hope/pray/socially engineer/somehow get the victim to go through the password change process, and authenticate. I dont think that this is all that far fetched. I know I for one would be concerned to see a password reset email when I know I didn't request that, but I know lots of people that wouldn't. Also, as you need to go through this process to access the site, it's very likely that someone would go through the process anyway (maybe resetting back to their original password) while they remember to do it. What would interest me is not browser ownership via XSS, but if the login/session was for developer.apple.com, or *.apple.com (as G does). That would be a nice vector for CSRF, which with XSS most current mitigation techniques are useless :) 4. Here is the kinda far fetched part: you need to hope/pray/socially engineer/somehow get the victim to go through the password change process, and authenticate.

I dont think that this is all that far fetched. I know I for one would be concerned to see a password reset email when I know I didn't request that, but I know lots of people that wouldn't. Also, as you need to go through this process to access the site, it's very likely that someone would go through the process anyway (maybe resetting back to their original password) while they remember to do it.

What would interest me is not browser ownership via XSS, but if the login/session was for developer.apple.com, or *.apple.com (as G does). That would be a nice vector for CSRF, which with XSS most current mitigation techniques are useless :)

]]>