Sicherheitscheck, Shop gehackt, Datenbank fort

[AGI]

Aus gegeben Anlass:

Bitte schaut doch gelegentlich per FTP in eure Shops.
Prüft ob ihr in den folgenden Verzeichnissen admin/includes/ und includes/
"configure.php"-Dateien findet, die nicht die Endung .php haben.
Beispielsweise: configure.php_old, configure.php.old, configure.php.org, configure.php.bak, configure.old
Gerade in alten Shopversionen, oder bei Shopupdates und Umzügen werden die configure.php-Dateien gern kopiert und umbenannt und bleiben dann auf dem Server liegen.

Das Problem: die Dateien ohne .php-Endung sind von außen einsehbar.
Da darin die Datenbank-Zugangsdaten gespeichert sind, kann der Leser diese problemlos auslesen.
Wer die Dateien findet, hat somit den Datenbankzugang und kann diesen nutzen, wenn die Datenbank den Zugriff von außen erlaubt.

Und ja, es gibt Bots, die gezielt nach diesen Dateien suchen.
Das Ergebnis: Kundendaten, Bestellungen, PayPal-Zugangsdaten und alles andere, was in der Datenbank steht, kann ausgelesen werden, die Datenbank kann komplett gelöscht werden. Vielleicht findet ihr dann auch eine letzte Verbleibende Tabelle mit dem Satz: "To recover your lost data : Send 0.3 BTC to our BitCoin Address and Contact[...]"

Wenn ihr diese Dateien auf dem Server habt:
a) entfernt die Datenbank-Zugangsdaten daraus
b) gebt denen die Endung .php
c) löscht sie

Also, einfach die Augen offen halten.

Viele Grüße
Andreas

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

[fishnet]

[...]
Das Problem: die Dateien ohne .php-Endung sind von außen einsehbar.
[...]

Das gilt übrigens für alle Dateien (auch wenn es bei den configure Dateien am dramatischsten ist).

Wenn Ihr eine PHP Datei unbedingt behalten wollt (als online-Backup oder so), dann könnt Ihr da so machen:

beispiel.php
umbenennen in beispiel.php_
(kann man auch sinnvoll erweitern mit Datum und/oder Name, also  beispiel.php_2019.04.11_kg

in die .htaccess das hier setzen

Code: PHP  [Auswählen]

# Keinen Zugriff auf auskommentierte PHP Dateien zulassen
<FilesMatch ".*\.(php_)">
  <IfModule mod_authz_core.c>
    # Apache 2.4
   <RequireAll>
      Require all denied
    </RequireAll>
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
   Order Deny,Allow
    Deny from all
  </IfModule>
</FilesMatch>

[woeppel]

Dieser .htaccess Eintrag sollte zur Pflicht werden.

Vielen Dank
Markus

[Whiteflash]

Man könnte natürlich seine Datei auch in

beispiel.bak.php

umbenennen - dann muss ich keinen .htaccess-Eintrag setzen. Nur mal so...

[longchuan]

Ist es ein Nachtei in die .htaccess den Eintrag zu machen?
Danke für die Antwort

[hpzeller]

Das Szenario welches der TE Andreas beschreibt halte ich für realistisch und das damit verbundene Sicherheitsrisiko für ziemlich gross. Um das Sicherheitsrisiko einzudämmen und dabei die im Ordner includes enthaltenen JavaScript Dateien vor einem direkten Browserzugriff nicht auszuschliessen, könnte man in die Datei includes/.htaccess anstatt folgender Direktiven

Code: [Auswählen]

<Files *.php>
  <IfModule mod_authz_core.c>
    # Apache 2.4
    <RequireAll>
      Require all denied
    </RequireAll>
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
    Order Deny,Allow
    Deny from all
  </IfModule>
</Files>

diese Direktiven eintragen.

Code: [Auswählen]

<FilesMatch "(?<!\.js)$">
  <IfModule mod_authz_core.c>
    # Apache 2.4
    <RequireAll>
      Require all denied
    </RequireAll>
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
    Order Deny,Allow
    Deny from all
  </IfModule>
</FilesMatch>

Gruss
Hanspeter

[GTB]

da fehlen noch die CSS Dateien

Gruss Gerhard

[hpzeller]

da fehlen noch die CSS Dateien
[...]

Welche?

Gruss
Hanspeter

[GTB]

Code: [Auswählen]

<FilesMatch "!\.(js|css)$">
für zB CSS Dateien aus dem PayPal Modul.

Gruss Gerhard

[hpzeller]

Code: [Auswählen]

<FilesMatch "!\.(js|css)$">
für zB CSS Dateien aus dem PayPal Modul.
[...]

ok

Gruss
Hanspeter

[noRiddle (revilonetz)]

Sehr guter Hinweis, AGI, vielen Dank dafür.

Dazu noch folgender Gedanke:
Es wird sicherlich schwerlich für alle Server-Umgebungen vorausbestimmbar und somit nicht für alle modified-Installationen in der Installations-Anleitung erklärbar sein, aber gehört die configure.php nicht ohnehin eigentlich oberhalb des vom Web aus erreichbaren Roots positioniert, und somit also oberhalb public_html oder httpdocs oder wie immer das Web-Root benannt ist ?
Das würde jedenfalls eine zusätzliche und wichtige Sicherheit bzgl. der Informationen über Serverpfade und DB-Zugänge bedeuten.

Gruß,
noRiddle

[hpzeller]

Jetzt habe ich aber noch ein Problem.

Bei mir, Apache mit Nginx als Reverse Proxy, funktioniert folgender Code in der .htaccess nicht, z.B. wird .old nicht verboten,

Code: [Auswählen]

<FilesMatch "!\.(js|css)$">

folgender Code von hier -> https://stackoverflow.com/questions/12926604/inverted-filesmatc aber schon.

Code: [Auswählen]

<FilesMatch "(?<!\.css|\.js)$">

Gruss
Hanspeter

[GTB]

kannst du bitte das hier probieren ?

Code: [Auswählen]

<FilesMatch "^\.(css|js)$">
Gruss Gerhard

[hpzeller]

Nein leider funktioniert dieser Code auch nicht.

Was ist aber bei folgendem Code nicht in Ordnung, bei mir funktioniert er, will heissen nur Dateien mit den Endungen .css und .js werden an den Browser ausgeliefert, alle anderen sind mit Status 403 Forbidden gesperrt.

Code: [Auswählen]

<FilesMatch "(?<!\.css|\.js)$">

Gruss
Hanspeter

[GTB]

Ich überlege gerade das ins SVN zu übernehmen und ausweiten auf andere Ordner.
Micht sört eigentlich nur, dass \. für jede Endung notwendig ist.

Gruss Gerhard

Nachtrag:

mein aktuells Konstrukt sieht so aus, denn es kommen auch Bilddateien aus dem external Ordner:

Code: [Auswählen]

<FilesMatch "(?<!\.css|\.js|\.jpg|\.jpeg|\.png|\.gif|\.webp|\.ico|\.svg)$">