Bug - Problem - Bug?

  • Hallo,
    bin neu hier und habe commerce:seo installiert. Läuft so weit ganz gut aber bei Tests sind mir Fehler aufgefallen:

    a) klicke ich in der Login-Box auf "passwort vergessen", wird mir der Captcha (kein gd Fehler !) angezeigt. Dort tue ich nun aber einfach gar nichts und klicke weiter in den Kategorien herum. Gebe ich nun aber in der Login-Box Username und Passwort ein und will mich einloggen, komme ich auf die login.php (action=process), erhalte die Meldung, dass mein Sicherheitscode falsch wäre. Die Login.php zeigt aber keinen Captcha an. (Wurde evtl. in der Session gespeichert, dass ich vorher die Passwort-Vergessen Funktion aufgerufen hatte?).

    Lösung?

    b) Ganz ähnliches, evtl. Session Problem, z.B. beim Einlösen eines Gutscheines.
    Ich gebe einen falschen Gutscheincode auf der shopping_cart.php ein und erhalte richtigerweise die Fehlermeldung.
    Ignoriere ich das nun und klicke "zur Kasse", wird diese Fehlermeldung auch auf der checkout_shipping, checkout_payment usw. angezeigt.

    Wenn der Kunde auf die nächste Seite klickt, sollte doch nicht die Fehlermeldung der Vorseite erscheinen...

    Lösung?

    Danke im Voraus.

  • Hm... niemand vom Support da? 2 Tage? Schade...

    Hab mir zwischenzeitlich mal die login.php angesehen.

    Die erste Abfrage ist ja:

    if (isset ($_GET['action']) && ($_GET['action'] == 'process')){ ...

    Diese umschließt unter anderem

    $smarty->assign('VVIMG', '<img src="'.FILENAME_DISPLAY_VVCODES.'" alt="" />');
    $smarty->assign('INPUT_CODE', xtc_draw_input_field('vvcode', '', 'size="6" maxlength="6"', 'text', false));

    Und das müsste dann doch die Ursache sein, denn wenn ich nun über die Links "Kundenkonto" auf die login.html komme und dort "Einloggen oder ein neues Kundenkonto erstellen" klicke, ist die $_GET['action'] leer..., d.h. überhaupt nicht gesetzt...

  • Beim Test / Suche nach dem o.a. Bug ist mir noch folgendes aufgefallen:

    Habe ich mir über "Passwort vergessen" ein neues Passwort zusenden lassen und mich erfolgreich eingeloggt, gehe dann z.B. ins Adressbuch oder in die Auftragsübersicht, so erscheint weiterhin die Meldung "Ein neues Passwort wurde per E-Mail verschickt.", obwohl diese "Geschichte" ja dann schon längst erledigt ist.

  • Noch etwas gefunden:

    Fehler tritt seltsamerweise nur bei eingeschaltetem PHPIDS auf.

    Warning: Smarty error: unable to read resource: "/lang_.conf" in .......

    Ergebnis der Fehlersuche:

    In der logoff.php geht nach dem Include der header.php die Session verloren, jedoch wird danach auf die language aus der Session zugegriffen, die es dann aber nicht mehr gibt.

    Lösungsansatz:

    Vor

    require (DIR_WS_INCLUDES.'header.php');

    Einfügen

    $tmp_lang = $_SESSION['language'];

    und die beiden

    $smarty->assign('language', $_SESSION['language']);

    ersetzen mit

    $smarty->assign('language', $tmp_lang);

    Oder ist das dirty?

    • Offizieller Beitrag

    Das mit PHPIDS ist bekannt. Leider konnten wir nicht die Ursache genau ermitteln. In der v2 fliegt die erst mal raus, bis wir generell eine vernünftige Lösung haben. Das mit den Captcha ist ein Bug und Daniel sollte was dazu erzählen können.

    <p>Wir geben nur Anregungen und Hilfestellung auf Basis unserer Erfahrung, keine Rechtshilfe!<br>\m/('_')\m/</p>

  • Den hab ich in der v2 schon behoben. Wie richtig erkannt werden Fehlversuche + Captcha in der Session abgelegt. Ich habe das um eine Abfrage nach dieser Session erweitert.

  • Hallo,
    ist eigentlich geplant, dass man die V2 einfach auf die V1.1.1 aufspielen, also die 1.1.1 zur 2 updaten kann?
    Wäre schon heftig, jetzt nach den ganzen Anpassungen bei der irgendwann "für produktiv" erscheinenden V2 wieder von vorne anfangen zu müssen.
    Ich hab nun eigentlich alles lösen können und könnte mit meinem Shop starten, wenn ich nur das Captcha/Login - Problem lösen könnte...
    Hast Du bzw. habt Ihr da keinen Tipp (Deine Abfrage...), wie man das in der 1.1.1 hinbekommt?
    Wäre klasse...

    • Offizieller Beitrag

    Zum Einen sind ja viele Sachen in der v2 schon behoben. Einfach drüber bügeln wird aber momentan nix, da auch diverse Anpassungen in der DB gemacht werden müssen. Das kommt zu einem späteren Zeitpunkt. Du kannst also erst mal getrost mit der 1.1.1 weiter arbeiten.

  • Ich glaube das war nur der Code:

    Suche in der login.php:

    PHP
    if (isset ($_GET['action']) && ($_GET['action'] == 'process')) {

    Füge DAVOR ein:

    PHP
    if((isset($_SESSION['vvcode']) && !empty($_SESSION['vvcode'])) && ($_GET['action'] != 'process')) {
        $vv_validation=true;
        require_once (DIR_FS_INC.'xtc_random_charcode.inc.php');
        $vlcode = xtc_random_charcode(32);
        $smarty->assign('VVIMG', '<img src="'.FILENAME_DISPLAY_VVCODES.'" alt="" />');    
        $smarty->assign('INPUT_CODE', xtc_draw_input_field('vvcode', '', 'size="6" maxlength="6"', 'text', false));
    }
    • Offizieller Beitrag

    Ist mir nicht bekannt. Was meinst Du denn genau mit Rechtevergabe? Ein paar Tipps kann ich aber für das Filesystem schon mal geben. Den Shop mit 777 Rechten im Filesystem laufen zu lassen ist nicht sinnvoll. Ich weiß, bei vielen Root Servern ist das nicht anders machbar für Laien, aber es gibt immer Lösungen, wenn der jeweilige Provider oder Möchtegern Provider sich damit auskennt. Hier sollte man als Erstes ansetzen. Kann ich meinem Provider vertrauen, dass hier die aktuellen Sicherheitsmaßnahmen getroffen werden? Ist der Server aktuell? Viele Shops laufen z.B. noch mit steinalten PHP Versionen. Da fängt dann aber das Übel an, denn über reine PHP Sicherheitslöcher kann ja auch eingebrochen werden und da nützt der beste Shop nix!
    Ein häufiger Angriffspunkt ist der Ordner images, hier ist aber in CSEO ab 1.1.1 eine Zusatzsicherung drin, so dass von dort keine PHP Dateien ausgeführt werden können. Wir haben alle relevanten Sicherheitsmechanismen auch schon in die 1.1.1 eingebaut. ABER das ist natürlich kein 100% Schutz, da viele Module und Core Dateien noch aus xt:Commerce stammen. Sollte sich hier eine Sicherheitslücke auftun, muss man sich in jedem Fall regelmäßig informieren.
    Generell gilt, sparsam mit Rechten umgehen und auch im Shop die Admin Rechte nur vertrauenswürdigen Personen geben. In CSEO 1.1.1 sind alle bisher bekannten Sicherheitsupdates drin. Manche sind zwar nicht kritisch und eher für Spassmacher oder Panikmacher, aber sicher ist sicher.
    In manchen Foren wird teilweise aber auch sehr viel Wirbel um nichts gemacht, nur um Aufmerksamkeit zu erlangen. Konkret wird es dort aber nicht und oft ist es nur heiße Luft. Gambio und HHG gehen da professioneller mit dem Thema um und da würde ich auch immer mal ein Ohr dran haben (machen wir auch :D). Dort gibt es auch konkrete Lösungsansätze. Sobald uns was bekannt wird, informieren wir auch über unseren RSS Feed.
    Sicherheit ist ein langwieger Prozess. Man muss auf jeden Fall sich regelmäig informieren, wie z.B. auch bei Secunia. Das sind die Profi Quellen.

    Zum Abschluss. Nicht gleich in Panik verfallen, wenn einer mal irgendwo versucht Panik zu verbreiten. Hier immer mehrere Quellen anzapfen.
    Bei Eigenversuchen immer erst mal auf einem Testshop testen, da kann man sich auch schnell mal aussperren.
    Im Zweifel lieber mal einen Profi ran lassen. Das Geld, was man da ausgibt, ist besser dort, als wenn der Shop gar nicht geht und man einen Image Schaden hinnehmen muss und Verdiehnstausfall.
    Und jede Änderung Schritt für Schritt machen und immer testen! Nicht 3 Schritte mit einmal und dann geht gar nix mehr.

  • Danke für das ausführliche Statement. Der Server ist up to date. PHP 5.2.0-8, mySQL 5.0.32, Linux 2.6.18, Apache/2.2.3 (Debian)
    OpenSSL wird gerade auch upgedatet.

    • Offizieller Beitrag

    Up-to-Date nenne ich anders :D:

    PHP 5.2.13 http://php.net/
    Apache 2.2.15 http://httpd.apache.org/

    SSL war ja schon vor Wochen das Update. Aber bei großen Providern dauert so was immer etwas länger. Bei 1und1 komischerweise geht das immer recht fix. Die haben schon PHP5.2.13.

    Aber das ist noch kein Grund zur Panik. Die Provider haben ja auch Zusatzvorrichtungen um selbst mit etwas älterer Software kein Problem zu bekommen.

  • Ich meinte eher, nicht mehr auf mySQL 4 und PHP 4 zu sein.

    Sind die UpDates, die Du schilderst, sicherheitsrelevant?

    Mein Provider (klein aber fein) dated bei Sicherheitsproblemen eigentlich immer automatisch up...

  • PS: ...die genannten Versionen entsprechen dem Versionsstand der Quellcode-Pakete. Jede Linux-Distribution selbst führt aber nochmals eigene Versionen (und darüber hinaus sicherheitsrelevante Patches), so das die Pakete meist nie auf dem aktuellsten Stand sein können. Da sich mit neuen Programmversionen teilweise auch Funktionalitäten und die Abwärtskompatibilität zu Scripten und vorhandenen Konfigurationen ändern kann, kann man nicht immer "automatischen Updates" bei Neuerscheinung ausführen, sondern in der Regel nur sicherheitsrelevante Updates.

    • Offizieller Beitrag

    Nun ja, wie gesagt. Nicht jede Lücke muss auch automatisch ein Problem sein. Ich selber betreue diverse Server und wir haben auch viele Shopkunden drauf. Man muss sich halt mit der Materie beschäftigen und kostet viel Zeit. Ich mache das ca. 10 Jahre und lerne jeden Tag neu :) Aber auch jedes Server Update birgt Gefahren, dass danach gar nix mehr geht. Deswegen verstehe ich auch viele Provider, die lieber auf Stabilität gehen und nicht jeden instabilen Fix einbauen. In der Regel sind die Patches für Apache, PHP und MySQL gut getestet und man sollte als Hostinganbieter immer auch eine Testmaschine haben. Da ich auch in Hochsichertsumgebungen arbeite, ist man für solche Sachen sensibler. Die Frage ist, lohnt sich der Aufwand? Habe ich, wenn mein Shop mal 2 Tage nicht da ist, einen Verlust von 10 Euro oder 5000 (oder mehr). Bei ersteren, sollte man Wert auf eine regelmäßige Datensicherung (mySQLDumper / FTP Sicherung) legen. Im 2. Fall würde ich dann doch lieber mal ein paar Euro in die Hand nehmen und Spezilisten ran nehmen.
    Gut ist auch, wenn man den Provider in Notfällen schnell erreicht und der einem auf kurzem Dienstweg schnell weiter hilft. Da kann ein kleiner Provider in der Regel besser punkten als ein Riese, wo man auch mal ein paar Stunden verzug hat.
    Ich könnte Stundenlang so weiter schreiben, aber es muss sich jeder erst einmal selbst dazu Gedanken machen. Es gibt sehr viele Punkte die man betrachten könnte.
    Noch zum Abschluss ein Beispiel: In Joomla gibt es in der .htaccess Sicherheitseinstellungen zum Abfangen von Hackerangriffen. Die greifen aber erst im Apache 2.x!!! Das ist mir persönlich schon passiert, dass auf meinem Server (managed bei 1und1) reihenweise die Joomla Pakete gehakt wurden. Es hat sich raus gestellt, dass die Managed Server bei 1und1 noch mit dem Apache 1.3 laufen und halt dieser Schutz da nicht greift. Seit dem sind die auf Root Server untergebracht, die selbst aktualisieren kann.