Hallo Allerseites,
bei unserer Typo3 Installation wird anscheinend von außerhalb die Linkerzeugung manipuliert.
Die Typo3 generierten Links, manipulierten Links sehen z.B. so aus:
/index.php?id=38&L=http%3A%2F%2Ftornillo.com.mx%2Flist3.txt%3F
oder
/index.php?id=38&L=1&%20punkt%2012
Ein Update (schon eher eine Migration) von 3.8.0 auf 4.0.4 brachte nichts. Die relevanten Sicherheitsupdates sollten alle eingespielt sein.
Bei einer lokal laufenden Installation mit identischem Datenbestand, tritt der Fehler nicht auf.
Hat Jemand ähnliche Probleme gehabt und die lösen können?
Gruß Jürgen G.
versuche es doch mal mit realurl. allerdings wäre das ja nur ein mini workaround
Frescha schrieb
versuche es doch mal mit realurl. allerdings wäre das ja nur ein mini workaround
Hallo Frescha,
danke für den Tipp, aber manche Extensions mögen realurl nicht, deshalb wäre das für mich nur die letzte Verzweiflungstat.
Viele Grüße
Jürgen G.
siehe mein link, das hat nichts mit realurl zu tun
georg
Hallo Georg,
danke für den Link. Ich habe das gerade probeweise umgesetzt und werde das jetzt sehr gespannt beobachten.
Wenn ich das richtig sehe, bewirkt das, dass der Get-Parameter L nur dann mit den generierten Links durchgeschleift wird, wenn beim Aufruf der Seite selbiger bereits mit dem Wert 1 anhängt.
Allerdings hatte der Angreifer zuvor auch schon etwas an einen bestehenden L-Parameter angehängt:
/index.php?id=38&L=1&%20punkt%2012
Bin mir nicht im Klarem, was so erreicht werden sollte. Einmal hing vor Monaten eine rp57Shell dran und unsere Links hatten z.T auf fremde Seiten geführt, deshalb das komplett neue Setup. Und nun das; Na mal sehen.
Ich werde hier berichten.
Dank und Gruß Jürgen G.
du siehst das richtig.
aufgrund fehlender gehackter installationen kann ich eben nur raten und bin gespannt auf dein feedback
georg
Zwischenbericht
abschließend möchte ich noch nichts sagen, weil unserere Redakteurinnen krank sind und man den Effekt nur in ausgeloggtem Zustand sporadisch beobachten kann, aber:
bei meinen Probesitzungen ist bei Aufruf ohne L Parameter der Effekt bislang nicht mehr aufgetreten. Somit ist die Maßnahme schon einmal auf jeden Fall empfehlenswert.
bei Aufruf der englischsprachigen Seiten (bei uns L=1) wird teilweise und zu unregelmäßigem Zeiten zusätzlich an den normalen Wert für L (=1) ein Punkt angehängt. Dieser hängt dann wieder im Quelltext der Seite an der url.
Beispiel:
../index.php?id=64&L=1.
Das könnte auf versuchtes Cross-Site Scripting (XSS) hindeuten.
Ich werde noch ein zwei Dinge ausprobieren und dann ein abschließendes Feedback geben (falls ich es nicht vergesse).
@georg: Hast Du eine Idee wie es kommen kann, das falsche Get-Parameterketten in den Seitencache gelangen?
Gruß Jürgen G.
Hallo Jürgen,
danke für dein Feedback. Ahnung habe ich diesbzgl leider keine
georg
... wenn man den GET-Parameter L immer "mitschleppt", wird halt auch der Wert, den jemand da reinbastelt über die ganze Seite "mitgeschleppt" und landet (weil global eingestellt mit config.linkVars = L) natürlich auch im Cache.
Wenn config.linkVars = L aber in die "[globalVar = GP:L=1]"-Condition eingebaut wird, dann prüft der ja, ob der globale Parameter "L" den Wert 1 hat, erst dann wird er "mitgeschleppt".
Wenn da irgendein Scherzbold ein "&L=www.scriptkiddies-rule.com" an den URL anhängt, greift die Condition nicht & es wird auch nicht der L-Parameter "mitgeschleppt" ... 😉
Ich frage mich aber, inwiefern das eine Sicherheitslücke darstellt bzw. wie damit XSS realisiert werden soll ... o.O
chris3 schrieb
Wenn da irgendein Scherzbold ein "&L=www.scriptkiddies-rule.com" an den URL anhängt, greift die Condition nicht & es wird auch nicht der L-Parameter "mitgeschleppt" ... 😉
Ich frage mich aber, inwiefern das eine Sicherheitslücke darstellt bzw. wie damit XSS realisiert werden soll ... o.O
Probiere das doch mal aus, Chris, wenn Du "&L=www.scriptkiddies-rule.com" an eine URL-hängst, ist dies keineswegs bei erneutem Aufruf Bestandteil der generierten Menü-Link-URLs innerhalb der Seite. Ganz so einfach ist das also nicht. Irgendwo in diesem Forum hatte allerdings schon Jemand gepostet, wie es sich reproduzieren läßt, das diese Anhängsel in den Cache kommen.
Als unserer Auftritt gehackt war, waren diese URLs die Ziele der seitens Typo 3 generierten Menü-links. Also wurden unsere Besucher auf andere Seiten geleitet. Möglicherweise werden auf diese Art gehackte T3 Installationen mit schlüpfrigen Linkzielen versorgt.
Zum Glück trat dies nur sehr vereinzelt auf, und war mit dem Löschen des Caches kurzfristig beseitigt. Bis zum nächsten Mal jedenfalls.
Ich habe jedenfalls seitdem ein verschärften Blick auf die T3 Sicherheits-Mitteilungen.
Gruß Jürgen G.
Hi ihr,
lässt sich das nicht mit:
config.linkVars = L(0|1|2)
lösen? Schon gibte es nur noch 0, 1 und 2 als L-Variablen
beste Grüße
Sareen
Hallo Allerseits,
ja richtig, durch explizites setzen der erlaubten parameter via config.linkVars ließ sich das Problem (bei der neuen Installation) dauerhaft beheben.
Vielen Dank nochmals für Eure Tipps.
Gruß Jürgen G.
