Verwaltungsseite sichern?

filament

Erfahrenes Mitglied
Hallo liebe Community,

Ich möchte eine eigene Verwaltungsseite für Kunden erstellen und mich vorher mal mit dem Thema Sicherheit beschäftigen. Daher hätte ich mal ein paar Fragen an die Fachleute hier.

Fallbeispiel:
Die Seite wird ausschließlich von MIR genutzt. Dazu erstelle ich einen Unterordner auf meiner Seite, welche sich bereits in einem Unterordner vom root befindet und mit rewrite getarnt ist.

Ich habe zu diesem Thema bereits etwas im Internet rumgelesen auf Blogs und auch im PHP Manual. Dort habe ich gelesen, dass es sinnvoller wäre ein Session-Login zu erstellen, als einen htaccess Ordnerschutz anzulegen, weil diese Datei im Klartext auf dem Server liegt. Natürlich würde ich diese trotzdem neben den Sessions nutzen um Robots etc auszuschließen. Stimmt das denn, könnt ihr das bestätigen?

Natürlich ist mir klar, dass ich die Eingaben aus Formularen trotz dessen das nur ICH zugriff haben werde, trotzdem überprüfen sollte. (intval, mysql real escape string etc.)

Aufgrund der Größe der Seite werde ich versuchen auf includes komplett zu verzichten bzw. Diese in einem separaten Ordner mit ebenfalls htaccess schutz zu hinterlegen.

Was könnte oder sollte ich an schutzmaßnahmen noch treffen? Es geht hier schließlich um Kundendaten, die ich möglichst sicher schützen will. Niemand will, dass diese an Dritte gelangen weil das System zu schwach ist.

Achso und noch eine Frage. Wenn ich cronjobs ausführe und ich ohne htaccess arbeite, wie definiere ich dem system dann die userdaten am sichersten, sodass es mit den sessions auch zugriff hat?

Danke im Voraus.
 
Aufgrund der Größe der Seite werde ich versuchen auf includes komplett zu verzichten
Wie darf man das verstehen? An includes ist grundsätzlich nichts falsch, eher sogar gut, weil sie die Lesbarkeit des Codes eindeutig verbessern.

Passwörter solltest du nur als Hashwert (vgl md5 oder sha1) speichern (sei es im script, datei oder datenbank) da sie so nicht ausgelesen werden können. Sessions solltest du auf jeden Fall verwenden. Natürlich alle Usereingaben mit mysql_real_escape_string() und ähnlichen Funktionen bearbeiten, denn es gibt immer den Fall des Falles, das doch jemand die versteckten Dateien findet. (Außerdem sollte man sich es gar nicht erst angewöhnen ohne die Funktionen zu programmieren).
Wenn du auf jeder Seite die dort verwendet wird ein
PHP:
session_start();
if( !isset($_SESSION['userid']) ){ header('Location: startseite.php'); exit(0); }
einbaust, werden nicht eingeloggte User direkt zur Startseite umgeleitet. Alternativ kannst du sie auch auf eine error 404 Seite umleiten und so den Anschein erwecken, dass es die besuchte Seite gar nicht gibt.
 
Naja ich dache das es sicherer wäre je weniger includes ich habe, weil die Angriffsfläche sinkt.

Das heißt also du stimmst der Aussage zu das Session sicherer sind als ein htaccess Schutz? Beides gleichzeitig zu nutzen macht aber wahrscheinlich wenig Sinn oder?

Das ich die Passwörter in der Datenbank als hash sollte, ist mir bekannt. Mache ich auch schon Jahre so. Macht es Sinn sie erst md5 und dann mit sha zu hashen, um den Schutz noch zu erhöhen?

Zu Sessions nochmal: Es gibt ja verschiedene möglichkeiten damit zu arbeiten. Ich habe z.b. bisher immer ohne die sessionid gearbeitet. Dazu habe ich einfach $_SESSION['id'] genutzt. Wäre die richtige sessionid da vielleicht noch sicherer? Macht eventuell session expired sinn? Sprich sollte ich die Session beenden wenn z.b. 10 Minuten nichts gemacht wird, wenn ja wie?

Und grundsätzlich nochmal: Cookies kann man ja manipulieren. Bauen Sessions nicht auch auf Cookies auf und wären so ebenfalls manipulierbar?
 
Beides zu nutzen halte ich für übertrieben, Sessions reichen da vollkommen aus. Erst md5 und sha1 zu nutzen macht auch wenig Sinn, baue lieber einen Salt mit ein. Dafür lege dir ein extra Feld "salt" in der Tabelle an.
PHP:
$salt = 'f$j1';
$passwort = 'geheim';
$hash = sha1(sha1($passwort).$salt);
mysql_query('INSERT INTO users SET password = "'.$hash.'", salt = "'.$salt.'"');
 

Neue Beiträge

Zurück