Tag Archives: PHP

PHP, MariaDB, Load Data Infile – manchmal ist der Umweg über Dateien performanter ….

Posted on by

Im Moment bin ich wider mit LAMP-Entwicklung beschäftigt. Mit Simulationen zu technischen Netzwerken in mehreren Dimensionen mit vielen Knoten, die kreuz und quer verbunden sein können. In solchen Netzen gibt es u.U. eine mit der Knotenmenge exponentiell wachsende Anzahl von Pfaden. Die Simulation des Informationstransports durch solche Netze ist ähnlich zum Transport von Signalen in “künstlichen neuronalen Netzwerken” – in unserem Fall ist aber die Komplexität aufgrund der Netzstruktur und der Qualität der transportierten Information erheblich größer.

Das Ziel meiner Auftraggeber sind datenbankgestützte Simulationen solcher technischen Netze mit PHP. Bei einer hinreichenden Anzahl von Knoten, Ebenen und Verbindungen erhält man dabei u.U. erhebliche Datenmengen, die man während der laufenden Rechnung systematisch auslagern muss. Das ist in Forschungslabors mit einer Armada von Prozessoren und SSDs nun heute selten ein grundsätzliches Problem. Im einem kleinen Büro oder auf billigen LAMP-Servern aber sehr wohl – insbesondere dann, wenn man nicht mit Multithreading in Web-Server-Umgebungen beginnen will oder aus Sicherheitsgründen gar nicht kann (pthread etc,. lassen das in Webumgebungen gar nicht zu). Oft hilft dann ein kleiner Umweg – und der führt u.U. über Ajax, Web-Clients und Dateien.

Ausgangslage

Aus bestimmten Gründen sollen die Berechnungen meiner Kunden auf LAMP-Servern angeboten werden. Hochgradige Programm-Effizienz ist also ein Muss. Günstige virtualisierte Mittelklasse-Server haben oft eine Ausstattung mit 4-6 Prozessoren, mehreren GB RAM und SSD-Speicherplatz. Zwei Prozessoren sollen ggf. einen Apache-Server mit PHP-Modul stützen, zwei andere eine Hauptdatenbank, die während der Simulation benutzt wird, und ein fünfter ggf. eine Bank für Ergebnisdaten.

Nun macht jeder mal die Erfahrung, dass Datenbank-INSERTs in der Regel grundsätzlich zu den langsamen Transaktionen zählen. Zudem behindern sie in einem PHP-Programm die Ausführung weiterer datengenerierender Funktionen, die möglicherweise gar nicht – oder zumindest nicht zeitnah – von den erzeugten Outputdaten abhängig sind. So kann es je nach Breite von Records schon mal im Bereich von Sekunden dauern, wenn man mehrere hunderttausend Datensätze “on the fly” in Datenbank-Tabellen schreiben will – und dabei auch noch mehrere Indices aufgebaut werden sollen. Wertvolle Zeit, in der andere Dinge – nämlich weitere numerische Berechnungen – passieren könnten. Wie kann man da CPU-Zeit sparen bzw. sinnvoll nutzen?

Ajax und der Web-Client zur Multitasking-Steuerung für Arme

Man vergisst oft, dass bei gut separierbaren Aufgaben auch der (Web-) Client ins Spiel gebracht werden kann. So kann ein Client über Ajax zwei (oder mehr) PHP-Threads auf einem Apache-Server starten – jeder in einer eigenen Umgebung (memory-, session- und prozess-bezogen). Per Ajax kann man den zweiten Prozess auch periodisch – und in Abhängigkeit von zwischenzeitlich dokumentierten Ergebnissen des kontinuierlich laufenden ersten Prozesses starten.

Der Hauptprozess – in unserem Fall unsere Simulation – kann dabei mit den weiteren periodisch gestarteten Prozessen signalartig über ein gemeinsames Medium kommunizieren – nämlich über spezielle Tabelleneinträge in der Datenbank. Die periodischen Jobs lesen diese Information aus und verhalten sich entsprechend. Ergebnisse werden per Ajax an den Client übermittelt, der dann weitere Nachfolgeaktionen einleitet.

Diese Art von getriggertem “Multitasking” über einen zentralen Web-Client und einen vermittelnde Ajax-Schicht hat einige Vorteile bei langwierigen Prozessen – wie etwa Simulationsläufen. Eine typische Anwendung ist etwa das Status-Polling zum Simulationsprozess. Ich hatte darüber bereits früher in diesem Blog berichtet.

Umgang mit großen zwischen-zeitlich aufkommenden Ergebnisdaten

Wie können wir das nun nutzen, um
zwischenzeitlich produzierte große Datenmengen halbwegs schnell in eine Datenbank aufzuräumen? Man vergisst im LAMP-Geschäft zu oft Dateien als Austauschmedium und als Puffer. MariaDB/MySQL-Systeme bieten zudem einen hochgradig effizienten Weg an, große Datenmengen in flache Tabellen einzulesen, nämlich “LOAD DATA INFILE”:

Vergleicht man die Zeit, die man in einem ausreichend mit RAM gepufferten System mit Write-Caching auf Linux-Ebene benötigt, um strukturierte Daten in ein File zuschreiben, so wird man feststellen, dass das u.U. erheblich (!) weniger Zeit kostet, als zwischenzeitlich eine Datenbanktabelle zu befüttern. Das gilt auch dann noch, wenn man die Zeit hinzurechnet, die ein LOAD DATA INFILE der MariaDB für das Füllen einer Tabelle aus den insgesamt generierten CSV-Filedaten (mit ggf. Millionen Datensätzen) benötigt. Das Schreiben in ein File, das anschließende Laden in eine Tabelle einer ansonsten wenig ausgelasteten Bank (ohne gleichzeitige Index-Generierung!) und die nachträgliche Erzeugung von Indices ist i.d.R. immer noch um Faktoren schneller als der direkte Transfer über (prepared) INSERTs – selbst wenn man hunderte Rows in ein INSERT-Statement packt. Zeit, die – wie gesagt – vom eigentlichen Simulationsprogramm genutzt werden kann!

Hinweis:
Ganz entscheidend für den effizienten Einsatz von “LOAD DATA INFILE” ist hierbei, alle Indices von der zu befüllenden Tabelle gelöscht zu haben, die Daten zu laden und erst danach die notwendigen Indices zu generieren. In all unseren Tests haben sich hierbei übrigens MyISAM-Tabellen performanter als InnoDB-Tabellen verhalten.

Schrittfolge

Wir werfen kurz einen Blick auf die Schrittfolge (habe leider gerade keine Zeit, schöne Grafiken zu zeichnen):

  • Schritt 1: Der Web-Client startet das Simulationsprogramm “S”, das durchgehend auf der Hauptdatenbank-Instanz arbeitet.
  • Schritt 2: Der Web-Client startet unmittelbar darauf auch noch zum ersten Mal und danach periodisch ein weiteres Programm “O”, das für die Behandlung von Output-Daten zuständig ist (sobald halt welche angefallen sind) und das dazu eine spezielle Tabelle der Hauptdatenbank auf Einträge zu fertiggestellten Output-Dateien abfragt. Der Client startet “periodisch” aber nur dann weitere Jobs vom Typ “O”, wenn er zuvor Statusmeldungen des aktuellen “O”-Prozesses erhalten hat, und sich der aktuelle “O”-Prozess beendet hat.
  • Schritt 3: Der zweite PHP-Prozess “O” widmet sich dann jeweils der zuletzt fertiggestellten Datei, prüft ggf. deren Struktur und übergibt dann die weitere Behandlung an einen LOAD DATA INFILE-Prozess der MariaDB – ggf. einer zweiten separaten Datenbank-Instanz, der eigene Prozessoren und memory-Anteile zugewiesen wurden.
  • Schritt 4: Nach einem erfolgreichen Laden der Daten durch den Prozess “O” beendet sich dieser, nachdem er dem Client noch eine Meldung per Ajax zugeschickt hat.
  • Schritt 5: Der Client startet ein weiteres Mal das für Outputs zuständige Programm vom Typ “O”.
    etc.

Das Ganze dauert so lange, bis vom Hauptprogramm ein “Signal” (per DB-Eintrag) gesetzt wurde, dass kein weiterer Output mehr zu erwarten ist.

Das Vorgehen entspricht einer Art selbstgesteuertem, dynamischen Batch-Processing von Daten auf einem LAMP-Server. Es erfordert ein wenig mehr Programmieraufwand (insbesondere zur Fehlerbehandlung) als ein Standard-Vorgehen im Rahmen eines einzigen Threads – es bringt u.U. aber Faktoren an Performance – solange die Simulation nicht auf Zwischenergebnisse in der Bank warten muss. Letzteres ist bei uns oft genug der Fall.

Wir haben so Programm-Läufe, die in Tests 25 Sekunden dauerten, auf unter 5 Sekunden gebracht. Es
war der Mühe wert – und wir können anderen, die langwierige PHP-Programme für Simulations-Berechnungen auf LAMP-Servern nur empfehlen, eine solche Vorgehensweise an kritischen Engpässen mal als Alternative zu untersuchen.

Zusammenfassung

Fallen bei langwierigen PHP/LAMP-Programmen zwischenzeitlich große Datenmengen an, können diese u.U. ohne Beeinträchtigung des Hauptprogramms parallel durch weitere PHP-Programme einer Behandlung durch eine Datenbank zugeführt werden. Teil der Steuerung kann dabei ein gemeinsamer Ajax-Client sein, der die Ergebnislieferung der verschiedenen PHP-Programme überwacht. Der Datenaustausch zwischen den parallel laufenden PHP-Prozessen erfolgt dabei über die Datenbank, Ajax-Meldungen und Datenfiles. Zur Behandlung großer Datenmengen kann dabei LOAD DATA INFILE seine Performance-Vorteile ausspielen. Insgesamt sind dadurch im Einzelfall erhebliche Programm-Beschleunigungen möglich.

Zeichensatzvorgaben für MySQL und PHP – SET NAMES – und leere Strings durch htmlentities()

Posted on by

Gestern ist mir ein dummer Fehler passiert, dessen Analyse mich Zeit gekostet hat. Dabei erwies sich die Sache am Ende als trivial. Es ging letztlich um konsistente Zeichensatzeinstellungen für PHP und MySQL – allerdings mit einem mir bislang unbekannten Nebeneffekt.

Zeichensätze im Kontext von PHP und MySQL sind ein Thema vieler Foren- und Q&A-Artikel im Internet – und nicht immer trifft man auf zufriedenstellende Antworten. Ich hoffe, dieser Artikel trägt anhand eines Beispiels zu etwas mehr Klarheit bei.

Voraussetzungen und aufgetretener Fehler

Unsere hausinternen Apache- und Datenbank-Server laufen normalerweise vollständig unter UTF-8. Inklusive der eigenen Datenbank- und Tabellen-Kollationen unter MySQL- oder MariaDB-Systemen. Aber für Tests müssen wir immer mal wieder gezielt eine Kompatibilität zu den festgelegten Kollationen für MySQL-Banken/Tabellen auf Kundenservern herstellen. Meist kommt dann Latin1 (iso-8859-1) ins Spiel.

Gestern mussten wir für einen solchen Test Datensätze eines von uns entwickelten, php-basierten CMS von einem gehosteten MySQL-Kundenserver in unsere lokale Test-Datenbank übernehmen. Diese Datensätze beinhalteten viele Text-Strings mit deutschen Umlauten. Da es sich nur um wenige Records handelte, haben wir die Daten in diesem Fall mit Copy/Paste und mit Hilfe von Eingabefeldern unserer CMS-Verwaltungsoberfläche übernommen. Das CMS lief dabei unter einer lokalen UTF8-Standarddomäne. Unsere aktuellen CMS-Programme zeigten die fraglichen Textstrings denn auch korrekt in der Web-Oberfläche des CMS an.

Es gab aber andere zu untersuchende Punkte im Layout. Um die Unstimmigkeiten zu testen, haben wir zusätzlich eine separate Testdomäne angelegt und diverse PHP-Klassen vom Kundenserver (auf dem dortigen Versionsstand) in bestimmte Verzeichnisse des zugehörigen Web-Spaces auf unserem lokalen Server geladen. Ergebnis: 2 Domainen mit z.T. unterschiedlichen Versionsständen von PHP-Klassen.

Und dann passierte es:

Bei einem Aufruf der Webseiten in der Testdomäne verschwanden plötzlich fast alle Text-Strings aus der Web-Oberfläche.

Bilder und grundsätzlicher Aufbau der Webseiten bleiben jedoch erhalten. Ich war zunächst völlig verblüfft über diesen Effekt. Zumal der Einsatz unserer lokalen Versionen der gleichen PHP-Klassen kein Verschwinden der Textstrings zeitigte.

Die Analyse war nicht ohne, da ich zunächst nicht wusste, wonach ich zu suchen hatte. Man denkt da zunächst natürlich an Unterschiede im Programmcode selbst. Am Schluss entpuppten sich aber eine im wesentlichen unmodifizierte Klasse, die die Datenbankverbindung steuert, sowie eine Klasse, die die Strings aus Sicherheitsgründen nach unerlaubten Sequenzen filtert, als Kerne des Übels. Ausschlaggebend waren allerdings nicht Programmunterschiede sondern bestimmte Parameter-Setzungen sowie Server- und Zeichensatzeinstellungen. Aber der Reihe nach.

Zeichensatzeinstellungen in der Kommunikationskette zwischen einem PHP-Server und einer MySQL-Datenbank

In der Datenaustausch-Kette zwischen einer MySQL-Datenbank und PHP-Modulen auf einem Web-Server (und natürlich auch bei der Übersendung eines HTML-/XML- oder JSON-Outputs an Web-Clients) spielen verschiedene Zeichensatzeinstellungen eine Rolle. Einige davon können vom Entwickler beeinflusst werden. Andere wiederum nicht immer.

Für unseren Fall waren vor allem die nachfolgenden Punkte relevant; sie betreffen den Web-Server (mit PHP-Modul) und die MySQL-Datenbank:

  1. Zeichensätze (“Kollationen”) der MySQL-Datenbank und zugehöriger Datenbanktabellen.
  2. Zeichensatz-Vorgaben zur MySQL-Verbindung und zum Datentransfer von und zu (PHP-)Programmen, die mittels der SQL-Direktive “SET NAMES” vorgenommen wurden.
  3. Einstellungen für den Default-Character-Set des PHP-Apache-Moduls.
  4. Zeichensatzeinstellungen für die PHP-Funktion “htmlentities()”.

Zeichensätze in der Datenbank und die Direktive “SET NAMES”

Für die Kollation der relevanten MySQL-Datenbank und ihrer Tabellen war auf dem Kundenserver “latin1_german2_ci” gewählt worden. Unsere Einstellungen im lokalen Testsystem waren dazu auf Tabellenebene kompatibel. Die Kollation einer Datenbanktabelle bestimmt letztlich aber nur die interne Ablage der Daten in der Tabelle und nicht den Zeichensatz, unter dem z.B. per SQL ermittelte Resultsets an weiterverarbeitende Programme übermittelt werden.

Für letzteres sind andere Parameter verantwortlich, die man als Entwickler für eine spezifische Verbindung zur MySQL-Datenbank einstellen kann. Unter MySQL und der MariaDB nutzt man dafür etwa die SQL-Direktive “SET NAMES” (oder aber die Funktion mysqli_set_charset(); s.u.).

“SET NAMES” führt zur gleichzeitigen Festlegung dreier RDBMS-Parameter für die Behandlung einer spezifischen Datenbankverbindung. Diese Parameter sind: character_set_client, character_set_connection, character_set_results.

Siehe hierzu etwa
https://dev.mysql.com/doc/refman/5.7/en/set-names.html
und
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_character_set_results.

Die Datenbankverbindung wird unter dem PHP/mysqli-Interface dabei über das Connection-Objekt

$dbi = mysqli_connect(….)

identifiziert. Im Wesentlichen legen die genannten Parameter Folgendes fest:

  • character_set_client: Zeichensatz, unter dem Daten, die vom Datenbank-Client zum RDBMS-Server transferiert werden, interpretiert werden.
  • character_set_connection: Handhabung bestimmterErsetzungen und Konversionen, u.a. von Numbers zu Strings.
  • character_set_results: Zeichensatz, unter dem Daten, die vom RDBMS zu Client-Programmen übermittelt werden interpretiert werden.

Der “Client” ist in unserem Fall natürlich ein PHP-Programm auf einem Apache-Server. Die Anwendung des “SET NAMES”-Statements durch ein PHP-Programm, z.B.

$sql_unames = “SET NAMES ‘utf8′”;
$this->dbi->query($sql_unames);
//dbi->Datenbank-Connection Object
//$this->dbi = mysqli_connect(….)

ist somit von zentraler Bedeutung für die Kommunikation zwischen einem PHP-Programm und einer MySQL/MariaDB! Solange eine hinreichende Konvertierung verwendeter Zeichen gewährleistet ist, muss der Zeichensatz, unter dem Resultsets zum PHP-Programm übermittelt werden, nicht zwingend mit dem der Datenbanktabellen selbst identisch sein.

Es sei darauf hingewiesen, dass es zu “SET NAMES” auch Alternativen gibt, die man im Rahmen des mysqli-Interfaces einsetzen kann und sollte (s.u.). Dass wir in einigen Programmen noch SET NAMES verwenden, hat lediglich historische Gründe. Die hier beschriebene Problematik gilt aber unabhängig vom genauen Werkzeug zur Einstellung der Zeichensatzparameter.

Konsistenz zu Zeichensatzvorgaben für PHP – Einstellungen in der php.ini

Das PHP-Programm muss in jedem Fall mit dem gewählten Zeichensatz für Resultsets adäquat umgehen können; s.u.. Der rechte Bereich der folgenden Skizze, die ich aus einem anderen Artikel dieses Blogs entliehen habe, verdeutlicht das für den Fall “SET NAMES ‘latin1′” :

Nun könnte man in seinen PHP-Programmen natürlich spezifische Umwandlungsfunktionen (u.a. iconv(), mb_convert_encoding(), utf8-encode(), utf8-decode) für die Zeichensatzkonvertierung aus- und eingehender Strings bemühen. Die linke Seite der Skizze liefert hierfür Beispiele (s. den dazu gehörigen Abschnitt weiter unten).

Wenn möglich, kann man aber auch einen Standardzeichensatz für die PHP-Verarbeitung von Strings vorgeben und sich darauf bzgl. der Datenbankinteraktion verlassen.

Entsprechende Einstellungen nimmt man in der Konfigurationsdatei
/etc/php7/apache2/php.ini
vor. Die relevanten Parameter sind dort: 

; PHP's default character set is set to UTF-8.
; http://php.net/default-charset
default_charset = "UTF-8"

; PHP internal character encoding is set to empty.
; If empty, default_charset is used.
; http://php.net/internal-encoding
;internal_encoding =

; PHP input character encoding is set to empty.
; If empty, default_charset is used.
; http://php.net/input-encoding
;input_encoding =

; PHP output character encoding is set to empty.
; If empty, default_charset is used.
; mbstring or iconv output handler is used.
; See also output_buffer.
; http://php.net/output-encoding
;output_encoding =

Die hierfür gesetzten Werten sollte natürlich mit den Einstellungen für die Datenbankverbindung zusammenpassen.

Kundenvorgaben

Wir parametrieren in Kundenprojekten die PHP-Methoden für den Verbindungsaufbau zum Datenbankserver meist gemäß expliziter Kundenvorgaben. In unserem Fall hatten wir “SET NAMES ‘latin1′” gewählt. (Hinweis: Die Zeichensatz-Namen auf einem MySQL-Server enthalten grundsätzlich keine Trennzeichen; daher ist statt iso8859-1 “latin1” zu verwenden).

Der Grund dafür war, dass das Apache-PHP-Modul des (gehosteten) Kunden-Web-Servers auf “iso-8859-1” eingestellt war. Das bestätigte eine Überprüfung mit phpinfo(). Diese Einstellungen sollten wir gem. Kundenvorgabe nicht ändern, da auf dem Web-Server auch andere PHP-Programme als unsere eigenen laufen müssen.

Auf dem Kundenserver waren die Zeichensatzeinstellungen also konsistent.

Ursache unseres Problems und die Rolle von htmlentities()

Man ahnt es bereits: Durch das Kopieren der PHP-Klasse für die Steuerung von Datenbankverbindungen vom Kundenserver auf die Testdomäne unseres lokalen Web-Servers entstand dort u.a. eine Inkonsistenz zwischen der Zeichensatzbehandlung unter PHP (utf8!) und dem Zeichensatz für den Transfer von Resultsets aus der MySQL-Datenbank (latin1).

Diese Inkonsistenz kam jedoch noch nicht zum Tragen, als wir die Daten per Copy/Paste über lokale Web-Interfaces einer UTF8-Standard-Domäne in die Bank einbrachten.

Für unsere Testdomäne dagegen muss man jedoch u.a. eine fehlerhafte Konvertierung von deutschen Umlauten erwarten! Warum aber verschwanden die Text-Strings in Gänze aus den Web-Oberflächen?

Die Antwort lieferte schließlich eine von mir bislang zu wenig beachtete Eigenschaft der PHP-Funktion “htmlentities()”.

Unsere Web-Generatoren jagen Strings vor einer Web-Darstellung durch eine Reihe von Prüfroutinen, Transformatoren für erlaubte Zeichenfolgen und durch Filter (u.a. HTMLPurifier, aber auch eigene Filter). Dabei wird in einem Zwischenschritt (nach einer vorhergehenden Konvertierung erlaubter HTML-Zeichenfolgen) auch “htmlentities()” eingesetzt.

htmlentities() erlaubt selbst eine Vorgabe des “Character Sets” über einen Parameter. Ein Check zeigte: Dieser Parameter stand in der lokalen Testdomäne explizit auf “UTF-8”. Diese Einstellung betrifft jedoch eine Konvertierung in den gewünschten Ziel-Zeichensatz für den HTML-Output. Hier hatten wir kein Problem, da die
HTML-Header der Webseiten bzw. die vom Apache-Server generierten HTTP-Header tatsächlich auf UTF-8 ausgerichtet waren.

Allerdings sorgten schon die vorhergehenden Widersprüche zwischen dem Zeichensatz der Datenbank-Resultsets und dem Zeichensatz für die anschließende Behandlung von Strings durch PHP. Das hatte gravierende Folgen. Unter http://php.net/manual/de/function.htmlentities.php findet man nämlich folgenden Hinweis:

Rückgabewerte
Gibt die kodierte Zeichenkette zurück. Enthält der string eine in dem übergebenen encoding ungültige Code Unit Sequenz, wird eine leere Zeichenkette zurückgegeben, sofern weder das ENT_IGNORE noch das ENT_SUBSITUTE Flag gesetzt sind.

(Hervorhebung durch mich).

Das war des Rätsels Lösung:

Eine Inkonsistenz in der Zeichensatzbehandlung im Datenaustausch zwischen unserer MySQL-Datenbank und PHP führte zu nicht behandelbaren Zeichen bei der Anwendung von htmlentities() auf Strings – und diese Funktion produzierte dann gemäß ihrer Default-Einstellungen leere Strings.

Trivial – man muss es halt nur wissen! Ein Test mit

“SET NAMES ‘utf8′”

ließ denn alle verschwundenen Strings auch in unserer Testdomäne prompt wieder erscheinen!

Notwendige Checks vor der Anwendung von SET NAMES (oder von mysqli_set_charset())

Hat man die Kette der Zeichensatzsetzungen bzw. Zeichensatzbehandlung im Austausch zwischen PHP und einer MySQL-Datenbank erst einmal verstanden, so ist auch klar, wo man mit vorbeugenden Maßnahmen ansetzen kann. Solche Vorkehrungen sind – wie das Beispiel zeigt – vor allem dann notwendig, wenn man die Zeichensatz-Einstellungen für PHP nicht auf allen involvierten Web-Servern beeinflussen kann oder darf.

Bevor man “SET NAMES” (oder mysqli_set_charset(); s.u.) in einem PHP-Programm tatsächlich anwendet, sollte man die Setzung des “Default Character Sets” in der php.ini für den aktuellen Server explizit abfragen – mittels

ini_get(‘default_charset’);

– und dann mit der ebenfalls abfragbaren Kollation der Datenbanktabellen vergleichen. Das Ergebnis dieses Vergleichs kann man dann nach bestimmten Regeln behandeln:

Z.B. Warnhinweise bei (ernsthafter) Inkompatibilität ausgeben. Oder wenn man wirklich sicher ist, dass nur deutsche Umlaute zu potentiellen Problemen führen können: Wahl des zu den PHP-Einstellungen konsistenten Zeichensatzes für den Transfer von Resultsets aus der Datenbank. In unserem Fall also “utf8”.

Alternative: Ändern der php.ini-Vorgaben für den Zeichensatz durch und für das laufende PHP-Programm

Auf festgestellte Inkonsistenzen in den Zeichensatzeinstellungen kann man u.U. – nämlich wenn man die dafür nötigen Rechte besitzt – auch mit einer Modifikation der php.ini-Vorgaben für das laufende Programm reagieren. Dazu muss man natürlich die Funktion ini_set() bemühen; Bsp.:

ini_set( string ‘default_charset’, ‘ISO-8859-1’)

bemühen.

Empfohlener Weg zum Setzen des “Character Sets” für eine MySQL-Verbindung

Ich möchte explizit darauf hinweisen, dass es andere Möglichkeiten als die SQL-Direktive “SET NAMES” gibt, Character Sets für die Datenbankverbindung zu setzen. Das PHP-Manual empfiehlt explizit, die Funktion

mysqli_set_charset(mysqli $link , string $charset)

anstelle von SQL und “Set Names” zu verwenden. Siehe: http://php.net/manual/de/mysqli.set-charset.php

Zeichensätze und die Web-Client-Seite

Obwohl nicht Kernthema dieses Artikels werfen wir noch einen ergänzenden Blick auf den
Datenaustausch des PHP/Web-Servers mit Web-Clients (z.B. einem Browser). Die Zeichensatzthematik setzt sich natürlich auch auf dieser Kommunikationsstrecke fort; der linke Teil der obigen Skizze verdeutlicht das am Beispiel von Ajax/Ajaj-Programmen. Diese erfordern i.d.R. UTF-8 für einen ordnungsgemäßen Datenaustausch mit dem Web-Server.

Ist der Parameter “default_charset” in der php.ini-Datei aber auf “iso-8859-1” gesetzt, so muss man ein- und ausgehende Daten entsprechend konvertieren. Dafür eignen sich die Funktionen utf8_decode() für einlaufende POST-/GET-Daten aus Ajax-Programmen und utf8_encode() bei der Erzeugung des Ajax/Ajaj-Outputs in Richtung Web-Client.

Für reinen HTML-Output gilt analoges; dabei sind aber auch HTTP- und HTML-Header-Anweisungen für Character Sets zu setzen. Siehe hierzu:
http://www.html-info.eu/php/php-als-script-sprache/item/zeichensatz-latin1-oder-unicode-utf-8.html

Fazit

In unbeabsichtigter Weise kann htmlentities() plötzlich zu einer Testfunktion für die Konsistenz zwischen

  • der Zeichensatz-Einstellungen durch “SET NAMES” bzw. mysqli_set_charset() für die MySQL/MariaDB-Datenbankanbindung an ein PHP-Programm
  • und den Zeichensatzeinstellungen für das PHP-Modul selbst auf dem Webserver

werden – und in letzter Konsequenz zu leeren Strings auf Webseiten führen.

Es lohnt sich vor einem Einsatz von “SET NAMES” – oder besser mysqli_set_charset() – eigentlich immer, die Einstellungen in der “php.ini” bzgl. des “default_charset” und verwandter Parameter abzufragen und daraus angemessene Konsequenzen für den Aufbau der Datenbankverbindung zu ziehen.

Dies gilt vor allem dann, wenn man im Rahmen von Tests und Produktivierungen auf verschiedenen Servern arbeiten will oder muss – und dabei nicht alle Konfigurationsparameter der Server selbst beeinflussen kann und darf.

Neben dem Setzen von Server- und Verbindungsparametern kann man auf festgestellte oder vorgegebene Zeichensatzanforderungen oder Zeichensatzdiskrepanzen aber auch gezielt mit verschiedenen Funktionen reagieren, die PHP für eine Zeichensatz-Detektion und eine explizite Zeichensatzkonvertierung von Strings anbietet.

PHP and web application security – bad statistics and wrong conclusions

Posted on by

Sometimes I have discussions with developers of a company working mainly with Java. As I myself sometimes do development work with PHP I am regarded more or less as a freak in this community. Typical arguments evolve along the lines:

“PHP does not enforce well structured OO code, no 4-layer-architecture built in, problems with scalability”, etc…. I do not take these points too seriously. I have seen very badly structured Java OO code, one can with proper techniques implement web services in a kind of logical 3rd layer on special servers and Facebook proves PHP scalability (with some effort), etc…

What is much more interesting for me these days is the question how security aspects fit into the use of different programming languages. And here comes the bad news – at least according to statistics published recently by the online magazine Hacker News – see
http://thehackernews.com/2015/12/programming-language-security.html

The statistics on OWASP 10 vulnerability types of the investigated PHP code looks extremely bad there – compared to the investigated Java code examples. I admit that this is an interesting result for hackers and that it is somewhat depressing for security aware PHP developers.

However, is this the bad statistics the fault of the programming language?

I doubt it – despite the fact that the named article recommends to “Choose Your Scripting Language Wisely”. I would rather recommend: Educate your PHP developers properly and regularly, implement a proper quality assurance with special security check steps based on vulnerability scanning tools and invest in regular code reviews. Why?

The investigation revealed especially large deviations in the fields of XSS, SQL-injection, command injection (major elements on the OWASP 10 list). The countermeasures against the named attack vectors for PHP are all described in literature and very well known (see e.g. the books “PHP Sicherheit” of C.Kunz, S.Esser or “Pro PHP Security” of Snyder, Myer, Southwell). One of the primary key elements of securing PHP applications against attacks of the named types is a thorough inspection, analysis and correction treatment of submitted GET/POST-parameters (and avoidance of string parameters wherever possible). Never trust any input and escape all output! Define exceptions wisely and rewrite sensitive string elements according to your rules. Check whether input really comes from the right origin – e.g. your own domain, etc., etc.

Whether all relevant security measures are implemented in the PHP code of a web application has therefore more to do with the mentality, technical ability, the knowledge and on the negative side with the laziness of the programmer than with the programming language itself. As at least the technical capability is a matter of education, I conclude:

Tests regarding type, value range, length and of course tests of the contents of received string variables and e.g. image source references plus sanitizing/elimination/deactivation of problematic contents as well as the proper use of respective available library functions for such tests should be part of regular PHP training programs. In addition the use of web application scanning tools like OWASP’s ZAP scanner or the Burp Suite Pro (if you have money to afford the latter) should be trained. Such tools should become part of the QA chain. As well as educated penetration testers with the perspective of the attacker …. The money a SW-company invests for such educational measures is well invested money.
See for the significant impact of education e.g.:
https://seclab.stanford.edu/websec/scannerPaper.pdf

I would regard the statistical results discussed in the “Hacker News” article much more conclusive if we were provided additional information about
the type of applications analyzed and also the size and type of the companies behind the application development. And whether and what type of QA efforts were used. This would give a much better indication of why the Java code showed more quality regarding the prevention of OWASP 10 attacks. One reason could e.g. be that Java applications very often are developed for enterprise purposes – and bigger companies typically invest more time and effort into QA …

So, another valid interpretation of the presented statistics could be that the QA for typical PHP web application SW is on average worse than for Java SW. I admit that such a finding would also be very interesting – but it does not prove that one cannot write secure Web applications with PHP or that the production of secure code is for whatever reasons easier with Java.

In addition the presented number of bugs per MB itself is questionable: if you only look at 3 bad PHP examples and 1 good Java example you may get the same type statistics – but it would be totally meaningless. The distribution of PHP-, Java-, JS-code etc. among the statistical sample is, however, nowhere discussed in the named article – neither in number of applications nor in MB percentages.

Therefore: Without further information the implied conclusion that already the proper choice of a web scripting language would help to improve security of web applications appears is misleading.

To improve the mood of PHP developers having read the article in “Hacker News”: Have a look at the results of a similar investigation presented at this link
http://info.whitehatsec.com/rs/whitehatsecurity/images/statsreport2014-20140410.pdf

See also:
https://blog.whitehatsec.com/a-security-experts-thoughts-on-whitehat-securitys-2014-web-stats-report/
https://www.scriptrock.com/blog/which-web-programming-language-is-the-most-secure
https://threatpost.com/security-begins-with-choice-of-programming-language/105441/

It may help, really !

[But keep in mind: Only trust statistics you have manipulated yourself.]