Und noch ein Problem (German / Deutsch)

by Birgit ⌂, Monday, September 13, 2010, 07:12 (4975 days ago) @ Auge
edited by Birgit, Monday, September 13, 2010, 07:36

Hallo Auge,

Welche Version war denn auf dem alten Server installiert? Das Changelog gibt Auskunft über die Änderungen der einzelnen Versionen, ich möchte aber nicht alles durchsuchen müssen um etwaige Änderungen an den relevanten Stellen zu finden.

Tja, schon wieder ein Irrtum. Es war die gleiche Version installiert wie die jetzige. Ich wusste das nicht, da ich das Forum damals nicht selbst installiert hatte und mir gesagt wurde, dass es schon eine Nachfolge-Version gibt.

Nun gut. Wäre auch zu einfach gewesen. :-)

Stimmt. ;-)

Während der Entwicklung von PHP-Skripten arbeitet man am besten mit der Anzeige aller Meldungen, die PHP einem liefert. So spürt man von Parsing-Fehlern bis zur nicht initialisierten Variable alle Fehler, die dem PHP-Interpreter aufstoßen, auf. Die Meldungen werden im Browser ausgegeben. Das geschieht mit folgendem Code am Anfang eines jeden direkt aufzurufenden Skripts.

ini_set('display_errors', 1);
error_reporting(E_ALL);

Im laufenden Betrieb ist das aber kontraproduktiv. Einerseits sollten dann keine solchen Meldungen erscheinen, weil man deren Ursachen beseitigt hat, andererseits verunsichern sie die einen Benutzer und geben anderen (den "Bösen") Anhaltspunkte für Angriffsszenarien. Deshalb landen dennoch anfallende Meldungen dann in einer Datei auf dem Server außerhalb der DocRoot, wo nur du als Admin (z.B. per FTP) Zugriff hast. Für Meldungen, die von MySQL stammen, gilt das Gleiche. Während der Entwicklung gehören sie in die Browserausgabe, danach in die Logdatei.

In deinem Fall liegt die Sache etwas anders. Das nicht erfolgende Speichern der Einstellungen fällt in die oben beschriebene Kategorie, das Senden bestimmter Emails an die falsche Adresse aber nicht.

Die Email wird an das in der php.ini angegebenen Emailserverprogramm übergeben, es gibt also keinen PHP-Fehler. Es müsste also über die versendeten Emails Buch geführt werden. Da gehört, so angegeben, der Absender, der oder die Empfänger und der Zweck/Betreff der Email rein, nicht aber der Text. Somit ließe sich feststellen, dass z.B. eine Passwortreminder-Email gesendet wurde und an wen die Email ging.

So, um mal den Code durchzuarbeiten:

Der Vorgang der Neuvergabe eines Passworts setzt sich aus mehreren Schritten zusammen. Als erstes sagt man an, dass man sein Passwort vergessen hat. Es wird ein vorübergehend gültiger Code generiert und eine Email gesendet. Als Betroffener muss man nun einen Link in dieser Email betätigen, um ein neues Passwort zu vergeben. Dabei wird der Code aus der DB mit dem aus der Email verglichen, um den Betätiger des Links zu authentifizieren.

Das läuft in mlf2 so (siehe includes/login.inc.php). Im Abschnitt case "pw_forgotten_submitted" wird die erste Email mit dem zu betätigenden Link generiert und gesendet, im folgenden Abschnitt case "activate" wird der Link aus der ersten Email ausgewertet und eine zweite Email gesendet, in der das neue Passwort steht.

Allerdings wirst du, so du PHP-Quelltexte lesen kannst, feststellen, dass in keinem der beiden Abschnitte eine Email an den Admin generiert wird. Nach dem Lesen der Benutzerdaten, dem Generieren des vorübergehend notwendigen Codes bzw. des neuen Passworts und deren Hinterlegung in der DB wird der Text der Emails zusammengesetzt und an die Funktion my_mail übergeben. In beiden Fällen wird als erster Parameter der Empfänger der Email ($field['user_email']), der aus der jeweils ersten Abfrage der Benutzerdaten im konkreten Block stammt, übergeben.

Lesen kann ich den Quelltext schon, nur mit dem Verständnis hapert es gewaltig. ;-) Allerdings kann ich deine Ausführungen wenigstens nachvollziehen.

Ermittelt werden die Benutzerdaten über die eingegebene Emailadresse (case "pw_forgotten_submitted") bzw. bei case "activate" über die in der ersten gesendeten ersten Email angegebene user-ID (GET-Parameter activate).

Auch die aufgerufene Funktion my_mail (siehe functions.inc.php) enthält keinen Hinweis auf eine Kopie an den Admin. Es wird aber zwingend ein Header eingefügt, der den Absender der Email enthält. Der enthält entweder einen im Skript an die Funktion übergebenen Absender oder, so dieser nicht an die Funktion übergeben wurde, die Forumsemailadresse, die typischerweise mit der des Admins übereinstimmt.

<spekulation>Vorstellen könnte ich mir, dass die Konfiguration des Emailaccounts bei deinem Webspaceanbieter so aussieht, dass du eine Kopie aller über den Emailaccount gesendeten Emails erhältst.</spekulation>

Ich habe ja zwei Foren bei demselben Webspaceanbieter. Ein Katzenforum und eben dieses "probelmatische". Das Katzenforum zeigt keine dieser Auffälligkeiten. Ich glaube also eher nicht, dass es am Provider liegt. Aber:
Gestern bekam ich eine Mail des Scriptschreibers meines Gästebuchs mit folgendem Inhalt:

Leider ist es einigen "Hackern" gelungen unter bestimmten
Server-Vorraussetzungen ein Sicherheitsloch in meinen Scripten ausfindig zu machen.
....

In Ihrem Fall müssten Sie die Datei: "gbook.php" von Ihren Gästebüchern bitte dort einmal "patchen" lassen.

Trotzdem sollten Sie zusätzlich einmal den Server aufsuchen und ggf. versuchen, ihn abzusichern. Evtl. laufen dort ja auch noch weitere Scripte, wo so ebenfalls Möglichkeiten zum Angriff gegeben werden.

Diese Sicherheitslücke entsteht dadurch, dass es leider immer noch
Server/Hoster gibt, die eine derart unsichere Einstellung auf Ihren Servern fahren, dass dieser Angriff überhaupt möglich wurde.

Wenn Sie mal eine phpinfo Datei aufspielen und aufrufen, werden Sie
sicherlich feststellen, dass eine oder gar mehrere Einstellungen der nun folgenden leider zutreffen werden.

register_globals = ON

allow_url_fopen = ON

allow_url_include = ON

Diese sollten eigentlich alle auf OFF stehen. Am wichtigsten dabei ist die
"register_globals".

Kann das Problem evtl. darin begründet sein?

Wenn meine Spekulation nicht zutrifft, bleibt nur übrig, dass bei der Anforderung eines neuen Passworts (Schritt 1) von vornherein die Daten des Admins anstatt der des betroffenen Benutzers von der DB zurückgegeben werden. Dann bekommst du als Admin die Email mit dem Link, der Benutzer aber keine Email. Ist das so?

Die Userin, die ein neues Passwort angefordert hat, muss es auch bekommen haben, denn sie hat sich danach wieder eingeloggt. Ich habe sowohl die Mail mit dem Link wie auch das Passwort leider auch bekommen. :-( Mit den Mails, die über das Forum verschickt werden, verhält es sich genauso, ich bekomme sie auch. Bisher habe ich die User nur gebeten, keine Mails mehr über das Forum zu verschicken, da es technische Schwierigkeiten gibt. Gerade das heikle Thema des Forums und die Sensibilität der einzelnen Leute macht es sehr schwer, mit völlig offenen Karten zu spielen.

Das "alte" Forum auf dem anderen Server ist übrigens auch noch installiert, falls dies weiterhelfen könnte. Und ich habe gerade meine Mail-Adresse anklickbar gemacht...

Danke nochmals für deine ausführlichen Erklärungen und Hilfestellungen!

--
Best wishes,
Birgit


Complete thread:

 RSS Feed of thread