http://www.2f-cms.com/ 2F CMS - Neuigkeiten de_DE http://blogs.law.harvard.edu/tech/rss 2F CMS Thu, 09 Sep 2010 04:44:48 +0200 Thu, 09 Sep 2010 04:44:48 +0200 info@2f-cms.com info@2f-cms.com 2007-07-30T11:38:38+01:00 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. http://www.2f-cms.com/beitrag_Google-spricht-jetzt-direkt-mit-Webmastern_504.html http://www.2f-cms.com/beitrag_Google-spricht-jetzt-direkt-mit-Webmastern_504.html 2007-06-20T11:38:38+01:00 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. http://www.2f-cms.com/beitrag_Angeblicher-SPAM-von-Google-Search-Quality-Team_503.html http://www.2f-cms.com/beitrag_Angeblicher-SPAM-von-Google-Search-Quality-Team_503.html 2006-10-09T11:38:36+01:00 Erneut gibt es eine Sicherheitswarnung für die Skritsprache PHP (Hier bei Heise). Das 2F CMS ist, anders als viele andere Projekte,  auch hiervon wieder einmal nicht betroffen. http://www.2f-cms.com/beitrag_Sicherheitsl%25FCcke-in-PHP_477.html http://www.2f-cms.com/beitrag_Sicherheitsl%25FCcke-in-PHP_477.html 2 2006-07-19T11:38:35+01:00 Zur Zeit macht ein Hinweis auf eine "Sicherheitslücke" des FCKEditors die Runde und es wird schon gemutmaßt, dass jedes CMS, dass den FCKEditor einsetzt, diese Lücke beinhaltet. Ich stelle kurz klar: Die aktuellen 2F CMS Downloads sind hiervon nicht betroffen, ich habe die entsprechenden Codezeilen vorausschauend schon vor Wochen umgeschrieben. http://www.2f-cms.com/beitrag_FCKEditor-SecHole%252B-2F-CMS-nicht-betroffen_466.html http://www.2f-cms.com/beitrag_FCKEditor-SecHole%252B-2F-CMS-nicht-betroffen_466.html 2 2006-06-24T11:38:35+01:00 Ein Hinweis in eigener Sache: In der aktuellen "PHP Professionell" ist ein Artikel von mir zum Thema "PHP Sicherheit", der sich auf meinen PHP Security Guide bezieht. Der PHP Security Guide ist kostenlos als PDF verfügbar. Ich danke dem Magzin für diese Möglichkeit, das Thema öffentlich zu machen - von anderen PHP-magazinen habe ich auf meinen umfassenden und auch beliebten PHP Security Guide bisher leider kein Feedback oder gar eine Meldung erhalten. http://www.2f-cms.com/beitrag_Artikel-in-PHP-Professionell_459.html http://www.2f-cms.com/beitrag_Artikel-in-PHP-Professionell_459.html 2 2006-06-03T11:38:34+01:00 Microsoft bietet einen Sicherheitslehrgang für kleine Unternehmen in Form eines Fils im Internet an. Das Thema ist wichtig und gewinnt immer mehr an Beachtung - die idee ist nett und der Film geht nur 7 Minuten - einen Blick ist es sicherlich Wert:Link zum Film bei MicrosoftBeachten Sie die Möglichkeit, sich direkt durch IM Concepts beraten zu lassen. In Notfällen steht Ihnen unsere Hotline zur Verfügung. http://www.2f-cms.com/beitrag_Sicherheitslehrgang-im-Internet_448.html http://www.2f-cms.com/beitrag_Sicherheitslehrgang-im-Internet_448.html 2 2006-05-20T11:38:33+01:00 Der PHP-Security-Guide hat sich allmählich zu einem Erfolg gemausert: In den letzten 2 Monaten 500 Downloads und eine Menge an Feedback dazu :) Ich habe mich daher nun entschlossen, den Guide zu aktualisieren und zu überarbeiten. Inzwischen umfasst er 40 Seiten und steht kostenlos hier zum Download: Download auf PHPReferenz.de. Eine Registrierung ist nicht notwendig. Ich freue mich weiterhin über reges Lesen und Feedback.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" Variablen 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 Eine Erläuterung der Regeln findet sich im kostenlosen PHP-Security-Guide, im Downloadbereich: Hier zu finden http://www.2f-cms.com/beitrag_PHP-Security-Guide-%25FCberarbeitet_440.html http://www.2f-cms.com/beitrag_PHP-Security-Guide-%25FCberarbeitet_440.html 2 2006-05-01T11:38:33+01:00 Das Sicherheitskonzept des 2F CMS wurde überarbeitet - bisher basierte die Sicherheit des 2F CMS auf drei Säulen, nun sind es (in der Version 2.0) vier:Die Intrusion DetectionSQL BereinigungIntegritätsprüfungAktualitätNeu 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.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 http://www.2f-cms.com/beitrag_Sicherheitskonzept-%25FCberarbeitet_435.html http://www.2f-cms.com/beitrag_Sicherheitskonzept-%25FCberarbeitet_435.html 2 2006-04-07T11:38:32+01:00 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 http://www.2f-cms.com/beitrag_L%25FCcke-im-VWAR-Modul_426.html http://www.2f-cms.com/beitrag_L%25FCcke-im-VWAR-Modul_426.html 2 2006-04-07T11:38:32+01:00 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. Macht das endlich! Bei solchen Lücken schützt keine Intrusion Detection, da die Skripte ja direkt aufgerufen werden - es sind somit funktional gesehen eigenständige Skripte und keine Module. Auch wenn es nervt: Schmeisst die Module runter, ansonsten ist es nur eine Frage der ZEit bis eine Seite gehackt wird. Dazu auch im Forum: http://www.laanix.de/showthread.php?p=22088 http://www.2f-cms.com/beitrag_Sofort-htaccess-hinterlegen_427.html http://www.2f-cms.com/beitrag_Sofort-htaccess-hinterlegen_427.html 2