Kundennews
Ihr Zugang
* SSL - die Daten werden verschlüsselt an Ihren Browser gesendet
RSS
[Übersicht] - [Archiv] - [Sicherheit]
Google spricht jetzt direkt mit Webmastern
Jetzt spricht Google direkt mit dem Webmaster über die Google Webmaster Tools - z.B. bekommt man auf diesem Wege Nachrichten, bei Verstößen gegen die Richtlinien für Webmaster.
Sicher auch eine Reaktion auf den SPAM der angeblich vom Google Search Quality Team kam (siehe unsere News vom 20. Juni 2007 - Angeblicher SPAM von Google Search Quality Team.
Angeblicher SPAM von Google Search Quality Team
Scheinbar geht es wieder los - Heute morgen haben mich einige Anfragen (per Mail und über das Forum Laanix erreicht) - ob es sich bei der Mail von: Google Search Quality Team um eine echte Mail von Google handelt.
Ich kann das natürlich nicht mit 100% Sicherheit mit einem Nein beantworten. Aber bei den bisherigen Fällen spricht alles dafür, dass es sich um SPAM handelt.
Sicherheitslücke in PHP
FCKEditor SecHole: 2F CMS nicht betroffen
Artikel in PHP Professionell
Sicherheitslehrgang im Internet
Link zum Film bei Microsoft
Beachten Sie die Möglichkeit, sich direkt durch IM Concepts beraten zu lassen. In Notfällen steht Ihnen unsere Hotline zur Verfügung.
PHP Security Guide überarbeitet
Bei der Überarbeitung des PHP-Security Guides habe ich aus den bisher 10 Grundregeln nun 12 gemacht. Hier die aktuelle Fassung der Regeln:
1) Request-Variablen sind bei register_globals=on auch "normale" VariablenEine Erläuterung der Regeln findet sich im kostenlosen PHP-Security-Guide, im Downloadbereich: Hier zu finden
2) In ein include() gehören keine REQUEST-Variablen
3) In eine Ausgabe gehören keine REQUEST-Variablen
4) Wenn eine Ausgabe von REQUEST-Variablen nötig ist, an htmlspecialchars() denken
5) Sessions zum Transport von Daten sind besser als REQUEST-Variablen
6) Wenn Variablen nur einmal definiert werden sollen (etwa Konfigurationsdaten, besonders Pfade für include()), sind Konstanten besser
7) Daten sind spezifisch zu nutzen - die Unterschiede zwischen POST und GET sollten genutzt werden, nicht immer nur blind REQUEST
8) REQUEST-Daten, die in einen Datenbankquery übernommen werden, müssen validiert werden
9) REQUEST-Daten haben nichts in Dateioperationen (fopen() etc.) zu suchen
10) Variablen in globalem Kontext immer initialisieren und prüfen
11) Bei dezentralen Dateien immer den Direktzugriff prüfen
12) Traue keinen Benutzereingaben
Sicherheitskonzept überarbeitet
Die Intrusion DetectionNeu ist das Konzept der internen Integritätsprüfung - das System prüft regelmässig seine Dateien selbst, um direkte Änderungen zu erkennen und sofort bei einer geänderten Datei den Administrator zu benachrichtigen. Wahlweise kann der kostenlose Cyllo-Service genutzt werden: Im 2F CMS kann aktiviert werden, das bei Angriffsverdacht Cyllo per Mail informiert wird, damit schnellstmöglich die Seite geprüft und ggfs. der Webmaster kontaktiert werden kann.
SQL Bereinigung
Integritätsprüfung
Aktualität
Dabei arbeitet das 2F CMS wieder dynamisch: Es werden zum einen die Dateien auf dem Server regelmässig geprüft. Weiterhin wird die Ausgabe ständig überwacht und bei plötzlicher, scheinbar unauthorisierter Änderung, eine Warnung abgegeben. Sollte über den Server beschreibbare Dateien, wie etwa die Config-Dateien, verändert werden, erkennt das System das nicht nur, sondern verwirft diese Dateien und nutzt erstmal systeminterne Backups. Defacement-Angriffe, die über Server laufen, haben es damit im 2F CMS ab der 2.0 erheblich schwerer.
Der Bereich Sicherheit wurde entsprechend aktualisiert: http://www.2f-cms.com/content-seite-6-2F+CMS.html
Lücke im VWAR Modul
Das beliebte und für phpnuke als Modul vorliegende Skript "vwar" bietet eine Sicherheitslücke, die einen Remote-Include anbietet.
Ein Quickfix:
In den Dateien include/get_header.php und include/get_footer.php direkt nach dem <?php diese Zeilen platzieren:
unset($_GET['vwar_root']);
unset($_POST['vwar_root']);
unset($_COOKIE['vwar_root']);
unset($_REQUEST['vwar_root']);
Dazu habe ich auch ein Advisory von SecFocus vorliegen: http://www.securityfocus.com/bid/17358
Die von mir propagierte htaccess (http://www.2f-cms.com/article438.html) schützt zwar davor, doch nutzen scheinbar die meisten vwar User diese nicht, da das Modul dann nich vollständig funktioniert. Daher nochmal von mir der Hinweis: Diese htaccess sofort einsetzen, dazu nochmal das hier lesen: http://www.2f-cms.com/beitrag_Sofort+htaccess+hinterlegen_461.html. Jedes Modul, das mit dieser htaccess nicht funktioniert ist immer ien potentielels SIcherheitsrisiko, dass erst getestet werden muss! Wer das selber nicht kann und einen Auftrag bei Cyllo scheut, sollte das jeweilige Modul gar nicht einsetzen! Das Risiko ist es jedenfalls nicht wert!
Dazu auch die Diskussion im Forum: http://www.laanix.de/showthread.php?t=4041
Sofort htaccess hinterlegen
Nocheinmal, diesmal energisch an alle: Hinterlegt alle sofort die von mir beschriebene .htaccess Datei: http://www.2f-cms.com/article438.html
Wenn Module mit dieser htaccess nicht funktionieren, gelten die folgenden Regeln, die ihr ernst nehmen solltet:
1) Jedes Modul, das damit nicht funktioniert, ist ein potentielles Sicherheitsloch und gerade ein Grund die Datei zu hinterlegen. Auf gar keinen Fall die htacces snicht nutzen, weil ein Modul damit nicht funktioniert.2) Module die mit der htaccess nicht laufen müssen einzeln abgeklopft werden. Wenn man das nicht selber kann, ist das erst recht ein Grund diese Module nicht einzusetzen, aber auf keinen Fall ein Grund die htaccess zu löschen. Wahlweise kann man auch auf Cyllo (http://www.cyllo.com) einen kostenpflichtigen Auftrag zur Prüfung erteilen oder im Forum fragen ob es sich einer kostenlos ansieht - letzteres ist immer freiwillig!3) Wahlweise kann man für einzelne Module eine Ausnahme kreieren, was aber nur eine temporäre Lösung ist und maximal 7 Tage Einsatz finden sollte. So kann in jedem Modul, in dem direkt auf PHP Dateien zugegriffen werden soll, einfach eine weitere htaccess mit diesem Inhalt platziert werden:<filesmatch ".php$">
allow from all
</filesmatch>Am Ende unterläuft das aber den Schutz.

Start
Kontakt
AGB
Impressum
