Mit einem (*) markierte Elemente weisen darauf hin, dass es sich bei dem Element um eine grundlegende Lösung für das jeweilige Problem handelt. Sie sollten Ihr Bestes geben, um diese Inhalte zu vervollständigen. Elemente, die nicht mit (*) gekennzeichnet sind, weisen darauf hin, dass der Artikel Sicherheitsrisiken nicht vollständig beseitigen kann, sondern lediglich, dass Sicherheitsprobleme durch diese Methode vermieden werden können.
SQL-Injection
(*) Verwenden Sie beim Kombinieren von SQL-Anweisungen die SQL-Variablenbindungsfunktion
(*) Wenn die Datenbank keine Variablenbindung bietet, müssen Sie alle Variablen, aus denen die SQL besteht, maskieren und die Fehlermeldung nicht intakt im Browser anzeigen.
Legen Sie geeignete Berechtigungen für Benutzer fest, die auf die Datenbank zugreifen.
Befehlszeileninjektion des Betriebssystems
(*) Vermeiden Sie die Verwendung von Sprachen, die Shell-Befehle starten können. Sie müssen alle Variablen in den Parametern der Funktion überprüfen, um sicherzustellen, dass nur zulässige Operationen enthalten sind, und keine Pfadnamen-Parameter überprüfen. Verzeichnisdurchquerung.
(*) Verwenden Sie keine von außen übergebenen Parameter direkt als Dateinamen.
(*) Beschränken Sie Dateiöffnungsvorgänge auf feste Verzeichnisse und verbieten Sie, dass Dateinamen Pfade enthalten. Überprüfen Sie die Dateinamen-Sitzungsverwaltung.
(*) Verwenden Sie als Sitzungs-ID Inhalte, die schwer zu erraten sind
(*) Sitzungs-ID nicht in der URL speichern
(*) Legen Sie das sichere Attribut für Cookies fest, die im https-Protokoll verwendet werden
(*) Erzeugen Sie nach erfolgreicher Anmeldung eine neue Sitzung
(*) Generieren Sie nach erfolgreicher Anmeldung zusätzlich zur Sitzungs-ID eine geheime Information und überprüfen Sie diese bei jedem Besuch der Seite. Verwenden Sie keinen festen Wert als Sitzungs-ID.
Wenn Sie die Sitzungs-ID im Cookie speichern, legen Sie das Ablaufdatum fest. Cross-Site-Scripting-Angriff (XSS)
Lösung, wenn die Eingabe von HTML-Inhalten nicht zulässig ist
(*) Alles, was auf der Seite ausgegeben wird, muss maskiert werden
(*) Bei der Ausgabe von URLs sind nur URLs erlaubt, die mit „http://“ oder „https://“ beginnen
(*) <script>…</script>-Inhalte nicht dynamisch generieren
(*) Lesen Sie das Stylesheet nicht von einer externen Website. Lösung zur Überprüfung des Eingabeinhalts, wenn die Eingabe von HTML-Inhalten zulässig ist.
(*) Analysieren Sie den eingegebenen HTML-Inhalt, generieren Sie einen Analysebaum und extrahieren Sie dann die Nicht-Skript-Teile. Verwenden Sie Skripte, um relevante Zeichenfolgen im eingegebenen HTML-Inhalt zu löschen
(*) Geben Sie das Zeichensatzattribut „Content-Type“ im HTTP-Header der Antwort erneut an. Um den Verlust von Cookie-Informationen zu vermeiden, sollte die Trace-Methode deaktiviert und das HttpOnly-Attribut für alle Cross-Site-Anforderungsfälschungen festgelegt werden (CSRF)
(*) Der Zugriff auf alle Seiten erfolgt zufällig im ausgeblendeten Teil der vorherigen Seite. Die Seite überprüft die Informationen und führt sie nur aus, wenn sie korrekt sind.
(*) Vor Geschäftsabwicklung erneut Passwort anfordern
(*) Bestätigen Sie, ob der Referrer korrekt ist. Führen Sie nur dann wichtige Vorgänge durch und senden Sie eine E-Mail an die voreingestellte E-Mail-Adresse.
HTTP-Header-Injection
(*) Geben Sie HTTP-Header nicht direkt aus, sondern verwenden Sie die von der laufenden Umgebung bereitgestellte Ausgabe-API für Header-Informationen
(*) Wenn die API nicht verwendet werden kann, müssen Zeilenumbrüche in den Eingabe-Header-Informationen verboten werden.
(*) Verwenden Sie keine externen Parameter als E-Mail-Header-Informationen. Wenn Sie externe Parameter zum Festlegen der Header-Informationen verwenden müssen, löschen Sie die gefährlichen Zeichen.
Copyright-Erklärung: Sie können nach Belieben nachdrucken, aber beim Nachdruck muss der ursprüngliche Autor Charlee angegeben werden.
Ursprünglicher Link: http://tech.idv2.com/2008/04/19/secure-website-checklist/
Spezifische Referenz zur Anwendungsstrategie: PHP Practice Security Checklist