7
Wie man unter PHP SQL-Injection, CSRF und XSS-Angriffe verhindert
Web-Sicherheit ist ein zentrales Anliegen für jeden PHP-Entwickler. SQL-Injection, CSRF (Cross-Site Request Forgery) und XSS (Cross-Site Scripting) sind häufige Sicherheitsbedrohungen. In diesem Artikel wird erläutert, wie man diese Angriffe in PHP verhindern kann.
Verwendung von Prepared Statements
Die Verwendung von Prepared Statements ist eine der effektivsten Methoden zur Verhinderung von SQL-Injection. Prepared Statements trennen die Struktur der SQL-Abfrage von den Daten und verhindern so die Injektion von bösartigem SQL-Code.
Die Validierung und Filterung von Benutzereingaben ist entscheidend. Verwenden Sie Filterfunktionen, um sicherzustellen, dass der Eingabetyp dem erwarteten Typ entspricht, und validieren Sie bei Bedarf.
Verwendung von CSRF-Tokens
Generieren Sie ein eindeutiges CSRF-Token für jede Benutzersitzung und fügen Sie es in Formulare ein. Überprüfen Sie bei der Formularübermittlung, ob das Token mit der aktuellen Benutzersitzung übereinstimmt.
Same-Origin-Policy
Stellen Sie sicher, dass Ihre Anwendung die Same-Origin-Policy einhält, die nicht zulässt, dass Seiten von verschiedenen Ursprüngen direkt auf Ihre Schnittstellen zugreifen. Verwenden Sie CORS-Header, um erlaubte Ursprünge einzuschränken.
Ausgabe-Escaping
Bevor Sie Benutzereingaben in HTML einfügen, verwenden Sie die Funktion `htmlspecialchars`, um die Daten zu escapen und XSS-Angriffe zu verhindern.
Content Security Policy (CSP)
Verwenden Sie die Content Security Policy, um erlaubte Ressourcen zu definieren und die Ausführung von Skripten einzuschränken, wodurch XSS-Angriffe weiter verhindert werden.
Aktualisiert bleiben: Halten Sie PHP, Datenbanken und andere kritische Komponenten auf dem neuesten Stand, um sicherzustellen, dass bekannte Schwachstellen gepatcht sind.
Fehlerbehandlung: Konfigurieren Sie die Fehlerbehandlung so, dass sie ausreichende Informationen für Entwickler zur Fehlerbehebung bietet, aber deaktivieren Sie detaillierte Fehlermeldungen in der Produktion.
Sitzungssicherheit: Verwenden Sie sicheres Sitzungsmanagement, stellen Sie sicher, dass Sitzungs-IDs zufällig generiert werden und verwenden Sie HTTPS, um sensible Informationen während der Übertragung zu schützen.
Datei-Uploads: Überprüfen und validieren Sie hochgeladene Dateien, erlauben Sie nur sichere Dateitypen und speichern Sie hochgeladene Dateien an sicheren Orten.
Passwortspeicherung: Verwenden Sie Hash-Algorithmen (z.B. bcrypt) zur Speicherung von Passwörtern und fügen Sie geeignete Salze hinzu.
Eingabevalidierung: Führen Sie die Eingabevalidierung auf der Serverseite durch und verlassen Sie sich nicht nur auf die clientseitige Validierung, da diese leicht umgangen werden kann.
Logging: Implementieren Sie umfassendes Logging, um Sicherheitsvorfälle bei ihrem Auftreten untersuchen zu können.
Verhinderung von SQL-Injection
Verwendung von Prepared Statements
Die Verwendung von Prepared Statements ist eine der effektivsten Methoden zur Verhinderung von SQL-Injection. Prepared Statements trennen die Struktur der SQL-Abfrage von den Daten und verhindern so die Injektion von bösartigem SQL-Code.
// Verwendung von PDO Prepared Statements
$pdo = new PDO("mysql:host=localhost;dbname=mydatabase", "username", "password");
// Verwendung von benannten Platzhaltern
$statement = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$statement->bindParam(':username', $username);
$username = $_POST['username'];
$statement->execute();Niemals Benutzer-Eingaben vertrauen
Die Validierung und Filterung von Benutzereingaben ist entscheidend. Verwenden Sie Filterfunktionen, um sicherzustellen, dass der Eingabetyp dem erwarteten Typ entspricht, und validieren Sie bei Bedarf.
// Verwendung von filter_var zur Filterung von Eingaben
$email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL);
if ($email === false) {
// Ungültige E-Mail-Adresse
}Verhinderung von CSRF-Angriffen
Verwendung von CSRF-Tokens
Generieren Sie ein eindeutiges CSRF-Token für jede Benutzersitzung und fügen Sie es in Formulare ein. Überprüfen Sie bei der Formularübermittlung, ob das Token mit der aktuellen Benutzersitzung übereinstimmt.
// Generieren des CSRF-Tokens
$csrfToken = bin2hex(random_bytes(32));
$_SESSION['csrf_token'] = $csrfToken;
// Einfügen des CSRF-Tokens in das Formular
echo '<input type="hidden" name="csrf_token" value="' . $csrfToken . '">';
// Validierung des CSRF-Tokens
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
// CSRF-Angriff erkannt
die('Ungültiges CSRF-Token');
}Same-Origin-Policy
Stellen Sie sicher, dass Ihre Anwendung die Same-Origin-Policy einhält, die nicht zulässt, dass Seiten von verschiedenen Ursprüngen direkt auf Ihre Schnittstellen zugreifen. Verwenden Sie CORS-Header, um erlaubte Ursprünge einzuschränken.
// Setzen der CORS-Header in der Antwort
header("Access-Control-Allow-Origin: https://trusted-domain.com"); Verhinderung von XSS-Angriffen
Ausgabe-Escaping
Bevor Sie Benutzereingaben in HTML einfügen, verwenden Sie die Funktion `htmlspecialchars`, um die Daten zu escapen und XSS-Angriffe zu verhindern.
// Escape-Ausgabe
echo htmlspecialchars($_GET['user_input'], ENT_QUOTES, 'UTF-8'); Content Security Policy (CSP)
Verwenden Sie die Content Security Policy, um erlaubte Ressourcen zu definieren und die Ausführung von Skripten einzuschränken, wodurch XSS-Angriffe weiter verhindert werden.
// Setzen der Content Security Policy Header
header("Content-Security-Policy: default-src 'self'"); Allgemeine Sicherheitsempfehlungen
Aktualisiert bleiben: Halten Sie PHP, Datenbanken und andere kritische Komponenten auf dem neuesten Stand, um sicherzustellen, dass bekannte Schwachstellen gepatcht sind.
Fehlerbehandlung: Konfigurieren Sie die Fehlerbehandlung so, dass sie ausreichende Informationen für Entwickler zur Fehlerbehebung bietet, aber deaktivieren Sie detaillierte Fehlermeldungen in der Produktion.
Sitzungssicherheit: Verwenden Sie sicheres Sitzungsmanagement, stellen Sie sicher, dass Sitzungs-IDs zufällig generiert werden und verwenden Sie HTTPS, um sensible Informationen während der Übertragung zu schützen.
Datei-Uploads: Überprüfen und validieren Sie hochgeladene Dateien, erlauben Sie nur sichere Dateitypen und speichern Sie hochgeladene Dateien an sicheren Orten.
Passwortspeicherung: Verwenden Sie Hash-Algorithmen (z.B. bcrypt) zur Speicherung von Passwörtern und fügen Sie geeignete Salze hinzu.
Eingabevalidierung: Führen Sie die Eingabevalidierung auf der Serverseite durch und verlassen Sie sich nicht nur auf die clientseitige Validierung, da diese leicht umgangen werden kann.
Logging: Implementieren Sie umfassendes Logging, um Sicherheitsvorfälle bei ihrem Auftreten untersuchen zu können.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4320926329
Url: https://administrator.de/contentid/4320926329
Ausgedruckt am: 27.09.2024 um 23:09 Uhr
7 Kommentare
Neuester Kommentar
Diese Texte schreibt ChatGPT oder eine andere KI / bzw. ein LLM, habe ich Recht? 😄
6
Scheinbar versucht der Nutzer nun entsprechende Artikel aus SEO Gründen zu platzieren. Wahrscheinlich muss dann in Zukunft hierbei vorgegangen werden!
ehrlich gesagt - für mich siehts auch aus wie bei chatgpt o.ä. einmal reingeworfen, das ergebnis da rausgekratzt und hier reingekübelt.... denn das ganze ohne sinnvolle Erklärungen warum/wieso das gemacht werden sollte (und "weil is sicherer" ist zwar eine aber nicht zwingend eine ausreichende Begründung).
Von daher - sorry, 6, setzen... Sinnlos abgeschrieben vom Nachbarn.
Von daher - sorry, 6, setzen... Sinnlos abgeschrieben vom Nachbarn.
Wenn ich schon sehe, wie unnötige Variablen auch noch erst verwendet und dann deklariert werden... so ein Unfug riecht sehr nach "KI" :D
ebenfalls sollte man mit "die()" gerne mal vorsichtig sein -> das hat mit Fehlerhandling nix zu tun und kann dafür noch zu viel blöderen konsequenzen führen.. ne rückführung auf eine Fehlerseite (oder die Startseite) wäre da ggf. besser... aber ich vermute mal der TO fragt grad bei chatgpt nach den nächsten 50 tutorials um die ungefiltert hier einzukippen -> wäre ggf. mal ne funktionserweiterung hier -> frage eintippen und das ergebnis von cgpt direkt als manual anzeigen, würden dem TO ja min 3 tastendruck ersparen ;)
Ich persönlich habe mir in PHP ne funktion gebaut die inputs aus html forms z.B. auf bestimmte teilstrings prüft.
z.B. wenn ich erwarte das Vor und Nachname geliefert werden darf garantiert nicht ein SQL command mit rein Teilstring "Select" oder "Delete" oder sowas ... waren halt die gängigsten SQL commands drin...
ist vielleicht übertrieben aber sicher ist sicher
und wenn die funktion das halt feststellt wird er nicht das SQL command absetzen an die datenbank.
z.B. wenn ich erwarte das Vor und Nachname geliefert werden darf garantiert nicht ein SQL command mit rein Teilstring "Select" oder "Delete" oder sowas ... waren halt die gängigsten SQL commands drin...
ist vielleicht übertrieben aber sicher ist sicher
und wenn die funktion das halt feststellt wird er nicht das SQL command absetzen an die datenbank.
Zitat von @ThePinky777:
Ich persönlich habe mir in PHP ne funktion gebaut die inputs aus html forms z.B. auf bestimmte teilstrings prüft.
z.B. wenn ich erwarte das Vor und Nachname geliefert werden darf garantiert nicht ein SQL command mit rein Teilstring "Select" oder "Delete" oder sowas ... waren halt die gängigsten SQL commands drin...
ist vielleicht übertrieben aber sicher ist sicher
und wenn die funktion das halt feststellt wird er nicht das SQL command absetzen an die datenbank.
Ich persönlich habe mir in PHP ne funktion gebaut die inputs aus html forms z.B. auf bestimmte teilstrings prüft.
z.B. wenn ich erwarte das Vor und Nachname geliefert werden darf garantiert nicht ein SQL command mit rein Teilstring "Select" oder "Delete" oder sowas ... waren halt die gängigsten SQL commands drin...
ist vielleicht übertrieben aber sicher ist sicher
und wenn die funktion das halt feststellt wird er nicht das SQL command absetzen an die datenbank.
das hilft aber nur bedingt.... erstmal musst du hoffen alle befehle zu treffen. dann ist die frage was passiert mit umformatierten werten (zb als hex oder sonstwie codiert). da sind eben prepared statements in der regel besser - nur muss man das nich nur kopieren und als "manual" hier verkaufen...
2
