Link bei google erlaubt Zugang in den Adminbereich eines XTC-Shops!

  • Komische Sache: bei der google-Suche nach einem bestimmten XTC-Problem bin ich auf einen Link gestoßen, der folgenden Aufbau hatte (->Domainname wurde mit Rücksicht auf den inzwischen von mir informierten Shop-Betreiber entfernt): [url]http://www.irgendeine-domain.de/xtcommerce/admin/categories.php?sorting=stock&cPath=0_3&&XTCsid=b7a852580f36854af3722f241b97df30[/url] Nochmal den wichtigen Teil als Text: ....xtcommerce/admin/categories.php?sorting=stock&cPath=0_3&&XTCsid=b7a852580f36854af3722f241b97df30.... Sobald man auf den Eintrag in den Suchergebnissen klickte, gelangte man ohne Probleme in den Adminbereich des Shops und hätte dort alle Kundendaten einsehen sowie alle Daten ändern können. :o (Über das Frontend des Shops funktionierte der Zugang nur mit E-Mail-Adresse + Kennwort.) Kann soetwas auch mit den cseo-Shops passieren und wie kann man sich gegen derartige Dinge wirksam absichern??? Gruß Bernd E. PS: hier noch die "Session-Einstellungen" des Shops (könnte da der "Hund begraben" sein?): Session Speicherort /tmp Cookie Benutzung bevorzugen False Checken der SSL Session ID False Checken des User Browsers False Checken der IP Adresse False Session erneuern False
  • Ich hab das mal mit mehreren unserer Shops durchgespielt. Kein reinkommen. Erstens darf der Google-Bot das Verzeichnis des admin's -> robots.txt ([I]Disallow: /admin/[/I]) normaler weise nicht antasten. Zweitens ist in der v2, wegen dem PHP 5.3.x, eine neue Abfrage zur Überprüfung der Session drin. Man springt immer wieder zur login.php. Drittens sollte die Einstellung (Spider Sessions vermeiden? -> true) geschaltet sein. Also nein, beim v2 geht es nicht und beim v1.1.1 sollten lediglich die richtigen Einstellungen vorgenommen werden.
  • Meine password_double_opt.php hab ich auch im Index obwohl in der robot.txt Disallow: /password_double_opt.php steht. Die robot.txt wird gerne mal ignoriert. Die Loginbox hat nun noch ein rel=nofollow in den Link von mir bekommen. Ich hab auch früher schonmal Adminbereiche von Oscommerce Shops im Index gefunden als ich eine Fehlermeldung des Adminbereichs gegoogelt hab. Ich hab daher meine header.php geändert so das ein noindex ausgegeben wird. [QUOTE]Seite wird gelöscht\n"; echo " \n"; } else { include(DIR_WS_MODULES.FILENAME_METATAGS); } ?>[/QUOTE] Keine Ahnung ob es da eine bessere Lösung gibt aber so lösche ich ungewollt indexierte Seiten für die kein Antrag auf Löschung bei Google notwendig ist.
  • Hallo, die Sache mit der header.php finde ich interessant! Soeben stellte sich heraus, dass der Shopbetreiber zwar inzwischen scheinbar wirksame Vorkehrungen gegen die Benutzung des ihm mitgeteilten Links getroffen hat, dafür aber weiterhin die robots.txt (...die xtc-standard-datei...) im Shop-Unterverzeichnis belassen hat. Das Root-Verzeichnis seiner Site scheint überhaupt keine robots.txt zu enthalten. Soweit mit bekannt ist, wird von den SEs nur in der Root nach der robots.txt gesucht un nicht in irgendwelchen Verzeichnissen. Gruß Bernd E.
  • [QUOTE]die Sache mit der header.php finde ich interessant![/QUOTE] Die muss natürlich an die richtigen Seiten angepasst werden. Bei Title sollte man besser den Shopnamen angeben da der Title sonst ungünstigt aussieht :) Ich trenne meine Stylesheets z.B. auch damit in Startseite/Kategorien, Produktseite, Warenkorb und Account/Checkout.css auf. So bauen sich die Seiten wesentlich schneller auf da z.B. auf einer Produktseite kein CSS-Code bremst der dort nicht benötigt wird. Theoretisch kann man so sogar jeder Seite ein eigenenes Stylesheet zuordnen. Meine robot.txt liegt im root und wurde bei der password_double_opt.php (zu erreichen über den "Passwort vergessen?"-Link) ignoriert. Ich glaube ein "index"-Metatag hat mehr Gewicht als ein Disallow: /xyz in der robot.txt Wenn ich in den Webmastertools eine Seite aus dem Index löschen will geht das ja auch nur wenn die Seite kein "index"-Metatag hat. Schreibe ich die nur in meine robot.txt geben die Webmastertools eine Fehlermeldung aus und die Seite bleibt im Index.
  • Du hast einen Link mit einer aktiven Session bekommen (also war er gerade angemeldet und hat Dir den aktiven Link geschickt, oder sein Session Timeout stimmt nicht, z.B. Session Timeout auf 12 Stunden oder so). Wenn Dir ein Kunde einen Link schickt aus dem Admin mit einer noch gültigen Session, kommst Du IMMER rein. Das ist normal. Aber kein Grund zur Panik. Das funktioniert überall, egal ob es ein Shop ist oder irgend etwas anderes.

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

  • Habe mir jetzt meinen Adminbereich mit httpauth via vhost.conf (geht auch per .htaccess) geschützt. Stolpersteine sind die Kunden_status.gifs im Verz. admin/images/icons. Hier die Lösung: [URL='http://support.commerce-seo.de/threads/1513-htaccess-Auth-f%C3%BCr-Adminbereich-so-gehts']http://support.commerce-seo.de/threads/1513-htaccess-Auth-f%C3%BCr-Adminbereich-so-gehts[/URL]