Wie kann man Code-Injection-Angriffe in PHP verhindern?

Ich bin nicht verwirrend, es gibt so viele functionen in PHP, und einige verwenden dies, einige verwenden das. Einige Leute benutzen: htmlspecialchars() , htmlentities() , strip_tags() usw

Welches ist das Richtige und was benutzt ihr normalerweise?

Ist das korrekt (bitte geben Sie mir einen besseren, falls vorhanden):

 $var = mysql_real_escape_string(htmlentities($_POST['username'])); 

Diese Zeile kann MySQL-Injection und XSS attact verhindern?

Übrigens, gibt es noch andere Dinge, die ich neben XSS-Angriff und MySQL-Injektion beachten muss?

BEARBEITEN

Schlussfolgern:

Wenn ich einen String in die database einfügen möchte, brauche ich keine htmlentities , htmlentities benutze den mysql_real_escape_string . Wenn Sie die Daten anzeigen, verwenden Sie htmlentities() , ist das, was Sie alle meinen?

Zusammenfassen:

  • mysql_real_escape_string wird beim Einfügen in die database verwendet
  • htmlentities() verwendet, wenn Daten in eine Webseite htmlentities()
  • htmlspecialchars() wann verwendet?
  • strip_tags() wann benutzt?
  • addslashes() wann verwendet?

Kann jemand das Fragezeichen ausfüllen?

    • mysql_real_escape_string wird beim Einfügen in die database verwendet
    • htmlentities() verwendet, wenn Daten in eine Webseite htmlentities()
    • htmlspecialchars() wann verwendet?
    • strip_tags() wann benutzt?
    • addslashes() wann verwendet?

    htmlspecialchars () wann verwendet?

    htmlspecialchars ist in etwa das gleiche wie htmlentities . Der Unterschied: Zeichenkodierungen.

    Beide codieren Steuerzeichen wie < , > , usw. zum Öffnen von Tags usw. htmlentities codieren auch Zeichen aus anderen Sprachen wie Umlaute, Euro-Symbole und dergleichen. Wenn Ihre Websites UTF sind, verwenden Sie htmlspecialchars() , andernfalls verwenden Sie htmlentities() .

    strip_tags () wann benutzt?

    htmlspecialchars / entities codieren die speziellen Zeichen, so dass sie angezeigt, aber nicht interpretiert werden . strip_tags ENTFERNT sie.

    In der Praxis hängt es davon ab, was Sie tun müssen.

    Ein Beispiel: Sie haben ein Forum programmiert und geben Benutzern ein Textfeld, damit sie Beiträge veröffentlichen können. Böswillige versuchen einfach:

     pictures of kittens here 

    Wenn Sie nichts tun, wird der Link angezeigt und ein Opfer, das auf den Link klickt, erhält viele Pop-ups.

    Wenn Sie Ihre Ausgabe haben, wird der Text so wie er ist. Wenn Sie strip_tag verwenden, werden die Tags einfach entfernt und angezeigt:

     pictures of kittens here 

    Manchmal möchten Sie vielleicht eine Mischung, lassen Sie einige Tags da strip_tags , wie ( strip_tags kann bestimmte Tags da strip_tags lassen). Dies ist auch unsicher, also verwenden Sie besser eine vollständig geballte Bibliothek gegen XSS.

    zusätzliche Schrägstriche

    Um eine alte Version des PHP-Handbuchs zu zitieren:

    Gibt eine Zeichenfolge mit Backslashes vor Zeichen zurück, die in databaseabfragen usw. quotiert werden müssen. Diese Zeichen sind single quote ('), double quote ("), Backslash () und NUL (das NULL- Byte).

    Ein Beispiel für die Verwendung von addslashes () ist, wenn Sie Daten in eine database eingeben. Um beispielsweise den Namen O'reilly in eine database einzufügen, müssen Sie diesen Namen entfernen . Es wird dringend empfohlen, eine DBMS-spezifische Escape-function zu verwenden (zB mysqli_real_escape_string () für MySQL oder pg_escape_string () für PostgreSQL), aber wenn das verwendete DBMS keine Escape-function hat und das DBMS \ verwendet, um spezielle Zeichen zu vermeiden kann diese function verwenden.

    Die aktuelle Version ist anders formuliert.

    Verschlüsseln Sie Daten nur an dem Punkt, an dem sie in das System gelangen, für das sie kodiert werden müssen. Andernfalls werden Sie in Situationen geraten, in denen Sie die realen Daten manipulieren möchten.

    Für die SQL-Injection – verwenden Sie gebundene Variablen wie in Wie kann ich die SQL-Injektion in PHP verhindern? (es handelt von vorbereiteten Aussagen, aber es ist die Bindung, die Ihnen Schutz gibt, nicht die Vorbereitung).

    Für XSS – wenn Sie in HTML an einem Punkt schreiben, an dem entweder HTML oder Text angegeben ist. Verwenden Sie htmlentities an dem Punkt, an dem Sie Ihr Dokument generieren. Ich würde vermeiden, die Daten in dieser Form in der database zu speichern (außer in einem schreib-selten-lesen-oft-System, wo CPU-performance / Festplattenzugriffszeiten wurden und Problem – dann hätte ich eine raw_ und eine html_ Version der Spalte … oder einfach memcached oder ähnliches verwenden).

    Wenn Sie den Benutzern die Eingabe von URLs javascript:do_evil() müssen Sie vorsichtiger sein, da javascript:do_evil() ein gültiger URI ist, der ausgeführt wird (zB als href für einen angeklickten Link oder (in manchen Browsern) die src eines Bildes, das ist gerade geladen).

    Ich dachte an diese schnelle Checkliste:

    • Verwenden Sie immer HTTPS, ohne HTTPS ist Ihre Site völlig unverschlüsselt . Und nein, die clientseitige Verschlüsslung und das Senden von Nachrichten funktioniert nicht, denken Sie darüber nach. Ungültige HTTPS-Zertifikate machen Sie auch anfällig für einen MITM- Angriff . Verwenden Sie Let’s Encrypt, wenn Sie sich kein Zertifikat leisten können.
    • Verwenden Sie htmlspecialchars() für jede Ausgabe Ihres PHP-Codes, htmlspecialchars() , oder enthält eine Benutzereingabe . Die meisten Templating-Engines helfen Ihnen dabei.
    • Verwenden Sie in Ihrer php.ini die php.ini Nur HTTP php.ini , um zu verhindern, dass Skripts auf Ihre Cookies zugreifen
    • Verhindert sitzungsbezogene Probleme
      • PHPSESSID niemals die PHPSESSID (Sitzungs-ID) des Benutzers außerhalb des Cookies dar . Wenn jemand eine Sitzungs-ID von jemand anderem erfährt, kann er diese einfach verwenden, um sich bei seinem Konto PHPSESSID
      • Seien Sie sehr vorsichtig mit der function Remember me , zeigen Sie vielleicht eine kleine Warnung.
      • Aktualisieren Sie die Sitzungs-ID, wenn sich der Benutzer anmeldet (oder wie auch immer)
      • Timeout für inaktive Sitzungen
    • Vertrauen Sie niemals einem Cookie, es kann jederzeit von einem Skript / Benutzer geändert, entfernt, modifiziert und erstellt werden
    • Verhindern Sie SQL-bezogene Probleme
      • Verwenden Sie immer vorbereitete statementen . Vorbereitete statementen führen dazu, dass die Benutzereingabe separat übergeben wird und SQL Injection verhindert wird
      • Lassen Sie Ihren Code eine Ausnahme auslösen, wenn er fehlschlägt. Manchmal ist Ihr SQL-Server aus irgendeinem Grund nicht PDO , Bibliotheken wie PDO ignorieren diesen Fehler standardmäßig und protokollieren eine Warnung in den Protokollen. Dies führt dazu, dass die Variablen, die Sie von der database erhalten, null sind. Dies kann je nach Code zu einem Sicherheitsproblem führen.
      • Einige Bibliotheken wie PDO emulieren vorbereitete statementen. Schalt das aus.
      • Verwenden Sie die UTF-8 Kodierung in Ihren databaseen, so können Sie praktisch jedes Zeichen speichern und verschlüsselungsbezogene Angriffe vermeiden
      • Verketten Sie niemals etwas mit Ihrer Anfrage . Dinge wie $myquery = "INSERT INTO mydb.mytable (title) VALUES(" . $user_input . ")" Ziemlich viel bedeutet, dass Sie ein großes Sicherheitsrisiko einer SQL-Injektion haben.
    • Speichern Sie hochgeladene Dateien in zufälligen, erweiterungsfreien Dateinamen. Wenn ein Benutzer eine Datei mit der Dateinamenerweiterung .php hochlädt, führt er sie aus, sobald der Code diese Datei lädt, und ermöglicht es dem Benutzer, einen Backend-Code auszuführen
    • Stellen Sie sicher, dass Sie nicht anfällig für einen CSRF-Angriff sind .
    • Aktualisieren Sie Ihre PHP-Kopie immer, um die neuesten Sicherheitspatches und performancesverbesserungen sicherzustellen

    Sie müssen nur mysql_escape_string () beim Einfügen in eine database und htmlentites beim Anzeigen des HTML verwenden. Dies reicht aus, wenn Sie einen einfachen Injektionsangriff verhindern möchten. Zweifelsohne sind jedoch viele andere Sicherheitsprobleme zu beachten, die Sie bei der Entwicklung einer Web-App beachten sollten. Ein weiterer wichtiger Aspekt sind Cross-Site-Request-Fälschungen.

    htmlspecialchars() & , ' , " , < und > in ein HTML-Entitätsformat um ( & htmlspecialchars() " , usw.)

    htmlentities() alle anwendbaren Zeichen in ihr HTML-Entitätsformat um.

    strip_tags() entfernt alle HTML- und PHP-Tags.

    Sowohl htmlspecialchars() als auch htmlentities() einen optionalen Parameter, der angibt, wie Anführungszeichen gehandhabt werden sollen. Details finden Sie im PHP-Handbuch.

    Die function strip_tags() verwendet einen optionalen Parameter, der angibt, welche Tags nicht entfernt werden sollen.

      $var = strip_tags ($var, '


    ');

    Die function strip_tags() entfernt sogar ungültige HTML-Tags, was zu Problemen führen kann. Zum Beispiel wird strip_tags() den ganzen Code, den er für ein HTML-Tag hält, herausziehen, selbst wenn er falsch gebildet ist, wie z

      

    Ich würde htmlentities () nicht verwenden, wenn ich Daten in die database einfüge oder die database abfrage. Wenn die Daten in Ihrer database als Entitäten gespeichert sind, sind diese Daten nur für etwas nützlich, das HTML-Entitäten versteht.

    Sie müssen verschiedene Escapemechanismen für verschiedene Ausgabetypen verwenden, zB SQL – mysql_real_escape_string () , HTML – htmlentities () oder htmlspecialchars () , shell – escapeshellarg () . Dies liegt daran, dass die “gefährlichen” Zeichen für jeden unterschiedlich sind – es gibt keinen magischen Weg, um Daten für jedes Ausgabemedium sicher zu machen.

    Werfen Sie einen Blick auf diese Seite PHP Security Consortium . Ich fand es eine gute Seite für einen allgemeinen Überblick über PHP-Sicherheit (SQL Injection und XSS enthalten).

    Ich weiß, dass es eine alte Frage ist, aber heutzutage kann die am meisten gewählte Antwort für die Anfänger irreführend sein.

    Ab 2017

    1. Sie sollten niemals mysql_real_escape_string verwenden. Selbst mysqli_real_escape_string ist zu schwach, um Ihre database vor SQL-Injections zu schützen. Stattdessen sollten Sie PDO und ähnliche Techniken verwenden. (Siehe diesen Leitfaden )

    2. XSS (hier meine ich: strip_tags() , addslashes() , htmlspecialchars() , htmlentities() ) – hier ist die meistgewählte Antwort immer noch korrekt, aber ich würde vorschlagen, diesen Artikel zu lesen