PHP Mögliche Schutzmechanismen für die Website

[_CH_K_1991_]

Hallo zusammen

Ich habe eine ganz generelle Frage zu Schutzmechanismen, die dann greifen sollen, wenn die Website angegriffen wird, z.B. über SQL Injection und anderes Zeugs.
Ich habe zwar schon Websiten geschrieben und kenne sicherlich bereits das eine oder andere über PHP, DB's oder HTML aber in meiner Ausbildung wurde meiner Meinung nach bisher die Sicherheit ein bisschen vernachlässigt. Deshalb möchte ich gerne einige Sachen von euch (Fakten wie auch Meinungen) über das Sichern von Websitenlogins und das sichere Speichern von Daten wissen.

1. Was für gängige Angriffe gibt es auf Websiten mit Login und Datenbank (SQL Injection, Einschleusen von Scripts)
2. Wie kann ich Datenbankzugriffe so gut als möglich absichern (also z.B. das Login Script in einen gesicherten Ordner legen, wo nur der Server Zugriff hat, u.s.w.)
3. Sichers übertragen vom Client zum Server (z.b. SSL)
4. Sichers Speichern von Daten in eine Datenbank (z.B. Passwörter gesalzen mit einem MD5 Hash speichern)

Es wäre schön, wenn Ihr mir eine Angriffsmöglichkeit und einen möglichen Schutz dagegen nennen könntet. Das Ziel des Beitrags sollte eine Diskussion über dieses Thema sein und eine Linksammlung, da ich eigentlich vergeblich solche Seiten als Sammlung gesucht habe aber eine solche für die sichere Entwicklung von Websiten vonnöten ist.

Links:
http://www.danielfett.de/internet-und-opensource,artikel,web-sicherheit
http://php.net/manual/de/function.htmlspecialchars.php
http://de.wikipedia.org/wiki/Cross-Site-Scripting
http://blog.botfrei.de/2013/03/angriffe-auf-meine-webseite-aber-wie-rfilfisqli-was-ist-das/
OWASP:
https://www.owasp.org/index.php/Category:Attack
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

PS: werde die möglichen Links im 1. Beitrag sammeln für Zukünftige Leser

Ich danke Euch.

 

[DjNDB]

Eine wichtige Anlaufstelle ist OWASP. Da gibt es unter anderem Beschreibungen von Angriffstechniken und Gegenmaßnahmen und eine Top 10 für Schwachstellen und Fehler.

 

[_CH_K_1991_]

oh super, thx
Werde sicher die Top 10 Liste noch genauer durcharbeiten.

 

[DjNDB]

Falls du etwas praktisches suchst wo du dich durcharbeiten und Schwachstellen live erleben und erforschen kannst, dann kann ich noch Gruyere und Webgoat empfehlen.

 

[Daaron]

[*]Was für gängige Angriffe gibt es auf Websiten mit Login und Datenbank (SQL Injection, Einschleusen von Scripts)

SQL Injection ist bei wirklich schlechten Seiten schnell gemacht. Ansonsten natürlich XSS, Brute-Force, evtl. noch Cookie Spoofing

[*]Wie kann ich Datenbankzugriffe so gut als möglich absichern (also z.B. das Login Script in einen gesicherten Ordner legen, wo nur der Server Zugriff hat, u.s.w.)

Serverseitig sollte es so oder so dementsprechend aussehen, dass nur root und der jeweilige "Benutzer", unter dem die Webseite läuft, auf irgend etwas davon Zugriff hat. Andernfalls hat der Admin totalen Mist gebaut. Das fängt ja schon damit an, dass oftmals tatsächlich noch www-data der Besitzer des Apache-Prozesses ist....
Schutz vor SQL Injections ist hingegen leicht, nur sind viel zu blöd diese einfache Methode zu nutzen: Prepared Statements.

[*]Sichers Speichern von Daten in eine Datenbank (z.B. Passwörter gesalzen mit einem MD5 Hash speichern)

Besser als Klartext, besser als ungesalzen... da hörts aber schon wieder auf.
Ein anständiger Hashing-Algorithmus wäre angebracht.... und wenn es die neue Crypt-API von PHP5 ist. Allemal deutlich besser als MD5+Salt.

 

[ice-breaker]

Wie kann ich Datenbankzugriffe so gut als möglich absichern (also z.B. das Login Script in einen gesicherten Ordner legen, wo nur der Server Zugriff hat, u.s.w.)

es liegt nur genau eine (!) PHP-Datei im öffentlichen Pfad deines Webservers, diese wird aufgerufen. Und includet dann als Front Controller alle anderen PHP-Dateien die außerhalb des htdocs liegen.

Sichers Speichern von Daten in eine Datenbank (z.B. Passwörter gesalzen mit einem MD5 Hash speichern)

Das ist schon lange obsolet. Moderne Grafiken können 1 Mrd. Hashes pro Sekunde testen. Bcrypt oder PBKDF2 sind der aktuelle Weg. Beides in PHP 5.5 vorhanden, ersteres ist mit der Passwort-API leicht zu nutzen, es gibt auch nen backport, von ircmaxell auf Github.

Es wäre schön, wenn Ihr mir eine Angriffsmöglichkeit und einen möglichen Schutz dagegen nennen könntet.

Da sind wir Tage beschäftigt! Es gibt dutzende Angriffsmöglichkeiten. Das OWASP ist enin guter Anfang, einfach mal weitergooglen, es gibt in dem Bereich auch einige Bücher. Früher von Stefan Esser (Month of PHP Bugs), wird glaube ich aber seit Jahren nicht mehr gedruckt und ein etwas "neueres" von Mario Heidrich. Und "The Tangled Web" habe ich auch gerade im Gedächtnis, aber in das selbst noch nie reingesehen.


Ich kann Daarons Liste noch um CSRF ergänzen, das würde erstmal den Großteil abdecken.

 

[_CH_K_1991_]

Hey Daaron
Danke für deine Antwort.
Zu deinem zweiten Punkt.
Wenn ich jetzt einen Hosting Anbieter habe, welcher logischerweise mehr als einen Kunden auf einem Server betreut wird dieser ja eine ähnliche Ordnerstruktur wie folgt haben:
//Server/VirtualHost/Kunde/httpdocs

Jetzt ist doch alles relativ sicher, was auf der Ebene "Kunde" gespeichert wird. Oder nicht?
Da ja der Webpfad bis ins httpdocs (oder halt www) Verzeichnis führt.

Von der Crypt-API habe ich noch nie etwas gehört. Also werde ich mich noch über diese Informieren.

Danke und Gruss

 

[ice-breaker]

Das kommt auf die Konfiguration des Webhostings an. Wenn für jeden Nutzer ein eigener PHP-Prozess läuft und dafür eigene Linux-Nutzer angelegt wurden sind die einzelnen Kunden gut untereinander isoliert, das stimmt.
Wird dagegen die mod_php Hölle des Apache genommen, wird sich voll und ganz auf die Schutzmechanismen des open_basedir von PHP verlassen, aber wehedem da ist ein Bug drinne, was oft genug der Fall war...

 

[F_GXdx]

Inwiefern ist eigentlich XSS ein Problem für Seiten, wo Cookies und Sessions nur zu "Komfort-Zwecken" verwendet werden?

 

[ice-breaker]

Was genau meinst du mit "Komfortzwecken"? Hast du ein Login auf der Seite? Kann ein Nutzer da irgendwas machen? Stört es dich bzw. den Nutzer wenn ein "Hacker" mit XSS Aktionen in dessen Namen ausführen kann? Wenn du 3mal mit nein geantwortet hast, wird eine XSS-Lücke auf deiner Seite wahrscheinlich auch kein Problem sein. AUSER: Der Hacker kann durch XSS beliebigen JavaScript Code einbinden und deine Seite manipulieren, Texte austauschen ist da dein geringstes Problem.

Also ja, XSS ist immer ein Problem.

 

[F_GXdx]

Naja, Wordpress zum Beispiel. Da hat man ja eigentlich nur Suche, Admin-Panel und Kommentar-Felder. Aber da gibts ja keine Probleme mit XSS, wenn man nur die WP API-Mechanismen verwendet.

 

[_CH_K_1991_]

Hey ice-breaker

Danke für deine Antworten, habe die erste nicht sofort gesehen, da ich wohl den Antwort Post geschrieben habe.
Ich werde mal heute Abend noch etwas zu CSRF heraussuchen.

Wegen deiner Anmerkung "Da sind wir Tage beschäftigt!", es geht mir einfach darum, dass meine Seiten welche ein Login/Usersystem bieten und unterumständen auch Sensitive Daten in Datenbanken speichern nicht mit einem "Bubenstreich" angegriffen werden können. Ob ein System total sicher ist oder nicht, bemerkt man eh erst bei einem ersten Angriff (egal ob von aussen oder Vorteilhaft natürlich ein eigener Angriff auf die Website). Die Problematik ist nur, wenn man sich nicht unbedingt mit dem "Hacken" beschäftigt, kann man nur schwer mögliche und vor allem auch einfache Lücken schliessen. Denn ich denke der Aufwand eine Website zu knacken die, die einfachen Lücken geschlossen hat, erhöht sich sicherlich eher exponentiell und die Zahl der Personen die das können nimmt gleichzeitig stark ab. Oder ist dem nicht so?

 

[ice-breaker]

Doch dem ist so. Und die üblichen verdächtigen stehen eben alle im OWASP.

 

[Daaron]

es liegt nur genau eine (!) PHP-Datei im öffentlichen Pfad deines Webservers, diese wird aufgerufen. Und includet dann als Front Controller alle anderen PHP-Dateien die außerhalb des htdocs liegen.

So eine Struktur ist zwar theoretisch möglich, praktisch hab ich sowas aber noch nie in Aktion gesehen. So etwas könnte man nur umsetzen, wenn man das PHP-Projekt zu 100% in Eigenregie entwickelt und der Server es zulässt, dass du Ordner außerhalb deines HTML-Ordners anlegst. Würde dir bei uns z.B. schwer fallen, da bei uns das immutable-Flag gesetzt ist um "versehentliche" Änderungen zu vermeiden.
Das Höchste der Gefühle ist normalerweise, das die meisten Unterordner per .htaccess Deny All abgeriegelt werden.

Wenn ich jetzt einen Hosting Anbieter habe, welcher logischerweise mehr als einen Kunden auf einem Server betreut wird dieser ja eine ähnliche Ordnerstruktur wie folgt haben:
//Server/VirtualHost/Kunde/httpdocs

Jetzt ist doch alles relativ sicher, was auf der Ebene "Kunde" gespeichert wird. Oder nicht?
Da ja der Webpfad bis ins httpdocs (oder halt www) Verzeichnis führt.

Nö. Kommt drauf an...
Bei dämlichen Webmastern gehören all die verschiedenen DocumentRoots der verschiedenen Virtual Hosts trotzdem alle www-data. Da auszubrechen ist zwar mit ner FTP-Verbindung nicht gerade leicht, mit PHP hingegen ist es Kinderkacke.

Wenn hingegen jedem DocRoot ein separater User zugewiesen ist, unter dem auch der Apache bzw. PHP-Interpreter läuft, kommst du nicht raus.

Wird dagegen die mod_php Hölle des Apache genommen, wird sich voll und ganz auf die Schutzmechanismen des open_basedir von PHP verlassen, aber wehedem da ist ein Bug drinne, was oft genug der Fall war...

Hey, nix gegen mod_php. Ich verwende tatsächlich ab und zu mod_php in Kombination mit separaten Usern... MPM-ITK heißt das Zauberwort.
Vorteil gegenüber mpm-prefork (&co) + suPHP: viel viel schneller, unterstützt OpCode-Cache
Vorteil gegenüber FastCGI+SuEXEC: viel leichter zu konfigurieren (beinahe Nobrainer, 3-4 Zeilen zusätzlich in der jeweiligen VHost.conf) & eine separate php.ini ist möglich
Nachteil gegenüber FastCGI+SuEXEX: etwas langsamer (durch den zusätzlichen Fork) und es gibt Interferenzen mit mod_ruby.

Naja, Wordpress zum Beispiel. Da hat man ja eigentlich nur Suche, Admin-Panel und Kommentar-Felder. Aber da gibts ja keine Probleme mit XSS, wenn man nur die WP API-Mechanismen verwendet.

Wordpress hat, soweit ich weiß, immer noch reichlich XSS-Probleme. Wenn hier ein XSS-Angriff erfolgreich ist, dann kann der Angreifer per Cookie Spoofing deinen Account kapern. Und tschüß, Admin.

 

[macos]

Hey, nix gegen mod_php. Ich verwende tatsächlich ab und zu mod_php in Kombination mit separaten Usern... MPM-ITK heißt das Zauberwort. ...und es gibt Interferenzen mit mod_ruby.

Eine Interferenz mit mod_rails wäre aber besser... mod_ruby ist nämlich outdated und so gut wie tot... mod_rails aka Passenger ist das aktuelle Ruby Mod für den Apache / nginx

 

[Daaron]

Interferenz soll heißen: Wenn mod-ruby installiert ist, dann geht was SCHIEF... und zwar ein Neustart des Apache-Dienstes. Irgendwo bleibt was hängen und man muss erst alle Apache-Instanzen mit kill -9 verabschieden.

Ob der Bug auch mit mod-rails auftritt kann ich dir nicht sagen. Tangiert mich wenig, wir nutzen weder Ruby noch RoR.