2009-09-05 1 views
5

Er Jungs,Kreuz-Protokoll XSS mit Nicht-Standard-Service-Ports

Ich habe gerade gelesen this Post über wirklich böse (und cool zugleich) Möglichkeiten XSS auszuführen. Allerdings ist mir immer noch etwas unklar.

Ich verstehe das vollständige Konzept des Angriffs, aber ich sehe nicht, wie dies potenziell ausgenutzt werden kann. Das Attribut "action" im Formular muss auf einen FTP-Server (oder einen anderen Server, der die Eingabe widerspiegelt) zeigen. Dies ist jedoch nie der Fall.

Wenn Sie also kein weiteres XSS-Loch haben, um ein solches Formular zu injizieren, kann diese Sicherheitsanfälligkeit nicht ausgenutzt werden. Meine Frage ist, ob meine Schlussfolgerung, dass es nicht ausgenutzt werden kann, stimmt, oder dass ich etwas verpasst habe?

+0

Niemand hat eine Antwort ?? – Henri

Antwort

3

Dies kann wie folgt genutzt werden.

  • MrCrim will das Login von jemandem stehlen, die victim.net verwendet
  • MrCrim dass victim.net bemerkt auf einem ungewöhnlich Port
  • MrCrim erträgt ein Formular auf seiner eigenen Website einen FTP-Server ausgeführt wird, evil.com
  • Das Formular enthält die „fTP-Befehle“ in der Formularelemente und deren Beitrag Aktion ist
  • MrCrim schreibt ein JS-Skript victim.net die document.cookie von einer Website stiehlt und beherbergt das Skript in ein. js Datei auf evil.com. Es funktioniert wahrscheinlich, indem die Cookie-Zeichenfolge als Teil einer Bildquelle URL, die von evil.com angefordert wird
  • Einer der "FTP-Befehle" in MrCrims Form ist konstruiert, um ein kleines bisschen von JS zu schreiben, die MrCrims Cookie-Stehlen ausführt Skript
  • MrCrim verführt Leute dazu, sich evil.com anzuschauen, indem sie Links in Foren posten und Spam versenden.
  • NoscopingUser folgt einem Link in seinem Lieblingsforum und landet auf evil.com. Er postet die Form, nicht wissend über seine bösen und schlauen Absichten
  • NoscopingUser ist jetzt auf victim.net und Bam! Der vom FTP-Server "injizierte" JS wird ausgeführt und der Cookie von usseroscapingUser für victor.net wird an evil.com gesendet.
  • Profit! :-)
+0

Ahhh, jetzt verstehe ich. Ich hatte das Konzept der Referer und die gleiche Herkunft Politik durcheinander gebracht. Ich dachte, dass der Referer nicht in der gleichen Domäne wie der FTP-Server war. Aber jetzt verstehe ich es. Vielen Dank! – Henri

0

Ich denke, Ihr Argument ist, dass niemand FTP-Server auf dem gleichen Host wie der HTTP-Server ausgeführt wird. Sie haben Recht, wenn diese Annahme zutrifft. Es kann nicht ausgenutzt werden, wenn Sie sicher sind, dass Sie keine anderen offenen Ports haben.

Um diese Lücke im IE zu nutzen, müssen auf dem Host andere Dienste ausgeführt werden und die Portnummern müssen nicht standardgemäß sein. Das ist in der Tat selten. Viele Websites haben FTP auf dem gleichen Host, aber normalerweise verwenden sie die Standardportnummer (21). Dies kann jedoch passieren. Mein Hosting-Unternehmen führt einen FTP-Server auf mehreren Ports (einer davon muss nicht standard sein) auf demselben Host aus, auf dem meine Webseite geliefert wird. Dies ist eine alternative Möglichkeit, die Seiten zu aktualisieren, wenn das Authoring-Tool WebDAV nicht unterstützt.

0
  • Angriff in einem anderen Server gehostet,
  • FTP Server sollte
  • in dem Opfer-Server gehostet Da der Angriff seine Antwort vom Opfer-Server bekommt, Seite jetzt Angreifer Cookies lesen kann. Weil jetzt der Code des Angreifers in den Domänenkontext des Ziels reflektiert wird.

Das ist es.

So nicht Sie keine andere Verwundbarkeit brauchen, einen FTP-Server oder einen ähnlichen Server mit öffentlich zugänglich Port ist genug, verletzlich zu sein.