11 Reaktionen zu “Sicherheitslücken in diversen TYPO3 Extensions”

Kommentare abonnieren (RSS) oder TrackBack URL

Und ich hatte mich schon gewundert, warum die Extension „aeurltool“ seit ein paar Tagen nicht im TER zur Verfügung steht.

Schade auch, dass der Author sich nicht gemeldet hat, um die XSS Lücke zu schließen. Was macht „Die Community“ in so einem Fall, wo eine Extension wie diese hier mehrere 1000 Mal installiert ist und der Author nicht mehr verfügbar ist?

Besteht nicht die Möglichkeit, dass jemand anderes die Extension übernimmt, die XSS Lücken entfernt und dann eine aktualisierte Version veröffentlich? Die Aufgabe würde zur Not sogar ich übernehmen 😉

Torben Hansen am 02. Februar 2012 um 15:23

@Torben: ich persönlich habe die Extension aeurltool schon immer für überflüssig gehalten, da sie zumindest für mich keinen direkten Mehrwert bietet.

Zur Frage nach der Übertragung eines Extension Keys: du könntest versuchen, den Autor der Extension per Mail zu kontaktieren (Andreas Eberhard ).
Alternativ kannst du die Admins (admin[at]typo3.org) bitten, den Key auf dich zu übertragen. Das sollte dann aber mit dem Security Team (security[at]typo3.org) abgesprochen werden.

Peter Kraume am 02. Februar 2012 um 15:49

@Peter: Ich empfand es immer als Mehrwert die RealURL Konfiguration direkt in einem Backend-Modul bearbeiten zu können und nicht per FTP oder Shell. Was gibt es denn für Alternativen – oder braucht man überhaupt welche? Man könnte ja auch die Konfiguration als Textdatei ins Fileadmin zu legen und dann RealURL so einzustellen, dass er die Textdatei als Config nimmt. Das würde die Extension überflüssig machen und man könnte weiterhin direkt im Backend die Konfiguration bearbeiten. Gibt es da einen „empfohlenen Weg“?

Torben Hansen am 02. Februar 2012 um 16:26

@Torben: man kann doch schon seit einiger Zeit in den EM Einstellungen von RealURL den Pfad zur Konfigurationsdatei angeben. Allerdings finde ich nicht, dass die Konfiguration in fileadmin gehört.
In der Regel wird die realurl_conf.php ja eh nur während der Entwicklungsphase geändert und dann mache ich das üblicherweise mit einer PHP IDE. Im späteren Live Betrieb kann man ja zur Not noch den Quixplorer verwenden.
Einen „empfohlenen Weg“ gibt es übrigens nicht.

Peter Kraume am 02. Februar 2012 um 16:40

@Peter: Danke. Dann mache ich mich mal ran ein paar Seiten umzustellen 🙂

Torben Hansen am 02. Februar 2012 um 16:50

Hallo,

noch was als Mitglied des Security-Teams: Wenn wer die Extension übernehmen will + fixen will, dann spricht da aus Security-Team-Sicht nichts dagegen.

Georg Ringer am 03. Februar 2012 um 15:42

Ich habe die REAL URL Konfiguration mit in die localconf.php geschrieben. Da spricht doch nix dagegen? Oder?

Pat am 06. Februar 2012 um 13:24

Ich persönlich finde, dass die RealURL Konfiguration nichts in der localconf.php zu suchen hat, da diese dadurch nur unübersichtlicher wird.

Besser nutzt man die realurl_conf.php, so wie von RealURL vorgeschlagen.

Peter Kraume am 06. Februar 2012 um 13:31

Ok Danke

Pat am 06. Februar 2012 um 13:33

Also ich finde zB. die 404er-Behandlung mit „aeurltool“ enorm einfach und problemlos…und mit der realurl-config kombiniert eine super einfache Ext (gerade wenns um kleine Seiten geht, wo man nicht viel Zeit investieren will)!!!

Verdammt verdammt…ich bräuchte sie grade dringen und es gibt sie nicht 🙁

precom Rainer am 13. Februar 2012 um 13:40

Da auch ich ein Fan von der Extension „aeurltool“ bin, habe ich mit Freude festgestellt, das es unter dix_urltool mit der Version 0.1.1 weitergeht.
Installation verlief einfach.
dix_urltool importieren, installieren und durchklicken – es werden die alten Einstellungen vererbt!
Danach kann man die alte Ext. deinstallieren und/bzw. mit dem Extension Manager restlos entfernen (Wartung).

Möge es immer so einfach weitergehen 😉

Hendrik am 19. März 2012 um 14:32

Kategorien

Archiv