In der PHP-Welt scheint der Mythos vorzuherrschen, dass die Nutzung von htmlspecialchars s\u00e4mtlichen Input in s\u00e4mtlichen Situation sicher macht. Quasi die „one fits all“ – Funktion. Beginnen wir gleich mal mit einem Beispiel. Kein Witz, so gesehen:<\/p>\n
\r\nfunction get_user_id($db)\r\n{\r\n\t$username = htmlspecialchars(trim($_POST['username']));\r\n\t$res = $db->query("SELECT `id` FROM `accounts` WHERE `login` = '$username' LIMIT 1");\r\n\treturn $res[0]['id'];\r\n}\r\n<\/pre>\nCool! Schauen wir uns doch mal die Signatur von htmlspecialchars<\/a> an:<\/p>\n\r\nstring htmlspecialchars ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = 'UTF-8' [, bool $double_encode = true ]]] )\r\n<\/pre>\nDas verflixte Hochkomma<\/h2>\n
Besonderes Augenmerk sei auf die Flags gelegt. ENT_COMPAT <\/b> hei\u00dft „Konvertiert nur doppelte Anf\u00fchrungszeichen und l\u00e4sst einfache Anf\u00fchrungszeichen unver\u00e4ndert.<\/i>„. Also: Perfektes Einfallstor f\u00fcr SQL-Injection.<\/p>\n
Gleiches ergibt sich im Formularhandling:<\/p>\n
\r\n<?php\r\n$_GET['firstname'] = "'onmouseover='alert(\/xss!\/)'";\r\n$firstname = htmlspecialchars($_GET['firstname'], ENT_COMPAT);\r\n?>\r\n<input name='firstname' value='<?php echo $firstname ?>'>\r\n<\/pre>\nAnalog zu diesem PHP WTF<\/a>-Artikel erfreut auch hier die !sinnvolle Wahl der Defaultparameter. Der Flags-Parameter sollte also in jedem Fall ENT_QUOTES<\/b> enthalten, so werden n\u00e4mlich auch Single-Quotes durch das entsprechende Pendant '<\/i> ersetzt. <\/p>\nEncoding<\/h2>\n
Seit PHP 5.4 ist der dritte Parameter string $encoding<\/i> sinnvollerweise auf UTF-8 gesetzt. Vorher kam htmlspecialchars mit ISO-8859-1<\/i> als Standard daher. Bei der Frage des Encodings gilt: Immer dasselbe Encoding verwenden, das auch die Applikation selbst verwendet<\/b>. Und das sollte ja in der Regel UTF-8 sein. Deswegen in Libraries am Besten eine eigene Wrapperfunktion bauen, die genau so aussieht:<\/p>\n\r\nfunction real_htmlspecialchars($string)\r\n{\r\n\treturn htmlspecialchars($string, ENT_QUOTES, "UTF-8");\r\n}\r\n<\/pre>\nUnd trotz dessen: F\u00fcr Datenbankparameter ist htmlspecialchars tabu! PDO bietet die quote<\/a>-Funktion und wer wirklich noch mit nacktem MySQL rumjuckeln muss freut sich \u00fcber mysql_real_escape_string<\/a> oder alterantiv die Escape-Funktion des verwendeten Frameworks.<\/p>\nInteressant auch, wie es „die Gro\u00dfen“ betreiben: Die u.a. von Symfony verwendete Template-Engine Twig (siehe twig_escape_filter<\/i>)<\/a> und der Zend-Escaper<\/a> kann man sich mal zu Gem\u00fcte f\u00fchren. Sehr lesenswert ist auch das eingereichte Proposal<\/a> f\u00fcr einen vern\u00fcnftigen, kontextabh\u00e4ngigen PHP-builtin-Escaper.<\/p>\n","protected":false},"excerpt":{"rendered":"In der PHP-Welt scheint der Mythos vorzuherrschen, dass die Nutzung von htmlspecialchars s\u00e4mtlichen Input in s\u00e4mtlichen Situation sicher macht. Quasi die „one fits all“ – Funktion. Beginnen wir gleich mal mit einem Beispiel. Kein Witz, so gesehen: function get_user_id($db) { … Weiterlesen