Ver. 2.7 gehacked, alle index Seiten mit <iframe> versehen

[Hans>NULL]

@gottfried
Die Rechte müssen gesetzt werden können (Server ja, andere nee)
Ansonsten kann man die auch oberhalb von WWW plazieren.
Auch bei einem "Bilighoster" sollte man das jedenfalls können dürfen, sonst schmeiß wech.
Ein Telefonat mit dem Support gibt Aufklärung darüber, ob er gewillt ist, PHPIDS aktiv werden zu lassen, ist es doch auch zu seinem Vorteil.
Gruß, Hans>NUL

Erste Schritte mit der Einbruchserkennung PHPIDS
http://www.infinite-fire.net/tutorials
Weil alle ganz gern lesen: Serverfrieden: PHP-Anwendungen individuell absichern

[Hans>NULL]

Das Index-Gehacke ist eigentlich bekannt und wurde im Forum (früher, beim Kaiser...) auch schon mal erwähnt.
Aber alles wie gehabt, die Hoster haben nix gelernt und die User eben auch nicht.
Paßt doch    
Gruß, Hans>NUL

[doc]

Hi,

Mal 'nen Vorschlag dazu... Auf vielen Seiten - etwa zu phpMyFAQ - gibt's eine Seite mit "Security Announcements". Man könnte doch ein entsprechendes Forum eröffnen und die aktuellsten 5 Threads auf der Startseite der WB-Homepage in einem Kasten anzeigen lassen. Und in dem Forum werden dann halt Meldungen über geklärte (!!!) Hacks und gefixte Module veröffentlicht.

Genau darum gings mir in Post 13 oder Post 15. Also ja, sowas sollte auf die WB Homepage. Danke fürs verstehen  

ann mich dem nur anschließen. Das Board über Security Annoncements gibt es ja bereits

Das Board ist Klasse, aber da sollten dann eben solch sicherheitskritisch en Sachen wie der FCKEditor gepostet werden. Ein guter erster Schritt, aber etwas mehr Infos würden nicht schaden.

@Hans>NULL (Post #51):
Danke für den Link, recht interessant.

Habe das Gefühl, dass wir mit diesem Thread auf dem richtigen Weg sind. Hatte nach den ersten Posts ja so meine Bedenken, aber die letzten Posts sind wieder deutlich konstruktiver geworden

Gruss Doc

[WebBird]

@doc - ja, irgendwie hatte ich das Gefühl, aber es weckte bei mir auch das Bedürfnis, es nochmal in andere Worte zu fassen.

[WebBird]

Ich war grad nochmal eben im Security Board und hätte da noch eine Anregung: Man sollte dort IMHO Antworten verbieten. Diskussionen über die Announcements sollten woanders geführt werden. (Kann man dann ja im Announcement verlinken.) Oder man macht's halt andersrum, ein geschlossenes Board für die Ankündigung und das jetzige weiterhin für Diskus.

Die Announcements sollten fundiert, knapp und sachlich sein, was Diskus in der Regel nicht sind.

Edit: Hier ein Beispiel von phpmyfaq.de
http://www.phpmyfaq.de/advisory_2009-06-02.php

[erpe]

Hallo

ich finde, es sollte kein Sub-Board sein.
Das ist jetzt das erste Mal, dass ich das gesucht und gefunden habe.
Ansonsten will ich mich Webbird anschliessen: Infos = Ja, Diskussion dort = Nein

Gruss

erpe

[WebBird]

Ich hab's gestern auch vergeblich gesucht, obwohl ich wußte, daß es da ist.

[Luisehahne]

Ansonsten will ich mich Webbird anschliessen: Infos = Ja, Diskussion dort = Nein

Ein Board für Diskussionen und ein Board für Infos? Funktioniert das?

Dietmar

[erpe]

Ich denke ja, weil bei den Announcements "nur" die Ergebnisse/Erkenntnisse/Verhaltensweisen etc gepostet werden, die im Diskussionsthread entstanden sind oder Informationen, die von anderen Seiten (z.B. FCKEditor) kommen.

Gruss

erpe

[WebBird]

Ein Board für Diskussionen und ein Board für Infos? Funktioniert das?

Sagen wir mal so - das Info-Board soll ja nur aus Gründen der Bequemlichkeit ein Board sein. Es hat halt den Vorteil, daß es sowohl hier im Forum als auch auf der HP eingeblendet wird / werden kann, ohne daß man großen Aufwand betreiben muß. Ansonsten hätte ich halt gesagt, macht 'ne entsprechende Seite, analog zu phpmyfaq.de.

Im Announcement selbst kann man zugrundeliegende Diskussionen verlinken, und in der Diskussion wiederum das Announcement.

Ich sehe da keine Probleme.

[doc]

@WebBird:
Yepp, sehe ich genauso. Das Security board erlaubt u.a. die Erstellung von RSS Feeds etc. oder die Einbindung von Security News auf der WB Homepage. Wie könnte man die Module handeln, die auf der Projektseite und auf AMASP angeboten werden?

Gruss Doc

[WebBird]

Vielleicht zwei getrennte Boards, Core und Module?

[mr-fan]

-> wb security board unter General gleich bei announcements....
    ->third party componenten mit sicherheitslücken
    ->unterboard module mit sicherheitslücken

=>core + third party auf der HP per rss einbinden

=> bei offiziell in diesem bord bekannten schwächen deutliche kennzeichnung auf AMASP mit link zum board (wenig doppelter 
      pflegeaufwand)

es wären so die drei boards zu betreuen und bei bedarf module auf AMASP zu kennzeichnen....

ist das sinnvoll oder gäbe es bessere lösungen?

mfg martin

[erpe]

Warum will man denn zwischen Core und Modulen (und dann noch Addon und AMASP) unterscheiden?

Geht doch um Sicherheit und ist dann doch egal, ob es sich um Core oder Module handelt.
Am Besten ist doch alle Infos zu einem Thema auf einen Blick.
Kann sich doch dann jeder raussuchen, was für ihn relevant ist.
Wichtig ist aber auch, dort dann einzutragen, wenn etwas erledigt ist, z.B ein Bugfix angeboten wird oder eine neue Modulversion etc......

Gruss

erpe

EDIT: Klar sollte dann bei Modulen von AMASP / Modul ein Link auf der entsprechenden Page eingetragen werden (hoffe, es sind nicht so viele.....).

[WebBird]

Warum will man denn zwischen Core und Modulen (und dann noch Addon und AMASP) unterscheiden?

Könnte der Übersichtlichkeit förderlich sein. Und da vermutlich mehr Probleme in Modulen als im Core auftreten, ist es vielleicht auch für die Optik besser, das zu trennen.

Edit: Wobei ich Module nicht weiter aufteilen würde.

[erpe]

Ist im Grunde wurscht, ob getrennt wird nach Core / Modulen oder nicht.

Vielleicht fängt man erstmal an und sieht dann, je nach Übersichtlichkeit, ob es Sinn macht zu trennen oder nicht.

Mir wäre schon wichtig, dass man dann da aber über Fakten spricht und nicht Vermutungen/Eventualitäten/Gerüchte.

Die können meinetwegen dann in den Threads diskutiert werden.

erpe

[WebBird]

Jo, seh ich auch so. Nichts ist schlimmer als Halbwissen, das als Tatsache weitergegeben wird.

[ruebenwurzel]

Hallo,

so in einem ersten Schritt ist jetzt mal das Security Board kein Unterboard mehr. Wie damit weiter verfahren wird (zusätzliche Unterboards, Trennung core + module, rssfeed auf startseite ....) wäre schön, wenn sich da ein "Sicherheitsteam" bilden könnte, das da die Verantwortung übernimmt.

Sprich wer testet was nach welchen Kriterien, ab wann ist was tatsächlich ein sicherheitsloch, wer fixt es, wann wird es veröffentlicht.

Matthias

[FrankH]

Sprich wer testet was nach welchen Kriterien, ab wann ist was tatsächlich ein sicherheitsloch, wer fixt es, wann wird es veröffentlicht.

Testen könnte ich auch mit, das sollten in jedem Falle mehrere Leute machen in verschiedenen Umgebungen.
Fixen darf ja eh nicht jeder, im Idealfall sollte ja zu jeder Datei der verantwortliche Entwickler feststehen. Wenn der im Urlaub ist, muss aber auch kurzfristig ein anderer einspringen.
Veröffentlichung macht nur Sinn nachdem der Fix verfügbar ist, es kann aber auch vorkommen, daß ein Loch schon vorher publik wird, dann ist meist eh alles zu spät.

[doc]

Hi,

wie FrankH schon angedeutet hat, wäre es hilfreich für jedes Modul noch ein paar Zusatzinfos bereit zu stellen:

• Gewartet / maintained: ja / nein (wenn ja, Link mit PM zum Autor)
• 3rd party code (Lizenz, Version + Link auf Homepage)

Das gäbe einen schnellen Überblick, ob ein Modul überhaupt noch aktiv weiter entwickelt oder gepflegt wird. Wird es nicht, können andere Entwickler dies evtl. übernehmen. Oft verwenden Module auch 3rd Party code (JS, PEAR ...). Da sollte zumindest die Version und ein Link zur Quelle gepostet werden, damit man schnell prüfen kann, ob es evtl. kritische Updates gibt.

Doc

P.S.: Auf jeden Fall schon mal gut, dass das Security Board nun kein Unterboard mehr ist sondern an prominenterer Stelle angzeigt wird 

[WebBird]

Ich denke, wir sollten ein Template erarbeiten, damit die Einträge im Board einheitlich sind.

[FrankH]

Na es betrifft nicht nur die Module, auch den Core.
Eigentlich sollte in jeder Distribution eine Möglichkeit erwähnt werden, wie man sicherheitskritisch e Probleme melden kann.
Das kann eine email-Adresse sein oder ein Webformular, ein Forumsbeitrag wäre dagegen keine gute Idee, weil damit ja vor dem Fix die Veröffentlichung erfolgt.

[ruebenwurzel]

Hallo,

Na es betrifft nicht nur die Module, auch den Core.
Eigentlich sollte in jeder Distribution eine Möglichkeit erwähnt werden, wie man sicherheitskritisch e Probleme melden kann.
Das kann eine email-Adresse sein oder ein Webformular, ein Forumsbeitrag wäre dagegen keine gute Idee, weil damit ja vor dem Fix die Veröffentlichung erfolgt.

100% Zustimmung. Bin gespannt ob sich ein "Security team" findet, das genau das dann in die Wege leitet.

Matthias

[WebBird]

Das kann eine email-Adresse sein oder ein Webformular, ein Forumsbeitrag wäre dagegen keine gute Idee, weil damit ja vor dem Fix die Veröffentlichung erfolgt.

Ich hab auch nicht gemeint, daß Sicherheitsprobleme per Forenbeitrag gemeldet werden sollen. (Also von demjenigen, der ein Problem festgestellt hat.) Mir ging es um das Format des "Bulletins", mit dem das dann "offiziell" gemeldet wird. Halt analog zu phpmyfaq.de oder von mir aus auch Microsoft. Das erleichtert es auch dem "Sicherheitsteam", die Beiträge zu gestalten.

[doc]

Hi,

habe zu einigen meiner früheren Thread Aussagen noch ein wenig im WWW gestöbert.

Infos zum weiteren Absichern von WB:
 - Servereinstellungen (E_NONE, register_globals, magic_quotes = on, open basedir, url_fopen_wrappers, safe mode)
 - Zusätzliche Absicherung (/admin umbenennen -> kein Frontend Login, zusätzlicher .htaccess Schutz, mod_security ...)
 - Dateirechte von Dateien und Ordnern (644, 750 ...)
 - WB Zugriffsrechte: Code Module ist nur für Admins (wer Zugriff darauf hat kann fast alles machen)
 - Umgang mit Addons: Nur installieren was benötigt wird, Referenzen einholen, kein Modul ist wirklich sicher
 - Liste mit benötigten Infos, falls man denkt ein Server wurde gehackt (welche Daten brauchts wofür)
 - Entwicklerleitfaden für Module / Templates (mit Abschnitt über Addon Sicherheit)

Beispiele:
http://docs.joomla.org/Category:Security_Checklist
http://wiki.cmsmadesimple.org/index.php/How_to#How_to_Secure_CMSMS_system_-_Small_Guide

Melden von Sicherheitslücken:
Wie hier bereits diskutiert:
 - Form auf der WB Seite um Sicherheitslücken zu melden
 - Sobald gefixt (z.B. SVN, oder Module), Meldung im WB Security Thread erstellen (Support für Forumsprachen?)
   (im Forumthread nicht diskutieren, aber Problem umreissen und Link zur Anleitung zum Fixen posten)
 - RSS Feed oder Newsletter zu Sicherheitsmeldunge n (Core, Module ...)

Was ist ein Bug. Nun alles was die Sicherheit einer Anwendung oder des Servers gefährdet und zwar unabhängig von den Servereinstellungen . Wenn sich Module auf register globals oder magic quotes verlassen, ist das eine Sicherheitslücke des Moduls, nicht des Servers. Mann kann in einem solchen Fall darauf Hinweisen, dass ein Exploit z.B. register globals = On oder magic quotes = Off voraussetzt. Ändert aber nichts an der Tatsache, dass das Modul ein Sicherheitsloch enthält.

Zusatzinfos für Module:
 - Wird das Modul noch gepflegt, wenn ja von wem (bzw. Kontaktadresse via Forums-PM, Kontaktformular des Entwicklers)
 - Infos über 3rd Party Code (Javascript, PHP ...) inkl. verwendeter Version und Link zur Herstellerseite (z.B. Für WB Xinha Editor die verwendete Xinha Version + Link auf Xinha Homepage)
 - Download eines Moduls nur wenn zuvor abgeklickt wurde, dass das Modul trotz Prüfung (wenn es denn welche gibt) kritische Sicherheitslücken enthalten kann, welche die Übernahme des Servers etc. ermöglichen (DEUTLICHER DISCLAIMER)

Denke es gibt noch genug andere Sachen die man tun könnte, wollte mal ein paar zur weiteren Diskussion hier einbringen.

Gruss Doc