Thema: Safer ***tensions by Register_Globals=Off

Zitat von mero

Hallo Ihr Joomla-ExpertInnen,

Moin,

was ist mit uns Männern? Spass beiseite,, schau hier und folge dem Ratschlag, gilt für alle..
http://www.joomlaportal.de/sicherhei...nd-module.html

Hallo Mero,

eine solche Blacklist ist mir nicht bekannt. Sie wäre auch sehr aufwendig zu pflegen, da man ständig den Entwicklern hinterherlaufen und eventuelle neue Versionen der Komponenten prüfen müßte.

KO-Kriterium 1: Du hast eine Extension heruntergeladen, und im Readme steht, daß register_globals auf ON stehen muß ==> Tonne.

KO-Kriterium 2: Du hast auf Deinem Testsystem (das logischerweise register_globals OFF hat) eine Extension installiert, und sie läuft nicht ==> Tonne.

Viele Grüße,
Zorro

Zitat von cybergurk

was ist mit uns Männern?

Ey, danke Euch 2 Männers, für die schnellen Hinweise. Und was den Platzbedarf von german_genderneutral.php angeht: Der kleine UnterschIed fällt kaum auf

Zitat von Zorro

eine solche Blacklist ... wäre auch sehr aufwendig zu pflegen, da man ständig den Entwicklern hinterherlaufen und eventuelle neue Versionen der Komponenten prüfen müßte.

Ja klar, wir hatten beim Mamboday schon mal darüber debattiert. Ich hab nicht an so ne aufwändige "Stiftung Joomlatest" gedacht.

Zitat von Zorro

KO-Kriterium 1: Du hast eine Extension heruntergeladen, und im Readme steht, daß register_globals auf ON stehen muß ==> Tonne

Meine Überlegung ist, dass Du eine derart eindeutige ==>Tonne Entscheidung bei ner Sammelstelle postest (falls dort noch keine steht). Mehr Aufwand muss nicht sein.
Wenn ein Entwickler unbedingt vom Pranger losgebunden werden will, muss er sich selbst rühren. Oder halt nicht. Es steht ja auch jedem User frei, die Prangerliste nicht zu beachten oder neue Erkenntnisse zu posten.
Wenn es gut läuft, entwickelt sich eine Art anders sortierter BugTracker, der zu einem kritischen Bug alle Extensions listet, die davon betroffen sind bzw. waren..

Naja, vielleicht überschätze ich die Community da...

Zitat von Zorro

KO-Kriterium 2: Du hast auf Deinem Testsystem (das logischerweise register_globals OFF hat) eine Extension installiert, und sie läuft nicht ==> Tonne.

Genau da knackt´s dann beim J-Laien, denn es gibt noch ein paar andere Gründe, warum was nicht läuft. Ich finde es völllig in Ordnung und zumutbar, wenn diejenigen "My Joomlatest" durchspielen, die das fachlich auch können.
Doch Joomla ist ja grad als Newbie-freundlich positioniert und inzwischen wegen der Verbreitung auch securitymäßig besonders exponiert. Dass ein hoher Laien-Anteil (ich möchte den Gebrauch von DAU hier vermeiden) nervt, ist mir schon klar.
Darum
Kriterium 0: Extension stand schonmal in der RGon-Liste
Dann kann jeder entscheiden, ob das ein KO-Kriterium ist oder nur ein Grund, sich tiefer reinzufuchsen und (ggfls. eine PHP-Zeile reinzuflicken o.ä.)


Also, nochmal Danke an Euch , mir persönlich ist mit Euren Tipps geholfen, ich werde fleißig englische Security-Notes lesen

Mero

Zitat von headcrash

Nichts desto trotz wäre eine Institution, die mit der Mambofoundation geplant war (leider katastrophal in der Umsetzung) hilfreich, die eine Zertifizierung von Komponenten etc. realisiert.

Halte ich für unrealistisch. Das Suchen, Nutzen und Stopfen von Sicherheitslücken ist ein Hase-Igel-Spiel. Eine dauerhafte Aussage, daß ein Script sicher ist, ist gar nicht möglich. Deshalb sollte man vermeiden, den EIndruck zu erwecken, eine einmal zertifizierte Komponente sei "sicher". Wenn, dann muß man ganz vorsichtig formulieren, daß die Komponente am Tag X keine bekannte Sicherheitslücke aufwies. Sobald auch nur die kleinste Chance besteht, in "zumindest nicht bekannt unsicher" "sicher" hineinzuinterpretieren, schläft Otto Normaldau wieder für die nächsten zwei Jahre den Schlaf des Gerechten und interessiert sich weder für Sicherheitswarnungen noch für Updates.

Besser ist es, wenn im Hinterkopf jedes Script potentiell unsicher bleibt und einige Ausnahmen erwiesenermaßen unsicher sind. Erweist sich ein Script eine Woche nach seiner Zertifizierung als unsicher, haben weder der Programmierer noch der Hacker den schwarzen Peter, sondern der, der am wenigsten dafür kann: Der Zertifizierer.