Variablen-Filterung ausreichend?

dertechniker · 28.08.2009, 10:30

Hallo PHP.de-Mitglieder,

bisher habe ich schon häufig über Google hilfreiche Themen hier im Forum gefunden und wende mich daher heute mit folgender Frage an euch.

Nach einiger Recherche hatte ich mich für folgende Variante entschieden, die übergebenen Variablen in PHP zu filtern: filter_input();

Je nach Variable wähle ich den Wertebereich natürlich so klein wie möglich, z.B. bei einer ID:

Zitat:

$somekindofid = filter_input(INPUT_POST, 'somekindofid', FILTER_SANITIZE_NUMBER_INT);

Dabei kann natürlich noch nichts schiefgehen - allerdings gibt es natürlich auch eine Menge Felder, deren Wertebereich wesentlich umfangreicher sein muss, wie z.B. Kommentar-Felder u.ä. Hierfür verwende ich eine customized Variante von filter_input:

Zitat:

$action = filter_input(INPUT_POST, 'action', FILTER_CALLBACK, array (
'options' => 'filterext_irregularcharacters'
));

function filterext_irregularcharacters($value) {
$value = preg_replace("=\.\.\/|^\/=", '', $value);
$value = preg_replace("=[/\?><\|\,\;\\\]=", '', $value);
$value = preg_replace("=['\"]=", '', $value);

return $value;
}

Nach meiner Einschätzung müsste das alles sein, was man grundsätzlich herausfiltern muss. Aber mehr Augen sehen natürlich auch mehr - daher würde ich mich sehr freuen, wenn ihr einfach mal drübergucken könntet, ob ich alles erwischt habe, was potentiell Schädliches enthält.

Vielen Dank,
dertechniker

ak5 · 28.08.2009, 13:05

Zitat:

Zitat von dertechniker

… ob ich alles erwischt habe, was potentiell Schädliches enthält.

Vielen Dank,
dertechniker

Das kommt ja ganz auf den Verwendungszweck an. Was machst Du mit den Daten aus dem Feld?

dertechniker · 28.08.2009, 14:51

Hi ak5,

die Daten werden später in eine MySQL-Datenbank geschrieben.

Viele Grüße,
dertechniker

ak5 · 28.08.2009, 15:13

Dann solltest Du dort nicht versuchen irgendwelche Pfadangaben oder sowas herauszufiltern, sondern die Zeichen für die Datenbank maskieren.

Siehe dazu PHP: mysql_real_escape_string - Manual

dertechniker · 28.08.2009, 15:22

Habe ich mit der obigen Funktion nicht schon alles erschlagen, was auch mysql_real_escape_string() täte? Wenn ich mit filter_input sowieso nur integer zulasse, gibts ja kein XSS-Problem. Es geht mir daher darum, dass ich in den Fällen, wo halt diverse User-Inputs möglich sind, alle abgefragten Variablen mit dieser Funktion frei von Schadcode filtere, sodass ich in den konkreten SQL-Statements auf mysql_real_escape_string() verzichten kann.

ak5 · 28.08.2009, 15:32

Zitat:

Zitat von dertechniker

Es geht mir daher darum, dass ich in den Fällen, wo halt diverse User-Inputs möglich sind, alle abgefragten Variablen mit dieser Funktion frei von Schadcode filtere, sodass ich in den konkreten SQL-Statements auf mysql_real_escape_string() verzichten kann.

Das ist aber nicht sehr effektiv. Um nicht zu sagen sehr ineffektiv. Zudem leuchtet mir nicht ein, wieso ein "Kommentar" frei von normalen Satzzeichen sein soll.

Einen Integer braucht man natürlich nicht durch real_escape_string zu schicken.

Chriz · 28.08.2009, 15:51

Hallo,
ich verstehe nicht so ganz warum du mysql_real_escape_string() hier nachbauen möchtest. Alles was in die Datenbank kommt (auch Zahlen) einfach mit mysql_real_escape_string() absichern und die Sache ist für die Datenbank-Sicherheit erledigt. Zahlen deshalb, weil du sicher mal irgendwann vergißt, wirklich zuzusichern, dass der Wert ein Zahl ist, durch Parameter-Verschiebung oder ähnliches doch so eine Lücke aufmachst. Du bist so einfach auf der sicheren Seite.
Wenn du jetzt noch vor der HTML-Ausgabe von Datenbankinhalten htmlentities() verwendest, kann dir auch keiner durch XSS bösen Code unterjubeln.

Dazu habe ich hier bereits etwas geschrieben:
http://www.php.de/php-einsteiger/577...tml#post446351

rudygotya · 28.08.2009, 16:08

Zitat:

Zahlen deshalb, weil du sicher mal irgendwann vergißt, wirklich zuzusichern, dass der Wert ein Zahl ist, durch Parameter-Verschiebung oder ähnliches doch so eine Lücke aufmachst.

Seh ich bissi anders

Ich verzichte bei ints auf die singlequotes, um unabhänging vom dbms zu bleiben. Wenn du natürlich "nur" MySQL verwendest, sparst dir dadurch schon einiges an Aufwand.

Chriz · 28.08.2009, 17:50

Ich benutz Zend_Db, da brauch ich eh nur $this->_db->quote($value) machen, den Adapter kann ich einfach zentral wechseln. Dass deine Zahlen nicht gequotet sind, erspart dir ohne Adapter nicht die Arbeit, die String-Quotes zu ersetzen.

Ich glaub nur, dass es zumindest minimal anfälliger ist, das Casten auf INT mal zu vergessen, als wenn du komplett immer quotest. Ich meine wenn ich dir sag, du sollst 1000x "fischer" sagen, machst du vermutlich weniger Fehler als wenn ich dir sage sag 500x "firschers fritz". Blödes Beispiel und jetzt auf dem Niveau ist es vielleicht auch Quark, aber ich meine trotzdem, dass man besser fährt, wenn man konsequent alles quotet.

robo47 · 28.08.2009, 19:08

imho wenn man nicht mit dem uralten mysql_*-funktionen arbeitet,
also egal ob mysqli, pdo, zend_db [pdo / mysql], doctrine [pdo], propel [pdo] ...

Alles bietet eigentlich mittlerweile prepared statements an, da muss man sich um die hochkommas und das escapen gar keine gedanken mehr machen, ob das ein string oder ein int ist, darum kümmert sich das system von selbst, auch im hinblick auf eventuelle Änderungen eines datentypes einer spalte (auch wenn es selten ist) und solange es querys sind die man prepared machen kann ... warum nicht ?

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Variablen werden nicht übermittelt	kietzmann	PHP Tipps 2009	2	06.06.2009 00:34
Klasse statt globaler Variablen	ecomeback	PHP-Fortgeschrittene	6	15.07.2008 16:30
Templatesystem mit Funktionen und Variablen drin?	BartTheDevil89	PHP Tipps 2008	6	01.07.2008 09:32
Übergeben von Variablen an in PHP eingebundenes Perl-Script	shredder01	PHP Tipps 2008	3	04.04.2008 09:25
Datei mit Variablen so includen, dass Variablen nutzbar?	BartTheDevil89	PHP Tipps 2008	6	22.01.2008 20:57
unerklärliches Leeren von Variablen	KuShi	PHP Tipps 2007	2	08.07.2007 15:19
Teil einer Variablen mit einer Variablen ersetzen ?	simsalabim	PHP Tipps 2007	11	20.03.2007 20:36
variablen aus textfile erzeugen (shellscript)	noskule	Server, Hosting und Workstations	2	19.07.2006 15:42
Variable aus Variablen zusammensetzen	juhuwoorps	PHP Tipps 2007	1	28.11.2005 21:50
$_GET Variablen weitergeben		PHP Tipps 2005	3	01.03.2005 15:36
Variablen übergeben bzw. auslesen?		PHP Tipps 2005	4	30.01.2005 03:56
[Erledigt] register globals off bei variablen Variablen...		PHP Tipps 2005	4	25.01.2005 17:50
komplexe Variablen übergeben?		PHP Tipps 2004-2	8	02.12.2004 08:29
Variablen aus den Formular sind nicht mehr verfügbar		PHP Tipps 2004	6	30.10.2004 13:31
Variablen per adresse übergeben	rocco	PHP Tipps 2004	7	24.07.2004 12:03


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

28.08.2009, 14:51
dertechniker Neuer Benutzer Registriert seit: 28.08.2009 Beiträge: 15 PHP-Kenntnisse: Fortgeschritten	Hi ak5, die Daten werden später in eine MySQL-Datenbank geschrieben. Viele Grüße, dertechniker

28.08.2009, 15:13
ak5 Benutzer Registriert seit: 26.08.2009 Beiträge: 41 PHP-Kenntnisse: Fortgeschritten	Dann solltest Du dort nicht versuchen irgendwelche Pfadangaben oder sowas herauszufiltern, sondern die Zeichen für die Datenbank maskieren. Siehe dazu PHP: mysql_real_escape_string - Manual

28.08.2009, 15:22
dertechniker Neuer Benutzer Registriert seit: 28.08.2009 Beiträge: 15 PHP-Kenntnisse: Fortgeschritten	Habe ich mit der obigen Funktion nicht schon alles erschlagen, was auch mysql_real_escape_string() täte? Wenn ich mit filter_input sowieso nur integer zulasse, gibts ja kein XSS-Problem. Es geht mir daher darum, dass ich in den Fällen, wo halt diverse User-Inputs möglich sind, alle abgefragten Variablen mit dieser Funktion frei von Schadcode filtere, sodass ich in den konkreten SQL-Statements auf mysql_real_escape_string() verzichten kann. Geändert von dertechniker (28.08.2009 um 15:28 Uhr).

28.08.2009, 15:51
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.268	Hallo, ich verstehe nicht so ganz warum du mysql_real_escape_string() hier nachbauen möchtest. Alles was in die Datenbank kommt (auch Zahlen) einfach mit mysql_real_escape_string() absichern und die Sache ist für die Datenbank-Sicherheit erledigt. Zahlen deshalb, weil du sicher mal irgendwann vergißt, wirklich zuzusichern, dass der Wert ein Zahl ist, durch Parameter-Verschiebung oder ähnliches doch so eine Lücke aufmachst. Du bist so einfach auf der sicheren Seite. Wenn du jetzt noch vor der HTML-Ausgabe von Datenbankinhalten htmlentities() verwendest, kann dir auch keiner durch XSS bösen Code unterjubeln. Dazu habe ich hier bereits etwas geschrieben: http://www.php.de/php-einsteiger/577...tml#post446351 __________________ "Nuschel ich?" - "Was?" Geändert von Chriz (28.08.2009 um 15:56 Uhr).

28.08.2009, 17:50
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.268	Ich benutz Zend_Db, da brauch ich eh nur $this->_db->quote($value) machen, den Adapter kann ich einfach zentral wechseln. Dass deine Zahlen nicht gequotet sind, erspart dir ohne Adapter nicht die Arbeit, die String-Quotes zu ersetzen. Ich glaub nur, dass es zumindest minimal anfälliger ist, das Casten auf INT mal zu vergessen, als wenn du komplett immer quotest. Ich meine wenn ich dir sag, du sollst 1000x "fischer" sagen, machst du vermutlich weniger Fehler als wenn ich dir sage sag 500x "firschers fritz". Blödes Beispiel und jetzt auf dem Niveau ist es vielleicht auch Quark, aber ich meine trotzdem, dass man besser fährt, wenn man konsequent alles quotet. __________________ "Nuschel ich?" - "Was?"

28.08.2009, 19:08
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	imho wenn man nicht mit dem uralten mysql_*-funktionen arbeitet, also egal ob mysqli, pdo, zend_db [pdo / mysql], doctrine [pdo], propel [pdo] ... Alles bietet eigentlich mittlerweile prepared statements an, da muss man sich um die hochkommas und das escapen gar keine gedanken mehr machen, ob das ein string oder ein int ist, darum kümmert sich das system von selbst, auch im hinblick auf eventuelle Änderungen eines datentypes einer spalte (auch wenn es selten ist) und solange es querys sind die man prepared machen kann ... warum nicht ? __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework