Kunden landen nach Account anlegen in falschem Kundenkonto

[gamaboa]

Hallo,

da dies mein erster Post hier ist, ersteinmal ein großes Dankeschön und Lob für die Arbeit und den Support, den ihr hier reinsteckt! Hut ab. Bei meinem Shop der seit gut einem Jahr läuft, hat bisher bei Problemen das Mitlesen geholfen. Aber jetzt stehe ich vor dem folgenden Problem, bei dem das Forum oder Handbuch noch keine Lösung ausgespuckt haben:

Seit ca. 2 Wochen kommt es immer wieder (bisher haben sie sich in 3 Fällen gemeldet) vor, dass Kunden, die beim Login einen neuen Account anlegen, in einem fremden Kundenkonto landen. Sie haben dabei volle Einsicht auf die Daten und können auch Bestellungen über das fremde Konto durchführen. Beide betroffenen Kunden haben immer recht zeitnah (ca. 1 h) ein neues Konto angelegt. Ausloggen und wieder einloggen scheint das Problem zu beheben. Der Fehler tritt nur manchmal auf, ich konnte ihn daher noch nicht nachvollziehen. Jeder Test von mir verlief problemlos. Bestellungen ohne Kundenaccount scheinen nicht betroffen zu sein. In den letzten Wochen wurden eigentlich keine Veränderungen im Shop vorgenommen.

Shopversion ist Version 1.03 (bisher ohne Updates – Asche auf mein Haupt), PHP Version: 4.4.8, MySQL 4.1.22 mit Modulen zu dezimalen Mengen und Anwendungsbereich und einige kleiner Veränderungen.

Ich hoffe ihr könnt mir weiterhelfen,
Martin



Linkback: https://www.modified-shop.org/forum/index.php?topic=11478.0

[fishnet]

Hast du
a) eine Kundengruppe gelöscht?
oder
b) Manuell in der Datenbank Kunden gelöscht?
Gruß
Karsten

[gamaboa]

Nein, beides nicht. In der DB habe ich nur manchmal bei den Artikel Daten geändert. Kundengruppen sind seit Monaten unverändert.

Martin

[fishnet]

Was hast du vor 2 Wochen geändert?
Vielleicht ein Modul installiert?
Machst du regelmässig Datenbanksicherungen?

[DokuMan]

Schau mal bitte hier und vergleiche deine Einstellungen: FAQ: Empfohlene Sessioneinstellungen

[gamaboa]

Ich bin seit 3 Wochen mit Facebook etc. beschäftigt und habe nur damit verbundene Änderungen/Links in Templates eingebaut, mehr nicht.
Datenbankbackups mache ich regelmäßig.

Die empfohlnenen Sessioneinstellungen hatte ich auch schon gefunden und vermutet, dass der Fehler daher kommt.
Session erneuern hatte ich schon geändert, danach kam es noch zu einem Fehllogin. Checken des User Browsers habe ich heute noch nach dem letzten Fehllogin geändert.

Martin

[Dragon]

Hallo Jungs,

hab da wieder mal etwas, was doch einige Probleme mit sich bringt:

Code: PHP  [Auswählen]

if (!(preg_match('/^[a-z0-9]{26}$/i', session_id()) || preg_match('/^[a-z0-9]{32}$/i', session_id()))) {
    // Thanks to HHGAG
    session_regenerate_id(true);
}
 

wenn ich jetzt dazu bei php.net nachschaue finde ich die folgende Information:

The higher you set session.hash_bits_per_character the shorter your session_id will become by using more bits per character. The possible values are 4, 5, or 6.

When using sha-1 for hashing (by setting ini_set('session.hash_function', 1) the following session string lengths are produced by the three session.hash_bits_per_character settings:

4 - 40 character string
5 - 32 character string
6 - 27 character string

It would seem desirable to use sha-l with 5 bits_per_character because this will emulate a standard 32 character md5 string and make a would-be attacker think that is what you're hashing with.

Quelle: PHP: session_id - Manual

Ebenfalls habe ich gelesen, daß die Session-ID seit php 5.0.0 ,(Komma) und - (Minus) beinhalten kann. Von daher sollten diese Zeilen doch etwas anders aussehen:

Code: PHP  [Auswählen]

if(version_compare(PHP_VERSION, '5.0.0', '>=')){
  if(ini_get(session.hash_function)==1){
    if(!(preg_match('/^[a-z0-9\,\-]{40}$/i', session_id()) || preg_match('/^[a-z0-9\,\-]{32}$/i', session_id())|| preg_match('/^[a-z0-9\,\-]{27}$/i', session_id()))) {
      // Thanks to HHGAG
      session_regenerate_id(true);
    }else{
      if(!(preg_match('/^[a-z0-9\,\-]{22}$/i', session_id()) || preg_match('/^[a-z0-9\,\-]{32}$/i', session_id()))) {
        session_regenerate_id(true);
      }
    }
  }
}else{
  if(!(preg_match('/^[a-z0-9]{26}$/i', session_id()) || preg_match('/^[a-z0-9]{32}$/i', session_id()))) {
    // Thanks to HHGAG
    session_regenerate_id(true);
  }
}
 

Der 22'er Zeile ist mir aufgefallen, als ich bei einem amerikanischen Hoster mit php5.3.5 und session.hash_function auf 0 stieß. Gut man kann auch festlegen, daß session.hash_function auf 1 und bits_per_character auf 5 zustehen hat, aber bei manchen Hostern gibt es Probleme mit ini_set.
So und nun dürft Ihr euch wieder an das Problem machen.

Gruß der Feuerspucker