1) Funktion zum Entfernen schädlicher Bits
<?php
function cleanInput($input) {
$search = array(
'@<script[^>]*?>.*?</script>@si', // Strip out javascript
'@<[\/\!]*?[^<>]*?>@si', // Strip out HTML tags
'@<style[^>]*?>.*?</style>@siU', // Strip style tags properly
'@<![\s\S]*?--[ \t\n\r]*>@' // Strip multi-line comments
);
$output = preg_replace($search, '', $input);
return $output;
}
?>
2) Bereinigungsfunktion
Verwendet die obige Funktion und fügt zusätzlich Backslashes hinzu, um Datenbankfunktionen nicht zu beeinträchtigen.
<?php
function sanitize($input) {
if (is_array($input)) {
foreach($input as $var=>$val) {
$output[$var] = sanitize($val);
}
}
else {
if (get_magic_quotes_gpc()) {
$input = stripslashes($input);
}
$input = cleanInput($input);
$output = mysql_real_escape_string($input);
}
return $output;
}
?>
Verwendung
<?php
$bad_string = "Hi! <script src='http://www.evilsite.com/bad_script.js'></script> It's a good day!";
$good_string = sanitize($bad_string);
// $good_string returns "Hi! It\'s a good day!"
// Also use for getting POST/GET variables
$_POST = sanitize($_POST);
$_GET = sanitize($_GET);
?>
Ich verwende meine eigenen Funktionen wie folgt
Dabei wird das Präfix „fsk_“ für WYSIWYG-Editor-Variablen verwendet. Funktioniert einwandfrei.
@iMaxEst: Ich denke, Sie haben den Punkt verpasst. Die Vorbereitung von Daten ist nur ein Nebenschauplatz. Die Bereinigung von Daten verhindert Code-Injektionsangriffe.
stripslashes() != sanitize()
Wirklich nette Funktionen, Chris! Eine saubere Art, reguläre Ausdrücke zu verwenden. Diese Snippets werden definitiv ihren Weg in meine Bibliotheks-Skripte finden.
Vielen Dank!
Warum die Eingabe von HTML/Skript-Tags bereinigen?
Sie müssen sich nur dann um XSS kümmern, wenn Sie die Ausgabe vorbereiten!
Schützen Sie Ihre Datenbank mit vorbereiteten Anweisungen und htmlspecialchars() kümmert sich um die Ausgabe.
Die Antwort lautet: Leistung. Das Bereinigen der Eingabe und nicht der Ausgabe bedeutet, dass Sie eine potenziell ressourcenverbrauchende Routine einmal ausführen und höchstwahrscheinlich in einem separaten Bereich Ihrer Anwendung (d. h. vielleicht einem Mitgliederbereich, in dem der Traffic viel geringer ist als in einem öffentlichen Bereich). Das Bereinigen der Ausgabe bedeutet, dieselbe potenziell ressourcenverbrauchende Routine viele, viele Male auszuführen. Wenn die Website wächst und der Traffic zunimmt, werden CPU, Speicherplatz und Arbeitsspeicher zu wertvollen Gütern, die man möglicherweise durch ständiges Bereinigen der Ausgabe verschwendet, anstatt einfach die Wurzel des Problems zu bereinigen: die Eingabe. Außerdem werden Ihre Kosten steigen, da mehr Arbeitsspeicher, Speicherplatz und CPU benötigt werden, da mehr Maschinen und möglicherweise sogar leistungsfähigere Maschinen und Festplatten benötigt werden. Zum Nachdenken: In meinem Fall ziehe ich es vor, eine skalierbare, nachhaltige und saubere Webanwendung zu betreiben.
Es scheint eine gute Idee zu sein, die Eingabe zu bereinigen. Warum sollte ich potenziell bösartigen Code in meiner Datenbank speichern?
Was ist mit ASP? Jemand?
Phil, das kann für ASP.NET verwendet werden
AntiXSS schützt vor Cross-Site-Scripting und SQL-Injection
http://wpl.codeplex.com/
Diese Code-Snippets kommen über RSS nicht sehr gut an. Alle Zeilenumbrüche scheinen zu verschwinden.
Sie können den Bereinigungsprozess nach Belieben ändern. Je mehr Sie zulassen möchten, desto unsicherer ist Ihre Website und umgekehrt. Finden Sie eine für Sie passende Balance. Seiten mit wenig Traffic müssen sich nicht viel um Sicherheit kümmern, während Seiten mit hohem Traffic härtere Zeiten mit Sicherheit haben werden.
Ich persönlich würde mir ansehen, was ich den Leuten erlauben möchte und nur das zulassen. Dann verbiete ich alles andere. Meine regulären Ausdrücke sind im Allgemeinen so aufgebaut, dass sie auflisten, was verwendet werden darf, anstatt zu versuchen, die Dinge zu jagen, die ich nicht in meiner Datenbank speichern lassen möchte.
Ich muss sagen, dass dieses Beispiel ein schönes ist und ich denke, ich werde ein wenig damit experimentieren.
Diese sind nahezu nutzlos und überkompliziert; z.B. der HTML-Filter gleicht einfach alles mit „<" ab, warum also nicht explizit machen? Derzeit tut dieser Ausdruck nichts weiter, all dieser zusätzliche Kram dient nur dazu, das Problem zu verschleiern. Z.B. der JavaScript-Filter funktioniert nicht, alles, was ich tun muss, ist ein Leerzeichen hinzuzufügen: "scripthere”, der Browser wird verstehen, was ich meine, und das Skript wird ausgeführt.
Ich entschuldige mich, wer auch immer diesen Filter geschrieben hat, hat es sowohl richtig als auch falsch gemacht (falsch, weil er ihn einfach entfernt, anstatt ihn zu escapen, richtig, weil er ihn abfängt), ich habe ihn mit von Hand escapeden Zeichen bereinigt, das sollte funktionieren
Diese sind nahezu nutzlos und überkompliziert; z.B. der HTML-Filter gleicht einfach alles mit „<" ab, warum also nicht explizit machen? Derzeit tut dieser Ausdruck nichts weiter, all dieser zusätzliche Kram dient nur dazu, das Problem zu verschleiern. Z.B. der JavaScript-Filter funktioniert nicht, alles, was ich tun muss, ist ein Leerzeichen hinzuzufügen: „< script>scripthere</script>“, der Browser wird verstehen, was ich meine, und das Skript wird ausgeführt.
Meine ist ziemlich klein und praktisch, um böse Hacker-Injektionen loszuwerden
<SCRIPT SRC=http://hackers.com/xss.js></SCRIPT>
Das ist einfach fantastisch! Wirklich großartig. Vielen Dank.
meine entfernt einfach die Klammern.
Hallo,
Wir suchen einen Berater, der unsere Website bewerten und prüfen kann, wie anfällig wir für diese Art von bösartigen Skripten sind.
Gibt es Empfehlungen?
Vielen Dank,
Mark
Ich kenne keinen Berater, aber ich lese „pro PHP security – from application security principles to the implementation of XSS defenses“, das diese Dinge ziemlich gut erklärt
Mark, ich weiß nicht, ob du noch interessiert bist, aber ich habe mehrere Jahre in diesem Bereich gearbeitet. Es gibt auch mehrere andere Angriffsarten, die ich für Sie untersuchen kann. Kontaktieren Sie mich einfach unter http://www.matatechconsulting.com/contact/ für weitere Details.
Chris, warum deine Regexes anstelle von PHP's strip_tags() verwenden, wie von gibigbig vorgeschlagen? Ich verstehe nicht, welche Funktionalität durch diesen Weg hinzugefügt wird.
Gut, dass ich das gefunden habe. Ich habe gestern gerade darüber nachgedacht und brauchte eine bessere Funktion.
Ist die filter_var() Funktion gut? z.B. filter_var($value, FILTER_SANITIZE_STRING)
Danke für das Tutorial, das ist sehr nützlich
Der sicherste Weg ist, Eingaben durch die Verwendung von Klassen wie PDO zu parametrisieren, da PHP eine lose typisierte Sprache ist.
Oder wandeln Sie die Eingaben einfach in den erwarteten Typ um, z. B. Erwarten Sie eine Ganzzahl? Stellen Sie einfach (int) vor die Eingabe. Typumwandlung ist die schnellste Operation zur Bereinigung von Zahlen.
Hallo! Es ist ein guter Tag!
Ich teste nur, wie das funktioniert?
Ich denke, die Bereinigungsfunktion benötigt ein paar Zeilen Code, da diese beiden Werte nicht gefiltert werden
<script src=”js/jquery-1.6.4.min.js” />
<span><script src=”js/jquery-1.6.4.min.js”</span>
Danke fürs Zuhören
Ich meine, die cleanInput-Funktion. Entschuldigung
Hallo, kannst du mir bitte das Beispielergebnis der bereinigten Daten posten!
Lol „evilsite.com“
Aber die Effizienz dieser Funktion gefällt mir wirklich.
Schöne Funktionen, Chris!
Aber als ich sie ausprobierte, bekam ich diesen Fehler.
Warnung: mysql_real_escape_string() [function.mysql-real-escape-string]: Zugriff verweigert für Benutzer ''@'localhost' (mit Passwort: NO)
Warnung: mysql_real_escape_string() [function.mysql-real-escape-string]: Eine Verbindung zum Server konnte nicht hergestellt werden in
und das ist die Zeile Code, die den Fehler verursacht
$output = mysql_real_escape_string($input);aus dieser Funktion zum Entfernen schädlicher Bits
Sie müssen zuerst eine Verbindung zur Datenbank herstellen, bevor Sie mysql_real_escape_string() verwenden, sonst wird ein Fehler auftreten.
Ich verwende diese Funktion zum Escapen von Daten, die in die Datenbank gelangen
function escape($string = null)
{
if (empty($string))
{
return FALSE;
}
if (function_exists(‘mysql_real_escape_string’))
{
return mysql_real_escape_string($string);
}
else
{
return str_replace(“‘”, “\'”, $string);
}
}
Was Tags und XSS angeht, verwende ich etwas Hartgesotteres.... Wenn ich Hartgesottenes sage, bedeutet das, dass alles entfernt wird, was ich nicht will, und nur das zugelassen wird, was in einem Array aufgeführt ist, das ich im Skript definiere:-
public function input($string = null)
{
if (empty($string))
{
return ”;
}
// Entferne alle bbcode
$string = preg_replace(‘/\[(.*?)\](.*?)\[\/?(.*?)\]/iu’, ‘\\2’, $string);
// Konvertiere das ok Markup in bbcode
$string = preg_replace(array_keys($this->markup), $this->markup, $string);
// Entferne alle HTML-Tags
$string = preg_replace(‘/\(.*?)\/iu’, ‘\\2’, $string);
// Führe strip tags aus, um sicherzustellen, dass wir alles erfasst haben
$string = strip_tags($string);
// Ersetze doppelte Anführungszeichen durch einfache Anführungszeichen
$string = preg_replace(‘/(“)+/u’, “‘”, $string);
// Ein oder mehrere Leerzeichen abgleichen und durch ein einzelnes Leerzeichen ersetzen
$string = preg_replace(‘/( )+/u’, ‘ ‘, trim($string));
return trim($string);
}
Ich hoffe, diese beiden Funktionen helfen anderen.
Matt :)
$_POST = sanitize($_POST);$_GET = sanitize($_GET);
Das ist die schlechteste Methode zur Bereinigung, die ich je gesehen habe. Sie sollten die bereinigten Eingaben NIEMALS in denselben Datenstrom zurückspeichern. Der Hauptgrund dafür ist, dass das Skript ausgeführt werden kann und eine sekundäre Übermittlung fast augenblicklich die Werte von $_POST auf etwas anderes als das ändern kann, wofür die Eingaben bereinigt wurden.
Das bedeutet, dass jede nachfolgende Verwendung von $_POST nach dem Double-Post-Hack verunreinigt ist.
Die Speicherung der bereinigten Eingaben in einer sicheren Variable ist die beste Option.
Die Verwendung einer Whitelist ist ebenfalls eine gute Idee, da Sie durch die ausschließliche Annahme von Eingaben von bestimmten POST-Feldern auch die Möglichkeit eines POST-Hacks über eine Variable begrenzen, die Sie möglicherweise nie verwenden.
Außerdem... Strip_tags() existiert aus demselben Grund wie
$search = array('@]*?>.*?@si', // JavaScript entfernen
'@<[\/\!]*?[^]*?>@si', // HTML-Tags entfernen
'@]*?>.*?@siU', // Style-Tags ordnungsgemäß entfernen
'@@' // Mehrzeilige Kommentare entfernen
);
existiert. Die Funktion entfernt die Elemente aus einer Zeichenkette und deckt jedes HTML ab, das verwendet werden kann, um einen Server oder ein Skript zu kompromittieren.
Mein Hauptpunkt hier ist, dass $_POST, selbst wenn Sie es bereinigen, der Variable nicht vertraut werden sollte. Dinge können sich ändern. Was vor Nanosekunden existierte, ist möglicherweise nicht mehr der Fall, wenn Ihr Programm die Variablen verwendet. Sie öffnen sich für Probleme, wenn Sie keine sichere Methode zur Bereinigung und Verwendung von Datenströmen verwenden.Bei allem, was Gott und ein sicheres Web liebt, versuchen Sie bitte nicht, Ihre eigenen Bereinigungsmethoden zu schreiben. Verwenden Sie eine etablierte, von Fachleuten geprüfte Bibliothek.
Lesen Sie Pádraic Bradys Artikel „HTML Sanitisation: The Devil’s In The Details (And The Vulnerabilities)“ für weitere Details: http://blog.astrumfutura.com/2010/08/html-sanitisation-the-devils-in-the-details-and-the-vulnerabilities/
Nachdem ich meine eigene Methode (die ich oben gepostet habe) mit Web-Schwachstellen-Scannern ausgiebig getestet habe und dieselben Tests auf die Standard-PHP-Methoden, d. h. strip_tags und ähnliche, angewendet habe, ziehe ich es vor, bei meiner eigenen Methode zu bleiben.
Aber all das beiseite lassend: Wenn sich irgendein Entwickler, Kunde oder Hosting-Anbieter wirklich um die Sicherheit seiner Online-Produkte und Server kümmert, wird er den Verstand haben, eine serverweite einheitliche Sicherheitslösung wie ASL (Atomic Secured Linux) einzusetzen, um nicht nur Web-, sondern auch Server-Level-Angriffe abzuwehren.
Das tue ich.
Sehr interessantes Thema! Sicherheitsprobleme sind immer interessant und nützlich!
Verhindert dies SQL-Injektionen, indem Apostrophe escaped werden? Habe ich das richtig verstanden?
Wenn Sie mysql-real-escape-string verwenden, dann ja. ABER, um mysql_real_escape_string() zu verwenden, müssen Sie zuerst eine Datenbankverbindung herstellen, daher ist es besser, jede mysql_real_escape_string() Bereinigungsfunktion in Ihrer Datenbankklasse zu platzieren.
Ah ja, ich übergebe immer Verbindungsdaten an eine mysql_* Funktion, wo ich kann, und ich habe die Bereinigungsfunktion tatsächlich in meiner Datenbankklasse platziert.
Vielen Dank für die Bestätigung; jetzt kann ich beruhigt schlafen, ohne mir Sorgen über kleine Schurken machen zu müssen, die ein „); DROP TABLE valuabledata;– hineinlegen könnten.
Einfache Regeln, die ich in einem Webformular verwende.
1. Das Formular wird mit 3 Dingen gesalzen
a) Ein Salt-Wert, der ein Hash ist, basierend auf der angeforderten IP-Adresse und einem Serverwert, kombiniert, sodass Sie einen gesalzenen String erstellen, der in ein verstecktes Eingabefeld platziert wird.
b) Ein verstecktes „Honeytrap“-Eingabefeld, das immer leer sein soll und schreibgeschützt und deaktiviert ist. Sein Name ist nicht wichtig, aber ich setze den Namen oft auf die IP-Adresse des anfragenden Browsers, lege aber keinen großen Wert darauf, dass dies bei der Rückkehr zuverlässig ist.
c) Ein sekundäres verstecktes „Honeytrap“-Eingabefeld mit einem attraktiven Namen wie „login“, das ebenfalls schreibgeschützt und deaktiviert ist.
** Ich habe ein paar weitere Methoden, die ich verwende, um meiner Überprüfung eine weitere Schicht Zwiebel hinzuzufügen, und habe auch ein Formular, das eine Reihe von Feldern erzeugt, die zufällig benannt sind und auch auf ihre Anwesenheit im Postformular überprüft werden können, um weiter sicherzustellen, dass mein Server das Formular ausgestellt hat.
2. Das übermittelte Formular wird geprüft, sodass ein „Submit“-Element (der Button selbst ist Teil des Übermittlungsprozesses) vorhanden ist. Wenn nicht, wird das Formular abgelehnt.
3. Das Formular-Hashing wird dann neu berechnet und abgeglichen. Wenn es nicht übereinstimmt, bedeutet dies, dass die übermittelnde IP-Adresse nicht übereinstimmt. Das Formular wird abgelehnt.
4. Überprüfen Sie, ob die leeren Felder leer sind. Sie sind schreibgeschützt und deaktiviert, aber für einen BOT, der sich als Ihr Formular ausgibt, ist das unerheblich, da er alle Eingabeströme mit Daten füllt. Wenn Daten vorhanden sind, wird das Formular abgelehnt.
5. Wenn Ihr böser Wolf scheinbar in Ordnung ist, sollte Ihre Wache NICHT aufgeben... Sie sollten dann zu einer Whitelist für Ihre Eingabeströme übergehen, die SIE AKZEPTIEREN WERDEN.
6. Bereinigen Sie NUR die WHITE-LIST-Streams in ein Array, das Sie dann in Ihrem Skript verwenden werden. Sie sollten die integrierten PHP-Funktionen zur Bereinigung Ihrer Zeichenketten verwenden, da diese binär sicher sind.
7. Verwenden Sie NUR ein bereinigtes Array, um Ihre DATEN-Streams darin zu speichern, nachdem sie bereinigt wurden.
8. Verwenden Sie das integrierte mysql_real_escape_string zum Übermitteln in Ihre Datenbank, da dies sicherstellt, dass die übermittelten Daten den Server nicht mit einer schlecht formatierten Zeichenkette zum Absturz bringen.
Endlich....
Selbst wenn das Formular fehlschlägt, gebe ich trotzdem eine Dankesnachricht für die Einreichung aus und leite die Person NIEMALS zurück zur Formularseite, sondern zur Website-Startseite.
Vor allem: Wenn es komisch riecht, ablehnen, ablehnen, ablehnen... Leiten Sie den Besucher zur Website-Startseite und machen Sie es wie ich, haben Sie eine separate Datenbank mit verdächtigen IP-Adressen und wenn Sie von einer bestimmten IP-Adresse überschwemmt werden, gehen Sie damit um, indem Sie einfach die Formulardaten vollständig verwerfen und protokollieren, wie oft sie Daten senden, und wenn sie einen bestimmten Schwellenwert überschreiten, können Sie Ihr Formular diese IP-Adresse einfach ignorieren lassen, indem Sie eine 404-Fehlerseite ausgeben.
Ich muss sagen, dass viele hartgesottene Programmierer versuchen, dies mit den alten Argumenten von mehr als einer IP-Adresse und dass Hashes dekodiert werden können, zu verspotten oder Lücken hineinzubohren, und ich möchte den Mythos entkräften, dass die Verwendung von Rainbow Tables auf IP-Adressen zwar auf rohen IP-Adressen funktioniert, aber wie Sie Ihren Salt „kreativ“ hashen, nur dann funktioniert, wenn Sie eine serverseitige Ergänzung zum Hashing-Prozess verwenden. Dies hängt von Ihnen, dem Programmierer, ab, der kurze und vorhersehbare Salts in Ihrem Versuch verwendet, einen Hash zu erstellen, der nicht dekodierbar ist, wird von der Art und Weise abhängen, wie Sie dies tun. Wenn Sie also gehackt werden, liegt es an Ihrer Implementierung und der vorhersehbaren Natur.
Z.B.
$server_salt = „Ein unglaublich langer String, der zufällig sein sollte und sich erst ändert, wenn Sie ihn benötigen, um einem Rainbow-Table-Angriff auf Ihre IP-Adressen-Implementierung entgegenzuwirken, ist ratsam.“
$hash = md5( $_SERVER[‘REMOTE_ADDR’] . $server_salt );
Andere Methoden, die ich implementiert habe, umfassen die Stunde, in der das Formular angefordert wurde. Die Verwendung dieser Stunde im $hash, der in die Formularprüfung geschrieben wird, ermöglicht es Ihnen, zu alte Formulare abzulehnen. Das bedeutet, wenn ein Bot es schafft, Ihre Website zu imitieren, können Sie dies zumindest zeitlich begrenzen, auch mit Ihrem Hashing-System.
Dann haben Sie die Möglichkeit, Sitzungen zu verwenden, um eine weitere Schicht Paranoia zum Formular hinzuzufügen.
Ich hoffe, das ist jemandem nützlich, bitte gebt Anerkennung, wo sie fällig ist.
Ich verwende etwas Ähnliches, habe es aber nicht erwähnt, da sich dieser Thread mehr um die Bereinigung von Dateneingaben drehte. Aber hier ist die Methode, die ich verwende.
Vom Formular-Ende verwende ich einen Hash, der eine Kombination aus einem langen zufälligen Salt, plus dem MD5-Hash des aktuellen Tages, Monats, Jahres ist, was offensichtlich bedeutet, dass sich der endgültige Hash jeden Tag ändert, und all das wird mit SHA1 zu dem endgültigen versteckten Hash-Feld.
Was die eigentlichen Daten angeht, habe ich eine separate Validierungsklasse, um verschiedene Feldtypen zu überprüfen, wie z. B. E-Mail-Validierung, Passwort-Validierung und so weiter.
Bevor die Daten in die Datenbank gelangen, verwende ich eine Wrapper-Funktion, die alle HTML- und BBCode-Markierungen entfernt, die nicht auf einer definierten Whitelist stehen.
Dann verwende ich schließlich in der eigentlichen Abfrage ein modifiziertes mysql real escape string als letzte Sicherheitsstufe.
Aber wie ich bereits erwähnt habe, führe ich auch eine serverseitige/Kernel-Level-Sicherheitssuite aus.
Oh, und noch eine Sache, die ich hinzufüge, aber die ich nur für Daten verwende, die nicht entschlüsselt werden müssen, wie z. B. Passwörter, ist, für jeden Benutzer einen zufälligen Hash zu generieren, und dieser Hash wird während der Passwortvalidierung verwendet. Jeder Hash ist eindeutig und komplett zufällig, sodass die Verwendung einer Rainbow-Tabelle keine Hilfe wäre.
Und damit komme ich zu einem SEHR wichtigen Sicherheitspunkt. Unter KEINEN Umständen sollten Benutzerpasswörter im Klartext in einer Datei oder einer Datenbanktabelle gespeichert werden. Das ist ein häufiger Fehler und ein absolutes No-Go.
Diese Funktion hat viele Probleme. Filtert keine onclick-Ereignisse und filtert nicht den einfachsten Trick
Verwenden Sie HTML Purifier Das ist eine Bibliothek, die das tut, was Sie wollen. Und diese Leute haben viele Jahre Erfahrung in der HTML-Bereinigung. Vertrauen Sie ihm einfach.
Beispiel-Funktion zur Verwendung von htmlpurifier.
function clean($dirty_html, $valid_html = 'b,i,u,strong,em,strike,ul,ol,li,a[href],br,p[style],div[style]') { $config = HTMLPurifier_Config::createDefault(); $config->set('HTML.Allowed', $valid_html); $config->set('HTML.TidyLevel', 'medium'); $config->set('Cache.SerializerPath', $upload['uploadpath'] . '/htmlpurifier'); $config->set('Core.Encoding', 'UTF-8'); $config->set('HTML.Doctype', 'HTML 4.01 Strict'); $purifier = new HTMLPurifier($config); $clean_html = $purifier->purify($dirty_html); return $clean_html; }Hallo, kannst du mir bitte das Beispielergebnis der bereinigten Daten posten!
mysql_real_escape_stringwird ab PHP 5.5 als veraltet eingestuft (Dokumentation).Ich empfehle dringend, alle Ihre mysql-Sachen durch die PDO-Methode zu ersetzen. Wenn Sie jedoch eine schnelle Konvertierung benötigen, verwenden Sie mysqli_real_escape_string (beachten Sie das i?).
Hey,
Dieser Thread erscheint im Google-Index recht weit oben, wenn man nach PHP und der Bereinigung von Eingaben sucht.
Es ist eine Sache, zu bereinigen, wenn man zur Datenbank geht, eine andere sollte direkt in dem Moment geschehen, in dem man Benutzereingaben akzeptiert.
Auf diese Weise können Sie die Daten, mit denen Sie arbeiten, direkt korrigieren oder von Ihrem Kunden eine Korrektur verlangen.
Daher möchte ich eine Bereinigungsmethode für PHP beitragen
php.net Dokumentation
Die Funktionen filter_input und filter_var bieten eine ganze Reihe von Lösungen dafür.
Sie können Eingaben bereinigen (Eingaben in akzeptable Eingaben umwandeln) über die Bereinigungsfilter.
Sie können Eingaben validieren (prüfen, ob Eingaben dem erforderlichen Eingabetyp entsprechen) über die Validierungsfilter.
Letzteres gibt Ihnen die Möglichkeit, Ihre eigene Regex-Prüfung zu schreiben, falls erforderlich, sowie 'html'-Logik in 'Entwickler'-Logik zu transformieren, wie string('true') zu boolean(true).
Mit freundlichen Grüßen,
SakuraNoMae
Eine alternative und sehr einfache Lösung ist die Verwendung von 'HTML-Encoding' für den eingehenden Text, bevor er in die DB eingegeben oder beim Rendern verwendet wird. Kein Bedarf, etwas zu bereinigen.
gute Arbeit, danke,
für diejenigen, die HTML in die Datenbank einfügen, scheint sanitize(htmlspecialchars($input)) perfekt zu sein.
und wenn Sie ausgeben, sollten Sie htmlspecialchars_decode($output); verwenden.
Ich habe meine eigene Funktion erstellt und benutze diese
Sie ist ähnlich wie deine :D
bitte, was ist falsch an diesem Code
Das ist der Fehler, den ich bekomme, wenn ich auf den Button klicke
Das ist mein Code
mysql_real_escape_string ist veraltet