Fremdes Javascript im Quellcode

Beitrag von **Synonym** » 12.05.2012, 16:15

Ich denke mal, das war irgendwie eine Spielerei. Das eigentliche Ziel gibt es nicht mehr, aber die Seite wird nun weitergeleitet. Also von "Server nicht erreichbar" ist nicht die rede, der ist erreichbar.

Hatte auch nur einen Dreher bei meiner URL-Auflösung drinnen, nun hab ich alle Buchstaben. Ist nicht .ru wie gedacht, sondern .au. Und die jetzige Zielseite ist ein Unternehmen für Schulungen und Weiterbildungen, habe ich zumindest so verstanden. Vielleicht war das ja "nur" ein Student von denen. Wie dem aber auch sei. Wenn der das kann, dann können es die richtig bösen auch.

von **Anzeige von ABAKUS** »

Beitrag von **multiple** » 12.05.2012, 16:54

Der Trick mit der JS-Datei hat nicht funktioniert. Wär auch zu einfach gewesen.

FTP-Zugangsdaten hatte ich natürlich als erstes geändert.

Ich gehe auch davon, dass es ein Problem beim Hoster ist. Hab auch schon andere Websitebetreiber gefunden, die das Gleiche haben. Ich werd den Hoster mal mit den Erkenntnissen hier konfrontieren. Mal sehen, ob das irgendwie eine Idee hervorbringt, aber ich vermute mal, dass nichts Anderes übrig bleibt, als das Weite zu suchen.

Nachtrag: Hab nun eine temporäre Umleitung zu einem anderen Webspace gebaut. Was Google davon hält, weiß ich nicht, ist aber auch egal, weil die Seite eh unten durch war.

Beitrag von **sx06050** » 12.05.2012, 16:56

genau, nix wie weg -> liegt definitiv am hoster (soll der doch mal suchen, wo das drecksteil herkommt)

Beitrag von **nerd** » 13.05.2012, 07:37

sx06050 hat geschrieben:genau, nix wie weg -> liegt definitiv am hoster (soll der doch mal suchen, wo das drecksteil herkommt)

Gut dass wir eine qualifizierte beurteilung der sachlage haben. Fehler oder technische inkompetenz eines kunden koennen ja immer ausgeschlossen werden

Beitrag von **Synonym** » 13.05.2012, 08:49

Gut dass wir eine qualifizierte beurteilung der sachlage haben. Fehler oder technische inkompetenz eines kunden koennen ja immer ausgeschlossen werden

Also in diesem Fall recht sicher sogar. Mehrere Webseiten, verschiedene Systeme, mal CMS, mal WP, mal was anderes und mal nur HTML, alle verschiedene Inhaber, alle der gleiche Server, alle das gleiche Script drinnen.

Selbst wenn da irgendwo ein Script / Webspace fehlerhaft ist, dann darf das nicht auf die anderen Kunden durchschlagen und das ist definitiv ein Problem vom Hoster.

Und die Antwort von dem spricht auch Bände, zumal das Problem nicht neu ist, sondern wohl schon seit 3 Wochen besteht.

Das ist aus meiner Sicht nur wieder der gleiche Punkt: 20,- EUR im Jahr an der falschen Stelle gespart.

Beitrag von **sx06050** » 13.05.2012, 08:51

genau so sehe ich das auch, da dieses problem nicht am threadersteller liegt

Beitrag von **Synonym** » 13.05.2012, 09:05

So, eben auch mal nachgesehen. 5 andere IPs haben das Problem auch. Natürlich könnten die auch alle auf dem gleichen Server liegen, aber das ist sehr sehr unwahrscheinlich.

Und der Kundenbereich bzw. die Adminoberfläche vom "Parallels Confixx" hat das Script auch drinnen.

Beitrag von **seonewbie** » 13.05.2012, 14:47

Das liegt nicht am Hoster.

1.) Alle .htaccess durchsuchen (Bis zum Ende scrollen auch wenn
da 3 Seiten nichts kommt)
3.) Durchsuche als erstes alle Verzeichnisse die 777 haben.
2.) Schaue ob in den 777 Verzeichnissen eine dir unbekannte
Datei liegt
4.) Durchsuche alle Datein die 777 haben scrolle bis zum ende

Die Injection ist garantiert nicht über deinen Hoster sondern über
ein schlechtes php script gekommen.

Ich bin mir sicher das Du was findest

Gruß

Micha

Beitrag von **chris21** » 13.05.2012, 14:56

@seonewbie, nerd:

Habt Ihr den Thread gelesen?

Fast alle Kunden eines Hosters sind betroffen.

Unterschiedliche CMS, IPs, teilweise nur HTML Seiten. Aber alle bei einem Hoster. Und da auch die Confixx Backends betroffen.

Beitrag von **multiple** » 13.05.2012, 18:51

@Synonym: Das ist der einzige Punkt, an dem ich mich schuldig bekenne: Beim Setzen auf einen Billig-Provider. Im Prinzip sollte die Seite nur ein Textarchiv werden und ein Versuchsballon, ob der Provider für Satellitenseiten brauchbar ist. Es hat auch in den eineinhalb Jahren keine Probleme gegeben, aber wie man sieht, wenn es Probleme gibt, dann hat man ein Problem.

Bis jetzt gibt es fast nichts im Netz über diese Geschichte. Ich hab einige Ergebnisse aus diesem Thread an den Provider übermittelt. Mal sehen wie die Auskunft morgen lautet.

Als Nutzer ist man übrigens geschützt, wenn man Cookies nicht zulässt. Kannst du das bestätigen?

Beitrag von **Aniel** » 13.05.2012, 19:54

Ich habe dieses Teil gestern auch bei mir im Quellcode entdeckt! Bin gerad durch google auf diesen Thread gestoßen.

Komischerweise verschwindet das Ding immer nach einem Refresh und kommt dann irgendwann wieder. WTF ist das?!

Auch die "LasVisit" Cookies erscheinen bei mir. Und noch eins namens "__utmz" von "flag.natese.gov.au"

Beitrag von **todo** » 14.05.2012, 07:28

Ich hoffe, du nutzt nicht Filezilla. Hab den Thread zwar nur überflogen, aber das war in letzter Zeit schon desöfteren das Problem.

Beitrag von **Synonym** » 14.05.2012, 09:47

Als Nutzer ist man übrigens geschützt, wenn man Cookies nicht zulässt. Kannst du das bestätigen?

Das kann ich nicht sagen, habe es nicht versucht. Normalerweise sind Cookies immer an und wenn man das erste mal auf der Seite ist, dann ist es ja schon zu spät.

Was ich aber sagen kann... Wenn der abschließende </body> fehlt, dann geht das Script auch nicht. Ist dann zwar nicht mehr valide, aber das Script versagt seinen Dienst

Bzw. Das Script selbst wird eingebunden, aber das iFrame nicht...

@Aniel
Ja, diese gov.au ist die Seite, an die weitergeleitet wird. Eigentlich ist das ein anderes Ziel. Das _umtz ist von Analytics auf der .au, also das ist kein Problem, aber eben auch auch nicht von Dir. Ist aber normal, da die Seite ja im iFrame geladen wird. Das lasvisit ist aber nicht normal.

@todo
hat mit Filezilla, dem lokalen PC oder den Webseiten nichts zu tun.

Beitrag von **multiple** » 14.05.2012, 10:48

Synonym hat geschrieben: Was ich aber sagen kann... Wenn der abschließende </body> fehlt, dann geht das Script auch nicht. Ist dann zwar nicht mehr valide, aber das Script versagt seinen Dienst Bzw. Das Script selbst wird eingebunden, aber das iFrame nicht...

Das ist ja immerhin etwas. Den Gedanken, das zu testen, hatte ich zwischendurch auch, aber dann hab ich die ganze Zeit mit den Cookies gekämpft, um das Setzen zu sabotieren. Hat aber nie hingehauen und dann war der Gedanke an den Body-Tag futsch.

Beitrag von **wvsgnovize** » 18.05.2012, 12:22

Das mit dem Entfernen des </body>-Tags ist eine Möglichkeit, es geht aber auch eleganter (und valider).

Schreib einfach den </body>-Tag folgendermaßen:

Code: Alles auswählen

<!-- SCRIPT CAGE
--></body>

Das Script wird immer in der Zeile direkt über dem </body> eingefügt, und in dieser Konstellation landet es dann als Kommentar im Quellcode. Das Script wird dann nicht einmal geladen.