Verwaltungsseite sicher gestalten?

R

Ronny84

Angesehenes Mitglied
Hallo liebe Community,

ich möchte eine Verwaltungsseite für Kunden erstellen und mich vorher hier mal der Sicherheit wegen umhören.

Die Seite werde ich definitiv in einem Unterordner deponieren und via htaccess Datei serverseitig schützen. Auch Robots etc. werden ausgeschlossen in dieser Datei.

Nun aber die große Frage. Da ich das System als einzige Person benutzen werde, stellt sich mir die Frage, ob ein Login-System dann neben der htaccess Sicherung noch Sinn macht? Oder wäre ein Session Login sicherer als ein htaccess Schutz?

Sollte ich bei den Datenbankabfrage trotz dessen alle Eingaben an die Datenbank auf logisches überprüfen (Zahlenwerte nur Zahlen, Stichwort SQL Injektion -> mysql_escape_string) bevor ich diese einspeise? Weiterhin habe ich gelesen, dass man dem Script nur bestimmte Rechte beim Zugriff auf die Datenbank erlauben soll mittels Benutzerrechten. Ich kann mir gerade nicht ganz vorstellen, wie ich das machen kann? (Normal erstelle ich die Datenbank über das Verwaltungssystem meines Providers und bekomme Datenbank und Nutzer genannt, wo kann ich da noch Rechte einräumen?)

Dann habe ich weiterhin gelesen, dass man lieber PHP Code in eine HTML Datei implementieren soll, damit ein externer Besucher die Scriptsprache nicht gleich erkennen kann. Kann das jemand bestätigen, dass das sinnvoll ist?

Welche weiteren Sicherungsmöglichkeiten hätte ich? (Die Kundendaten sind mir immerhin sehr wichtig und auch heilig, wenn da was nach Außen dringt, verliere ich vielleicht einen Kunden.)

Ich wäre sehr froh, hier vielleicht von einigen erfahrenen PHP Programmierern etwas zu erfahren. Ich kenn mich zwar mit PHP / MySQL aus, aber das ist halt alles hobbymäßig und ich würde es auch nie verkaufen, was ich mache. Sicherheitslücken gibt es immer, es gilt halt diese zu minimieren.
 
Hallo,

QUOTE Nun aber die große Frage. Da ich das System als einzige Person benutzen werde, stellt sich mir die Frage, ob ein Login-System dann neben der htaccess Sicherung noch Sinn macht? Oder wäre ein Session Login sicherer als ein htaccess Schutz?

also htaccess hat bei normaler Authentifizierung mittels Benutzername/Passwort ganz klar einen Nachteil gegenüber ein System, welches mit Session arbeitet. Denn ob ich eine Session klaue, die ich nur während des aktiven Sitzung nutzen kann, kann ich die in Klartext übertragenen Benutzernamen und Passwörter jederzeit nutzen, bis es geändert wird. Auch werden bei htaccess natürlich bei jeden einzelnen Aufruf diese Informationen übertragen. Ergo ist im prinzipell beides schlecht bei einer ungesicherten Verbindung, nur das Zeitfenster zum Ausnutzen ist geringer (auch das mögliche Abgreifen von Benutzername und Passwort ist auf das Login beschränkt).




QUOTE Sollte ich bei den Datenbankabfrage trotz dessen alle Eingaben an die Datenbank auf logisches überprüfen (Zahlenwerte nur Zahlen, Stichwort SQL Injektion -> mysql_escape_string) bevor ich diese einspeise?

Klar musst Du alle Eingabedaten logisch prüfen, das steht absolut außer Frage.




QUOTE Weiterhin habe ich gelesen, dass man dem Script nur bestimmte Rechte beim Zugriff auf die Datenbank erlauben soll mittels Benutzerrechten. Ich kann mir gerade nicht ganz vorstellen, wie ich das machen kann? (Normal erstelle ich die Datenbank über das Verwaltungssystem meines Providers und bekomme Datenbank und Nutzer genannt, wo kann ich da noch Rechte einräumen?)

Das ist das Problem, wenn man die DB nicht selbst verwaltet, also den Provider Fragen, ob er Benutzer mit gesonderten Rechten anlegen kann. Sinnvoll ist dies auf jeden Fall.




QUOTE Dann habe ich weiterhin gelesen, dass man lieber PHP Code in eine HTML Datei implementieren soll, damit ein externer Besucher die Scriptsprache nicht gleich erkennen kann. Kann das jemand bestätigen, dass das sinnvoll ist?

Das macht nicht wirklich sind, weil damit alle HTML-Dateien wieder ausführbar sind, das Problem habe ich wohl schon mal geschildert: http://www.ayom.com/topic-56611.html#entry247975
Dann lieber den URL-Aufruf von .php Dateien auf einen 404er weiterleiten und die PHP-Dateien mittels RewriteRule als .html ausgeben. Aber es gehört etwas mehr dazu, um PHP zu verstecken, auch um PHP abzusichern.




QUOTE Welche weiteren Sicherungsmöglichkeiten hätte ich? (Die Kundendaten sind mir immerhin sehr wichtig und auch heilig, wenn da was nach Außen dringt, verliere ich vielleicht einen Kunden.)

Besser wäre es wohl die Kundendaten auf einen PC ohne Internet zu speichern und diesen komplett zu verschlüsseln, damit man diesen Ausstellen kann und ruhig schlafen kann, sollte den dann doch mal einer einfach so mitnehmen.

Wenn es um Authentifizierungen einer Website geht, nun da gibt es nur eine wirklich sinnvolle Kombination:
  1. Verbindungen nur mit HTTPS zulassen!
  2. Verbindungen nur mit genau aufgelistet Client-Zertifikation zulassen.
  3. Nach möglichkeit eine eigene CA erstellen für beides, und den privaten Schlüssel der CA sauber auf einen Offline Rechner stark verschlüsselt Speichern, oder noch besser auf einen USB stark verschlüsselt Speichern und in ein Bankschließfach oder minimum in einen sicheren Tresor legen.
 
Danke erst einmal für die ausführliche Antwort.

Natürlich wäre ein Offline-Rechner die beste Variante.
ABER: Ich mache das ja nicht nur, um die Kundendaten zu erfassen. Ich will gleichzeitig einen Backup schaffen. (Daten auf Webserver / Sicherung auf Rechner) So kann ich auf die Daten auch noch zugreifen, wenn eine der beiden "Datenspeichermöglichkeiten" ausfällt. (z. B. Festplatte am Laptop kaputt, Server beim Provider durch Wassereinbruch mit Datenverlust etc., man kann sich heute auf nichts zu 100% verlassen)

Weiterhin möchte ich einen Reminder innerhalb der Daten programmieren, um mich auf Termine oder Fristen hinzuweisen.

Dazu will ich Notizen zu den Kunden hinterlegen, damit ich bei späteren Kontakten (ob nun per Mail oder Telefon) alle Daten auf einen Blick habe und dementsprechend dem Kunden einen guten Service bieten kann. Welcher Kunde möchte schon bei jedem Gespräch nochmal alles neu erzählen, was vielleicht schon einmal erfasst wurde? Ich wäre dann als Kunde EX-Kunde. Eventuell sogar den Mail-Kontakt über die Seite herstellen und die Mail-Texte loggen. Das weiß ich noch nicht genau.

Nun zum eigentlichen Thema Sicherheit:

QUOTE also htaccess hat bei normaler Authentifizierung mittels Benutzername/Passwort ganz klar einen Nachteil gegenüber ein System, welches mit Session arbeitet. Denn ob ich eine Session klaue, die ich nur während des aktiven Sitzung nutzen kann, kann ich die in Klartext übertragenen Benutzernamen und Passwörter jederzeit nutzen, bis es geändert wird. Auch werden bei htaccess natürlich bei jeden einzelnen Aufruf diese Informationen übertragen. Ergo ist im prinzipell beides schlecht bei einer ungesicherten Verbindung, nur das Zeitfenster zum Ausnutzen ist geringer (auch das mögliche Abgreifen von Benutzername und Passwort ist auf das Login beschränkt).


Das heißt also ein Login mit Sessions wäre wesentlich sicherer als ein htaccess? Und wenn ich die htaccess Datei anderweitig schütze vor einem direkten Zugriff? In PHP kann man zum Beispiel den direkten Aufruf einer Datei (bei includes nutze ich das vor allem) verbieten. Die Frage also: Ist PHP Code in einer htaccess Datei erlaubt oder gibt es eine ähnliche Möglichkeit mit anderen Sprachen?


QUOTE Das ist das Problem, wenn man die DB nicht selbst verwaltet, also den Provider Fragen, ob er Benutzer mit gesonderten Rechten anlegen kann. Sinnvoll ist dies auf jeden Fall.


Dann werde ich meinen Provider dazu mal anschreiben.


QUOTE Das macht nicht wirklich sind, weil damit alle HTML-Dateien wieder ausführbar sind, das Problem habe ich wohl schon mal geschildert: http://www.ayom.com/topic-56611.html#entry247975
Dann lieber den URL-Aufruf von .php Dateien auf einen 404er weiterleiten und die PHP-Dateien mittels RewriteRule als .html ausgeben. Aber es gehört etwas mehr dazu, um PHP zu verstecken, auch um PHP abzusichern.


Bringt es mir denn wesentliche Vorteile das zu tun? Oder sind die Vorteile überschaubar, weil dann würde ich mir den Aufwand eigentlich eher sparen und PHP Dateien nutzen und die Scripte selbst schützen. Das Problem für jemanden, der da rein will ist doch wohl in erster Linie, die Kenntnis darüber, dass es die Dateien gibt und in welchem Unterordner diese sich befinden. Wäre das denn rein theoretisch schwierig herauszubekommen? Weil wie gesagt ich nutze die "Unterseite" als einzige Person und gebe diese an keine Dritten weiter.

Und selbst wenn die Person das dann herausfindet, müsste er ja dann noch den Login knacken oder nicht? Und wenn ich nicht gerade "admin" "admin" nutze - was ja sträflichst wäre -, dann müsste eine Person die da rein will schon einiges Aufbringen, um die md5 codierung zu knacken oder nicht?


QUOTE 1.Verbindungen nur mit HTTPS zulassen!
2.Verbindungen nur mit genau aufgelistet Client-Zertifikation zulassen.
3.Nach möglichkeit eine eigene CA erstellen für beides, und den privaten Schlüssel der CA sauber auf einen Offline Rechner stark verschlüsselt Speichern, oder noch besser auf einen USB stark verschlüsselt Speichern und in ein Bankschließfach oder minimum in einen sicheren Tresor legen.


Mit der Thematik habe ich mich bisher als Hobbywebmaster nicht großartig beschäftigt. Ich verfüge über einen SSL Server bei meinem Provider. Ich habe allerdings keine Ahnung wie genau ich das ganze einrichte und wie ich Verbindungen herstelle etc. Aber ich weiß natürlich, dass eine SSL Verbindung zu knacken noch einmal einen Zacken schwerer sein dürfte. Hast du vielleicht ein paar Tutorials dazu oder sowas?
 
Also ich antworte mal eben so.

Die Auth Basic von htacess hat immer den Nachteil die Passwörter in Klartext zu übertragen, man könnte natürlich mit Auth Digest, was etwas sinniger wäre. Grundsätzlich sollte aber auf jeden Fall eine SSL-Verschlüsselung sein. Die eigene CA gerade deswegen, da viele andere CAs unter der Hand die gängige Praxis haben auch mal ein Zertifikat auszustellen, damit jemand sich zwischen den Datentransfer schalten kann, daher lieber eine eigene CA aufbauen und diese verteilen.

Grundlegen brauchst Du bei einer Client-Zertifizierung nicht unbedingt die PHP-Dateien verstecken, wäre aber halt sinnig, je nachdem wer sonst noch Zugriff auf die Anwendung bekommen soll. Selbst wenn nicht, das wichtigste wäre eh erst mal nur die Versionsnummer von PHP nicht heraus zu brüllen, alles andere ist grundlegend überschaubar, auch wenn ich immer dazu raten würde, so gut es geht zu verstecken, womit wirklich gearbeitet wird. Jede überflüssige Information an einen Angreifer ist ein Nachteil für die Sicherheit einer Website.

Beim Login ist wohl der Angriff mittels Brute-Force gemeint, das kann man verhindern, indem die Verifikation des Passwortes immer eine Zeit X dauert, egal ob er nun auch schneller durch ist, also wenn die Applikation die Anmeldedaten mal in 10 ms, mal in 24 ms und mal in 50 ms check, kann man hier auch pauschal sagen, es dauert immer 250 ms oder 500 ms. Somit muss jede Anfrage erstmal abgearbeitet werden. Dann kann eine Anfrage nur alle 2 Sekunden kommen von einer IP. Eingeben der Daten plus Check von 0,5 Sek. Bei 5 Fehlermeldungen kann auch mal eben der Benutzer für 5 Minunten gesperrt werden. Bei 10 Fehlversuchen dann eben 15 min usw., damit ein Brute-Force einfach gut genug ausgebremst wird. Passwörter als reinen MD5 sollte man lange nicht mehr speichern, minimum mit SALT, am besten mit einigen durchläufen, und dazu am besten noch einen anderen Hash verwenden wie SHA-256 oder SHA-512.

Als Grundlage für den Einsatz mit Client-Zertifikaten kann ich wohl auf diese Dinger verweisen, auch wenn es nicht gerade der Weisheit letzter Schluss ist, da hier teilweise ewig veraltetes Wissen genutzt wird (insbesondere in Punkte Schlüsseltiefe), was ich wohl auch beim erten Eintrag angemerkt hatte. Beim Überfliegen habe ich wohl die richtig Client-Authentifizierung gegenüber den Webserver gefunden in einen Beitrag, aber ohne auf die möglichen Fallstricke dabei hinzuweisen.

http://www.phpgangsta.de/client-zertifikat...er-login-ersatz
http://www.noatun.net/docs/ssl_client.html#7
http://www.vanemery.com/Linux/Apache/apache-SSL.html


Ich selber habe für mich selber so eine Authentifizierung seit etwa 3 Jahren am Laufen, auch wenn der Wunsch GnuTLS dafür zu verwenden gescheitert ist, also muss halt mod_ssl zwingend her.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben