Beiträge von admin

    Wie mehrfach gesagt. Es liegt definitiv an der GDLibary. Wie sieht denn die PHPInfo aus? Speiziell dieser Bereich:

    Ja, ich war auch in extrem hoch sensiblen Sicherheitsbereichen und habe somit von Haus aus schon immer ein Blick darauf. Sobald etwas publik wird, haben wir bisher auch immer sofort reagiert und das wird auch in Zukunft so sein. Vor dem urlaub ist wie Freitag, da kommen alle noch mal aus den löchern und wollen was, da brennt hier immer die Luft ;-))<br>Danke
    Der 2. Admin wird auch ein Auge werfen und Fragen beantworten. Er macht erst in der 2. Woche frei. Da bin ich zwar dienstlich unterwegs, schaue aber nach dem Rechten.

    Frag bitte in 2 Wochen noch mal nach. Ich habe jetzt erst mal Urlaub. Dann machen wir uns ran. Die 2 Module müssen aber warscheinlich komplett mal erneuert werden, die sind schon ziemlich angestaubt.

    Hallo julien, auch hier tolle Arbeit, ABER ich habe eine deutlich bessere Variante im QF3 eingesetzt. Die Attributpreis update Funktion läuft jetzt sauber, inkl. Sonderspreise und Staffelpreise. Das ging alles nicht korrekt. Deshalb ist das QF3 auch etwas umfangreicher! Hier werden dann auch die product_info Dateien ausgetauscht. Jeder, der schon Anpassungen gemacht hat, SOLLTE UNBEDINGT eine komplette Sicherung machen und die Dateien EINZELN per Notepad++ vergleichen! :)

    Der Export ist im "alten" ISO Format. Bei meinem Export macht er es richtig. Ich habe bei Ihnen mal rein gesehen, da kommt es auch korrekt raus. Wird die bei preisrober eventuell zerhackt?
    In der Datei selbst steht es so:
    Wasserfall Edelstahl Victoria 90 Edelstahl Wasserfall f&uuml;r Wandeinbau ...
    Nach meiner Meinung ist das korrekt.

    So sollte der Block besser gehen. Cache leeren nicht vergessen :cool:

    Hallo lasermodelle, mit Luftblase meine ich nicht diesen thread hier. Ich meine das bezogen auf andere Foren, die gerne mal die Leute in Panik versetzen und dann bricht das Große hektische Treiben aus und es gehen mehr Shops dabei kaputt, als überhaupt jemand gehackt wird :)
    Wie mann aber fast jeden Tag bei heise nachlesen kann, werden trotz alledem genügen Webseiten zur Zeit gehackt und das Thema ist auch für uns ein hoch brisanntes.
    Das kommt natürlich auch immer kurz vorm Urlaub, wo eh schon die Luft brennt.
    Ich teste noch ein wenig am QF3 und weitere potenzielle Verbesserungen, so dass das QF3 noch heute Abend kommen wird.
    Auch im Urlaub werde ich einen Blick auf alles haben, allerdings können Antworten, die nicht wirklich eine hohe Prio haben, etwas auf sich warten lassen.
    Ich habe im letzten halben Jahr den Shop fast komlett umgekrempelt und von vielen vielen Fehlern befreit, die noch in der Vorgänger Version drin waren. Jetzt brauche ich aber auch mal eine Pause um wieder Energie zu tanken :-))
    Euch erst mal eine schöne Zeit. In 14 Tagen sind wir dann auch wieder im Dienst.

    Statement:
    Nach nochmaliger Analyse des ganzen Vorfalles hier noch einmal eine Zusammenfassung aus unserer Sicht:

    1. osCommerce ist über eine Schwachstelle angreifbar, die bereits seit 2 jahren gefixt ist. (letztes update war November 2010!) Das Problem liegt im ungeschützten Adminbereich. Die Problematik stellt sich bei commerce:SEO + xt:Commerce 3 nicht! Hier ist der Adminbereich geschützt. Bei xt:Commerce 3 gab es diverse Schwachstellen, die ALLE in commerce:SEO bereits seit langen behoben sind.
    2. commerce:SEO Schutz eingebaut: in der application_top.php werden potenzielle SQL Injections abgefangen. Wir haben das mit dem Header manipulieren nachstellen können, allerdings werden hier keine Daten in die DB geschrieben. Die Auswirkungen bleiben also lokal auf den Rechner beschränkt.
    3. Acunetix Web Vulnerability Scanner 7 Test. Ja da kommen auch Meldungen, allerdings bleiben die auch, ebenso wie die Modifikation des Headers, lokal auf den Rechner beschränkt.

    Was kann man tun:

    Erweiterung der .htaccess
    Suche: RewriteEngine On

    füge danach folgendes ein:


    Das kommt zwar von Joomla, ist aber allgemein ein wirksamer Grundschutz vor Scripten.

    Die SQL Fehlermeldung, die dabei kommt, kann (sollte?) man eventuell reduzieren, damit keine weitere Angriffsfläche entsteht:

    Suche Datei: xtc_db_error.inc.php

    Suche darin folgenden Code:

    Code
    // handling an sql error
                echo "<b>SQL Fehler</b> [$errno] " . SQLMESSAGE . "<br /><br />\n\n";
                echo "<b>Query:</b> " . SQLQUERY . "<br /><br />\n\n";
                echo "Beim Aufruf der Datei <em>" . SQLERRORFILE . "</em> ";
                echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br /><br />\n\n";

    Ändere in:

    Code
    // handling an sql error
                if ($_SESSION['customers_status']['customers_status_id'] == 0) {
                    echo "<b>SQL Fehler</b> [$errno] " . SQLMESSAGE . "<br /><br />\n\n";
                    echo "<b>Query:</b> " . SQLQUERY . "<br /><br />\n\n";
                    echo "Beim Aufruf der Datei <em>" . SQLERRORFILE . "</em> ";
                    echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br /><br />\n\n";
                }

    und:

    Code
    echo "<b>My ERROR</b> [$errno] $errstr<br />\n";
                    echo "  Fatal error on line $errline in file $errfile";
                    echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n";

    gegen:

    Code
    if ($_SESSION['customers_status']['customers_status_id'] == 0) {
                    echo "<b>My ERROR</b> [$errno] $errstr<br />\n";
                    echo "  Fatal error on line $errline in file $errfile";
                    echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n";
                }

    Somit wird nur noch der Admin berechtigt, SQL Fehlermeldungen zu sehen. Ich halte diese Variante für sinnvoll, zumal der Admin trotzdem in der Lage ist, Fehler zu analysieren.

    Grundlegend verfalle ich nicht sofort in Panik bei solchen Vorkommnissen und behalte einen kühlen Kopf. Da ich regelmäßig heise lese, bin ich stets über aktuelle IT-Ereignisse im Bilde.
    Ich halte nicht viel davon, Sofort Panik zu verbreiten, die sich im Nachgang oft als reine luftblase raus stellt (wie damals oft bei ecomb...). Das verunsichert die Leute und verleitet viele zu Schnellschussreaktionen.
    commerce:SEO v2.1 wurde mit diversen Security Scannern mehrfach beackert und hierbei keine relevanten Probleme fest gestellt. Wir werden aber am Ball bleiben und Bei Bedarf Fixes liefern.

    Die aufgeführten Fixes sind im QF3 bereits enthalten. ACHTUNG, dabei wird die .htaccess mitgeliefert!!! Wer da schon Änderungen gemacht hat, bitte VORHER vergleichen!!! Es wurde der Sec-Fix eingebaut, aber auch das Caching noch etwas verbessert.

    Wir haben das Thema schon im Blick und arbeiten an der Lösung. Wobei anzumerken ist, die betroffenen Shop basieren auf osCommerce! die Lücke wurde im November schon von osCommerce geschlossen! Das xt:Commerce 3 Shops betroffen sind und deren Ableger ist bisher NICHT bekannt!