PHP: „intelligent“ Slashes entfernen [Update]
Eine Funktion, die etwas „Intelligenz“ bei der Säuberung der Ausgabe vor „Escapes“ (\) verwendet.
Ganz egal, ob der String aus POST, GET, COOKIE (mit ein- oder ausgeschaltetem „magic_quotes_gpc“)
kommt oder aus der Datenbank („escaped“ oder nicht), er wird korrekt aber ohne Escape-Zeichen (\) ausgegeben.
[code]
[/code]
[UPDATE 24.03.2008] Die Prüfung der get_magic_quotes_gpc war Unsinn. Leider zu spät gemerkt.
Hat natürlich die gesamte „Intelligenz“ der Funktion sinnlos gemacht.
| c:\doc | c:\doc |
| Eingabe | Ausgabe |
|---|---|
| c:\\doc | c:\doc |
| O\’Reilly | O’Reilly |
| c:\\doc\\O\’Reilly | c:\doc\O’Reilly |
| c:\doc\O’Reilly | c:\doc\O’Reilly |
ANMERKUNG:
Die Funktion entscheidet nicht für Teilstrings, ob eine Konvertierung erfolgt oder nicht.
Wenn die Eingabe also gemischte („escapte“ und nicht „escapte“) Stringstücke enthält, wird NICHT konvertiert.
| c:\doc\O\’Reilly | c:\doc\O\’Reilly |
Die beworbene Intelligenz _kann_ _nicht_ funktionieren. Wenn z.B. der String O\’Reilly vom Benutzer eingegeben wurde (explizit mit der Zeichenfolge Backslash-Single_Quote), das ganze dann z.B. via GET beim Skript landet und Magic Quotes deaktiviert sind, weiss die Funktion nicht, ob der Backslash vom Benutzer kommt, oder durch die Magic Quotes Funktionalität hinzugefügt wurde. Im beschriebenen Szenario wird der Backslash fälschlicher Weise aus dem String entfernt.
stripslashes darf nur genau dann auf einen String angewandt werden, wenn bekannt ist, dass Backslashes hinzugefügt wurden um Sonderzeichen zu schützen. Man kann i.A. nicht aus den Daten erraten, ob dies geschehen ist oder nicht.
„Man kann i.A. nicht aus den Daten erraten, ob dies geschehen ist oder nicht.“
Nein, im Allgemeinen kann man das nicht.
Ich behaupte jedoch, dass in einer Webanwendung in der normalerweise keine „Backslashes vor Sonderzeichen“ zur Eingabe gehören, die Funktion gute Dienste leistet. Dein Einwurf mit den abgeschalteten Magic Quotes sollte allerdings in der Funktion auch Berücksichtigung finden, wobei dann die Effizienz noch einmal gesteigert wird.
In welchem Kontext soll die Funktion gute Dienste leisten?
Wenn magic_quotes_gpc aktiviert ist? Dann lässt man stripslashes einfach über alle GPC Daten laufen. Die seq_remove_slashes Funktion böte da nur einen Vorteil, wenn PHP selbst einen Bug hätte und fehlerhafte Backslashes einstreut. Und dann wäre man mit einem „die(‚PHP sucks‘)“ weitaus besser bedient, für den Fall, dass addslashes(stripslashes($foo)) != $foo.
Wenn magic_quotes_runtime aktiviert ist? Dann sollte man das einfach mal abschalten…
Daten sollte bis zu genau dem Zeitpunkt in dem sie „geschützt“ benötigt werden in Rohform vorliegen, und auch nur genau für den Zweck für den sie geschützt werden müssen in geschützter Form vorliegen. Alles andere killt die allgemeine Verwendbarkeit von z.B. Funktionen.
function validateBla($foo)
{
// Might be slashed user input
$foo = seq_remove_slashes($foo);
// Whatever needs to be validated
}
Natürlich, das funktioniert, solange das Programm niemals gültige Daten der Form „O\’Reilly“ oder so erhält. Falls es das doch tut, müsste ich ggf. nen addslashes() verwenden bevor ich die Funktion aufrufe, z.B. wenn die Daten neuerdings auch via XML Schnittstelle kommen, und dementsprechend keinen Magic Quotes unterworfen sind. Und natürlich muss der addslashes Aufruf dann dort erfolgen wo ich weiss, dass die Daten nicht den Magic Quotes unterworfen sind. Wenn validateBla dann erst über 2, 3 Ebenen erreicht wird, hab ich in irgendwelchem High-Level Code direkte Abhängigkeiten zur Implementierung von validateBla(), dass von dort nicht mal direkt aufgerufen wird.
Und selbst für den Fall, dass ich niemals \‘ oder ähnliches erwarte und in Kauf nehme, dass ich die Eingabedaten verfälsche, also keine addslashes Aufrufe einbaue, kleistere ich mir auf diesem Weg doch nur alle mögliche Codestellen mit Aufrufen von seq_remove_slashes zu, anstatt die Daten einmalig und gebündelt in Rohform zu bringen.
Und für diese einmalige Säuberung ist die übliche get_magic_quotes_gpc()-Test-gebundene stripslashes Schleife völlig adäquat.
„Daten sollte bis zu genau dem Zeitpunkt in dem sie „geschützt“ benötigt werden in Rohform vorliegen“
Entspricht grundsätzlich auch meiner Überzeugung. Jedoch sehe ich den Sinn der Funktion „seq_remove_slashes“ in einen größeren Zusammenhang. Dabei ermöglicht sie die gleichwertig korrekte Behandlung von Zeichenketten ganz egal aus welcher Quelle sie stammen und ob „magic quotes“ an oder aus ist. Sie ist Teil von SSEQ-LIB, die als Sicherheitsbibliothek konzipiert ist und vor allem sicherstellen soll, dass in ansonsten ungeschützte Webanwendungen viele Schwachstellen geschlossen werden. Dazu wird diese „intelligente“ Entscheidung für oder gegen eine Behandlung mit „stripslashes“ bevorzugt denn sie verlangt viel weniger Wissen über die Anwendung und die anderen Komponente des Systems (Server, PHP, DB, etwaige Web Application Firewalls).