Trim() für alle Post Variablen funktioniert nicht

Computer: Software & Programmierung PHP
#1

Hallo,

ich habe vor einiger Zeit einen Thread - trim() für alle Post Variablen - eröffnet. Darin habe ich um eine Funktion gebeten, welche alle mögliche Leerzeichen eines Formulars (Text, Select, Checkboxen) entfernt. Leider kann ich in diesem Thread nicht mehr Posten. Ein hilfsbereiter User hat damals folgende Lösung vorgeschlagen.

function array\_trim($array) {
 if(is\_array($array)) {
 foreach($array as &$value) {
 $value = array\_trim($value);
 }
 } else {
 $array = trim($array);
 }
return $array;
}

Leider funktioniert diese Lösung allerdings nicht. Ich rufe die Funktion mit array_trim($_POST); auf. Ist das „&“ korrekt oder ein Tippfehler? Leider passiert bei beiden Versionen nichts :frowning: Wo liegt denn der Fehler?

#2

Moin!

Ist das „&“ korrekt oder ein Tippfehler?

Das ist essenziell!

Wenn Du das Array nicht referenzierst (mit dem &amp:wink:, arbeitet foreach mit einer Kopie vom Array. Das heißt, wenn Du Änderungen machst, werden die nicht ins Originale Array übernommen, es bleibt unverändert.

Das Referenzieren funktioniert aber erst ab PHP5. Wenn bei Dir nichts passiert, hast Du vielleicht eine falsche PHP-Version.

Steht alles hier: http://de3.php.net/manual/de/control-structures.fore…

Liebe Grüße,
-Efchen

#3

Nachtrag:

Wenn Du kein PHP5 zur Verfügung hast, dann nimm statt einer foreach-Schleife eine for-Schleife, die arbeitet nicht mit einer Kopie des Arrays.

#4

Hallo,

danke für deine Antwort. Ich denke, ich habe den Fehler gefunden. Zuerst vergebe ich kurze Variablennamen (etwa $test = $_POST[‚test‘]), dann führe ich die Trim Schleife für alle POST Variablen/Arrays durch und zuletzt schreibe ich die ungetrimmten Kurzvariablen in die Datenbank. Das nennt man wohl einen Logikfehler.

Allerdings habe ich eine neue Frage. In meinem Buch steht, man soll Formulareingaben - sofern get_magic_quotes_gpc() nicht aktiviert ist - mit addslashes() überprüfen, um Steuerungszeichen zu kennzeichnen. Theoretisch könnte man analog zur obigen Trim-Schleife eine Addslashes-Schleife schreiben. Allerdings steht in meinem Buch auch, dass man doubleval() anstelle von addslashes() verwenden sollte, wenn man Formulareingaben als „float“ speichert. Gibt es eine Möglichkeit potentielle Steuerungzeichen in POST Varialben/Arrays mittels Schleife zu kennzeichnen?

#5

schreiben. Allerdings steht in meinem Buch auch, dass man
doubleval() anstelle von addslashes() verwenden sollte, wenn
man Formulareingaben als „float“ speichert. Gibt es eine
Möglichkeit potentielle Steuerungzeichen in POST
Varialben/Arrays mittels Schleife zu kennzeichnen?

was hat doubleval mit addslashes() zu tun,
doubleval macht aus einem string eine dezimal zahl
addslashes maskiert zeichen in einem string die später unerwünscht interpretiert werden könnten , schreibe ich in einem artikel \n dann soll es kein Zeilenumbruch sein , sobald ich das aber in eine variable einlese und ausgebe wird das ein Zeilenumbruch , stelle ich aber ein \ davor also \n , so wird das steuerzeichen \ nicht interprediert , und somit \n nicht als zeilenumbruch gelsen sondern nur \ und dann das n angezeigt , eben so wie eingegeben.

#6

In meinem Buch steht, man soll Formulareingaben
mit addslashes() überprüfen, um Steuerungszeichen zu kennzeichnen.

Oder um SQL-Injections zu verhindern, indem auch Hochkommas (’) mit einem Backslash zu versehen. Sonst könnte man damit nämlich das SQL-Statement verändern.

Allerdings steht in meinem Buch auch, dass man
doubleval() anstelle von addslashes() verwenden sollte

doubleval() wird vermutlich Zeichen, die in einer float/double-Variable nicht vorkommen können entweder filtern/ignorieren oder einen Fehler auswerfen. Daher die Verbindung zu addslashes().

Gibt es eine
Möglichkeit potentielle Steuerungzeichen in POST
Varialben/Arrays mittels Schleife zu kennzeichnen?

Was meinst Du, wenn nicht addslahes()?

#7

doubleval() wird vermutlich Zeichen, die in einer
float/double-Variable nicht vorkommen können entweder
filtern/ignorieren oder einen Fehler auswerfen. Daher die
Verbindung zu addslashes().

das macht fast mehr sin , hat aber nix mit addslashes zu tun richtig ? eher was mit dem einzelfall „eingabe von Zahlen“

#8

Ich will alle meine Formularfelder (Text/Select/Checkboxen) wenn möglich mittels einer Schleife gegen „böse Eingaben“ schützen, ganz egal in welchen Spaltentyp (char, integer, float etc.) die Eingaben geschrieben werden. In meinem Buch wird addslashes() und eben doubleval() verwendet:

„Da der Preis in der Datenbank als Fließkommazahl gespeichert wird, sollten Sie keine Schrägstriche darin zulassen. Den gleichen Effekt des Ausfilterns ungeeigneter Zeichen in diesem Zahlenfeld erzielen Sie durch den Aufruf der Funktion doubleval(), …“

Quelle: PHP 5 & MySQL 5 - Dynamische Webanwendungen von Einstieg bis E-Commerce

#9

das macht fast mehr sin , hat aber nix mit addslashes zu tun
richtig ?

Eigentlich nicht, nein.

Aber addslashes macht ungültige Zeichen unschädlich und doubleval macht auch ungültige Zeichen unschädlich. Da sehe ich den einzigen Zusammenhang. Also nicht direkt verwandt die zwei, vielleicht verschwägert :wink:

#10

„Da der Preis in der Datenbank als Fließkommazahl gespeichert
wird, sollten Sie keine Schrägstriche darin zulassen. Den
gleichen Effekt des Ausfilterns ungeeigneter Zeichen in diesem
Zahlenfeld erzielen Sie durch den Aufruf der Funktion
doubleval(), …“

Das ist schon richtig so. Unglücklich formuliert wfinde ich nur „den gleichen Effekt“ - denn die beiden Funktionen machen natürlich was völlig unterschiedliches, was nur insofern den gleichen Effekt hat, als dass die Variable für den Eintrag in die Datenbank aufbereitet wird.

Schönes Wochenende,
-Efchen

#11

Das heißt wohl, ich muss jede Variable einzeln prüfen und eine Prüfung mittels Schleife ist nicht möglich:

$name = addslashes($name);
$wohnort = addlashes($wohnort);
$dioptrien = doubleval($dioptrien);
usw…

#12

das problem ist, das alle input felder text felder sind .
wie also soll man generell prüfen ob eine zahl oder ein text drin steckt.
Sollte ich wissen welchen kontext der inhalt ist, dann ok , aber am input feld selber kann man es nicht erkennen , ausser du machst den namen auffällig , also name_str wohnort_str dioptrien_double .

#13

Hallo sax408,

hier ein paar allgemeine Anmerkungen zum Topic:

  • Originalvariablen ($_POST, $_GET, …) sollte man idealer Weise niemals direkt aendern. Lieber eine Kopie erstellen und diese Aendern. (man weiss nie in welchem Sonderfall spaeter man doch auf das Original zugreifen muss)

  • Magic Quotes sind als Veraltet gekennzeichnet und werden (hoffentlich) alsbald aus PHP verschwinden. Auch ist diese Methode NICHT geeignet sich vor Injections zu schuetzen! Der Schutz vor Angriffen sollte im jeweiligen Anwendungsfall geschehen, also z.B. durch die Verwendung von htmlspecialchars() bei der HTML Ausgabe oder mysql_real_escape_string() bei Verwendung der mysql(i) Funktionen (oder noch besser: von mysql(i) auf PDO umstellen)

  • die Ueberpruefung von Eingabewerten hat im Endeffekt auch nichts mit der Anzeige zu tun. Dafuer gibt es z.B. ab PHP 5.2 die sehr einfach zu bedienenden Filter-Funktionen (Beispiele) oder man verwendet z.B. regulaere Ausdruecke zur Ueberpruefung von Eingabewerten.

Gruss
Stefan

#14

Das Referenzieren funktioniert aber erst ab PHP5. Wenn bei Dir
nichts passiert, hast Du vielleicht eine falsche PHP-Version.

nein, geht in 4.x auch:

$ echo '<?php echo phpversion()."\n"; $a=1; $b=&$a; $b=2; echo $a."\n";'\<br /> |/usr/local/php-4.2.1/bin/php -q
4.2.1
2

in 3.x gibt es aber tatsaechlich an der stelle einen parse error - den haette er also gesehen:

$ echo '<?php echo phpversion()."\n"; $a=1; $b=&$a; $b=2; echo $a."\n";'\<br /> |/usr/local/php-3.0.18/bin/php -q
3.0.18

**Parse error** : parse error in **-** on line **1**
#15

Danke für die Info. Ich werde mir mysql_real_escape_string() noch genauer ansehen.

Mit der Trim Funktion gehe ich jetzt wie folgt vor:

$\_POST = array\_trim($\_POST); // Die zuvor gepostete Funktion wird aufgerufen

$var1 = $\_POST['var3'];
$var2 = $\_POST['var2'];
$var3 = $\_POST['var3'];

if (!$var1 || !$var2 || !$var3) {
 echo 'Bitte füllen Sie alle Formularfelder aus!';
}

Ich denke, diese Änderung der Post Variablen ist kein Problem. Jedenfalls fällt mir momentan keine Situation ein, in welcher ich die Originalvariablen mit möglichen Whitespace zu Beginn oder am Ende benötige.

Sollte ich versehentlich in ein Feld nur ein Leerzeichen und keinen weiteren Inhalt schreiben, wird das Feld nun als leer erkannt, was ich auch sehr nützlich finde.

#16

Hi,

Allerdings habe ich eine neue Frage. In meinem Buch steht, man
soll Formulareingaben - sofern get_magic_quotes_gpc() nicht
aktiviert ist - mit addslashes() überprüfen, um
Steuerungszeichen zu kennzeichnen.

Dein Buch scheint nicht besonders gut zu sein oder Du interpretierst da was falsch. Bitte lies die Antwort von Stefan weiter oben - ein Rundumschlag mit addslashes() ist weder allgemein, noch speziell für MySQL ratsam.

Gruß
Ingo

#17

Hallo

addslashes() schützt nur dann gegen MySQL-Injections, wenn die behandelte Variable im SQL-Statement in Anführungszeichen eingeschlossen wird. Da MySQL es zulässt, auch Zahlen in Anführungszeichen zu übergeben, genügt auch hier addslashes(). Lässt man die Anführungszeichen weg, muss man zu Funktionen wie intval() oder doubleval() greifen.

Ich würde außerdem empfehlen, Zahlen-Formulareingaben vorher mit is_numeric(), ctype_digit() oder preg_match() daraufhin zu überprüfen, ob sie sinnvolle Werte (also echte Zahlen) enthalten. Wenn nicht, dann Formular einfach noch mal mit Fehlermeldung anzeigen. Eine anschließende Maskierung kann trotzdem nicht schaden.

Sinnvoller ist es eigentlich, die Variablen erst vor der MySQL-Abfrage zu escapen oder gleich Prepared Statements zu verwenden, bei denen das automatisch passiert. Denn falls man die Variablen doch noch mal auf dem Bildschirm ausgeben möchte, dann sind die \ im Weg.

In dem Zusammenhang hab ich aber selber mal ne Frage: addslashes() maskiert ", ', \ und das Nullzeichen. Das genügt doch schon, damit MySQL die (in Anführungszeichen eingeschlossene) Variable wie vorgesehen als einen String auswertet. Wozu gibt es dann mysql_escape_string() und mysql_real_escape_string()?

Gruß, sigterm

#18

Hallo

PHP 4 unterstützt & aber nicht im Zusammenhang mit foreach.

sigterm

#19

Hallo

PHP 4 unterstützt & aber nicht im Zusammenhang mit foreach.

aber mit vorsicht , bei einigen konstrukten ist die referenz nicht richtig das hab ich leider erst durch ausprobieren herrausbekommen , ich hab php4 versucht wie c++ zu nutzen (war mein fehler), aber seit php 5 funktionieren referenzen so wie gedacht. Ich find den Bug-Tracker jetzt nicht wieder , aber es gab dazu einen.

sigterm