Comments on: Apple.com XSS http://blog.phishme.com/2008/05/applecom-xss/ Internet Security Professionals comment on innovative phishing ploys, social engineering techniques, and the latest hacks. Bashing or bowing to the latest and greatest news in the security community. Keep up to speed with what phishers, hackers, and spammers are doing or just listen in on the latest geek rants. PhishMe is your one stop blog for the latest in anti-phishing and security news. Wed, 25 Aug 2010 07:51:26 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jash Sayani http://blog.phishme.com/2008/05/applecom-xss/comment-page-1/#comment-3189 Jash Sayani Thu, 26 Jun 2008 07: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 18: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 :)

]]>