Take the 2-minute tour ×

He guys,

I just read this post about really nasty (and cool at the same time) ways to perform XSS. However, there is still something unclear to me.

I understand the full concept of the attack, however, I dont see how this can potentially be exploited. The "action" attribute inside the form must point to a ftp server (or any other server that reflects input), but this is never the case.

So unless you have another XSS hole to inject such a form this vulnerability cannot be exploited. My question is if my conclusion that it cannot be exploited is true, or that im missing something?

share|improve this question
Nobody has an answer?? –  Henri Sep 6 '09 at 8:55
add comment

3 Answers

up vote 3 down vote accepted

This is exploitable as follows.

  • MrCrim wants to steal the login of someone that uses victim.net
  • MrCrim notices that victim.net is running an ftp server on an unusual port
  • MrCrim puts up a form on his own site, evil.com
  • The form contains the "ftp commands" in the form elements and its post action is to victim.net
  • MrCrim writes a JS script that steals document.cookie from a site and hosts that script in a .js file on evil.com. It probably works by including the cookie string as part of an image source URL that is requested from evil.com
  • One of the "ftp commands" in MrCrim's form is constructed to write a small bit of JS that executes MrCrim's cookie-stealing script
  • MrCrim tempts people to look at evil.com by posting links on forums and sending spam.
  • UnsuspectingUser follows a link posted in his favourite forum and lands at evil.com. He posts the form, not knowing of its evil and wily intentions
  • UnsuspectingUser is now on victim.net and Bam! the JS "injected" by the FTP server is executed and UnsuspectingUser's cookie for victim.net get's sent to evil.com
  • Profit! :-)
share|improve this answer
Ahhh, now I understand. I had mixed up the concept of referer and the same origin policy. I was thinking that the referer was not in the same domain as the ftp server. But now i get it. Thanks! –  Henri Sep 9 '09 at 20:15
add comment

I guess your argument is that no one runs FTP server on the same host as the HTTP server. You are correct if this assumption is true. It can't be exploited if you know for sure you don't have any other ports open.

To exploit this hole on IE, the host must have other services running and the port numbers must be non-standard. This is indeed rare. Lots of sites will have FTP on the same host but they normally use standard port number (21). However, this can happen though. My hosting company runs a FTP server on multiple ports (one has to be non-standard) on the same host where my webpage is served and that's alternative way to update the pages if the authoring tool doesn't support WebDAV.

share|improve this answer
add comment
  • Attack hosted in a different server,
  • FTP Server should hosted in the victim server
  • Since the attack gets its response from the victim server, now attacker's page can read cookies. Because now attackers code reflected into the target's domain context.

That's it.

So no you don't need another vulnerability, an FTP server or a similar server with publicly accessible port is enough to be vulnerable.

share|improve this answer
add comment

Your Answer


