Bug - Problem - Bug?

  • Nochmal zum eigentlichen Thema Sicherheit.
    Mir geht es nur darum, welche Dateien oder Verzeichnisse ZWINGEND auf 777 sein müssen, welche ZWINGEND auf 444, und welche auf XXX - hab schon rumgegoogelt aber nichts eindeutiges gefunden.

    • Offizieller Beitrag

    Noch was. Bisher sind bei uns gehosteten Kunden noch keine Probleme aufgetreten. Wir haben auch noch Kunden mit xt:Commerce (inkl. Security Fixe), und die laufen alle ohne Vorkommnisse.
    Bisher ist noch kein CSEO bekannt, wo es Probleme in dem Bereich gab, da Sicherheit beim Projekt commerce:SEO Shop an 1. Stelle steht und immer schon stand. und von dem Shop sind ja nun schon einige in Betrieb.

    • Offizieller Beitrag

    Zwingend muss kein Verzeichnis auf 777 oder 444 sein. Es kommt darauf an, was Du bei der Installation machen musstest. Hast Du per FTP hoch geladen und musstest dann die cache, templates_c, images ... Ordner alle mit 777 berechtigen? Wenn ja, ist es schon mal schlecht, denn damit gibst Du jedem Rechte auf die Verzeichnisse und das ist halt ein häufiges Einfalls Tor. 755 sollte normalerweise reichen.
    777 bedeutet ja, User-Gruppe-ALLE ANDEREN. Gut, muss man trotzdem einen Weg von aussen finden, aber gibt es einen, kann man da schöne böse Sachen machen, wie z.B. einen eigenen Webserver hochladen. Merkt man dann, wenn der Traffic mit einmal ungewöhnlich hoch ist :)
    Der Webshop muss in ein paar Verzeichnisse schreiben: images, cache, templates_c und im admin Order 2 Unterordner + sitemap1.xml im root. Mehr muss der Webshop prinzipiell erst mal nicht schreiben.
    Der Rest kann theoretisch, wenn Du nix an irgendwelchen Dateien ändern willst, sogar auf 444 gesetzt werden. Bei 1und1 ist es so, wenn man da was hoch läd per FTP, passen die Rechte immer. Diese 777 Geschichte ist oft, wenn ein Root Server angemietet wird und dann 100 fach untervermietet wird und der Betreiber die Rechte nicht richtig setzen kann. Oft läuft dann nämlich das Hosting unter einem Webserver User und der hat definitiv nicht Deine FTP User Berechtigung und auch nich die Gruppe. Deswegen musst man dann auch 777 setzen (alle anderen somit auch, da Webserver in dem Fall Other ist).

  • Da mein Provider nicht der langsamste ist, baut der gerade die UpDates ;)
    Dabei ist mir nun aufgefallen, dass bei DB-Error

    Warning: mysql_connect() [function.mysql-connect]: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) in /var/kunden/webs/xxxxxx/xxxxxx/shop/commerce_seo_url.php on line 9 usw. angezeigt wird

    Als Tipp für die Entwickler, da hier wohl mindestens ein @, besser ein try / catch vergessen wurde

    Gruß

    • Offizieller Beitrag

    Zum Abschluss ist mir noch eine Sache eingefallen. Wir haben oft, dass in den Shop die cache und templates_c Ordner immer komplett geleert werden, also auch die .htaccess und index.html (leere). Die .htaccess hat ihre Bedeutung in den Ordnern und die sollte in jedem Fall dort drin bleiben.

  • Also

    images, cache, templates_c und im admin Order 2 Unterordner (welche?) + sitemap1.xml auf 777 ???

    Wenn ich z.B. die sitemap1.xml auf 775 setze, gibts nen Fehler.

    Warning: fopen(sitemap1.xml) [function.fopen]: failed to open stream: Permission denied

  • Nochwas entdeckt:

    admin/configure
    define('ENABLE_SSL_CATALOG', 'true'); // secure webserver for catalog module

    /configure
    define('ENABLE_SSL_CATALOG', true); // secure webserver for catalog module

    Einmal string, einmal boolean...

    • Offizieller Beitrag

    Das war schon immer so. admin/images/graphs (für die Banner Statistik) und admin/rss. Da Du 777 berechtigen musst, läufst Du unter einem zentralen Webserver User. Wenn da einer an einer anderen Stelle einbricht, kommt er auch andere Webs ran. Das ist halt das Problem bei der Geschichte. Bei Root Servern mit Plesk macht sich da fast-CGI besser, da Dein Web dann unter Deinem user läuft. Dann hättest Du auch nicht das Problem, alles mit 777 berechtigen zu müssen.
    Schönes WE

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

  • Jepp, einmal als BOLEAN und einmal als Wert. Passt so. 'Ne Try&Catch in der Datei die sämtliche Anfragen verteilt macht in meinen Augen keinen Sinn. Sowas kann auch nur passieren wenn sich der SQL Server gerade nen Kaffee holt. So ungefähr in 1 von 10'000 Fällen.