Saubere URLs gehören längst zum guten Ton. Zwar werden diese vom „Otto-Normal-Nutzer“ während des Surfens meist gar nicht wahrgenommen, der Vorteil von:
http://www.example.com/de/products/productname-12/details gegenüber:
http://www.example.com/index.php?section=products&show=details&id=12&lang=de wird aber spätestens bei der Verwendung in E-Mails, SMS oder auf Papier deutlich. Selbst dem ein oder anderen Internetausdrucker dürfte hierbei auffallen, dass es eben auf die Länge und die Technik ankommt.
Neben rein ästhetischen und die Optimierung für Benutzer und Suchmaschinen betreffenden Aspekten können saubere URLs auch einen gewissen – wenn auch geringen – Sicherheitsvorteil gegenüber Ihrem Pendant im 90er-Jahre-Stil bieten. Letzterer liefert gegebenenfalls schneller Informationen über den internen Aufbau der Web-Applikation und bietet somit einen zusätzlich Ansatzpunkt für Angriffe, sofern entsprechende Schwachstellen in der Anwendung existieren. So könnte, hinter den oben genannten Beispiel-URLs die gleiche Anwendung laufen, allerdings geht nur aus der zweiten Adresse hervor, dass es sich um eine PHP-Anwendung handelt (Das Wissen über die verwendete Skript- oder Programmiersprache ermöglicht unter Umständen grundlegende Annahmen über den Aufbau der Applikation und könnte daher für einen Angriff relevant sein.). Darüber hinaus offenbart die zweite URL-Adresse über die GET-Parameter gegebenenfalls die Namen der verwendeten Variablen und zum Teil auch deren Funktion innerhalb der Applikation. Sofern im ersten Beispiel die expose_php-Direktive in der php.ini deaktiviert ist, lässt sich ohne Weiteres nicht herausfinden, dass PHP im Spiel ist und ein Rückschluss auf Variablennamen ist nicht möglich.
Sicherlich handelt es sich hierbei nur um „Securiy through obscurity“ und den Daten die vom Benutzer kommen – also neben Cookies und POST-Daten auch den GET-Parametern – sollte man grundsätzlich mit dem nötigen Misstrauen begegnen. Eine zusätzlich Hürde für potentielle Angreifer kann jedoch nie schaden.
Nach diesem mehr oder weniger allgemeinen Vorgeplänkel, schneidet der zweite und letzte Teil der Kurzreihe mögliche Sicherheitsvorteile bei der Verwendung von mod_rewrite im Gegensatz zu einer PHP–Rewrite-Engine an und setzt sich mit der Frage auseinander, an welcher Stelle in der Webapplikation das Umschreiben der URL denn eigentlich stattfinden sollte.
Die effiziente Nutzung begrenzter Ressourcen, ist nicht nur ein ökonomisches und ökologisches Anliegen, auch bei der Entwicklung von Webanwendungen ist der schonende Umgang mit der zur Verfügung stehenden Rechen- und Speicherkapazität ein wichtiger Aspekt.
Bei einem kleinen Backend-Skript mag es wenig sinnvoll sein auch noch die letzte Mikrosekunde rauszukitzeln. Bei offenen Webpräsenzen, deren Server der potentiellen „Gefahr“ ausgesetzt ist, durch einen Link von einer großen Webseite aufgrund des Besucheransturms in die Knie gezwungen zu werden, sollten allzu enge Flaschenhälse jedoch vermieden werden.
Zum Aufspüren von Geschwindigkeitsproblemen in PHP-Anwendungen, die durch einzelne Funktionen verursacht werden, bietet sich die Kombination aus Xdebug und Webgrind an, um ein minimales Profiling durchzuführen.
Xdebug installieren und einrichten
Xdebug wird als PHP-Modul installiert und bietet neben dem Profiling auch nützliche Möglichkeiten zum Debugging von PHP-Skripten. Für Ubuntu gibt es ein Paket in den Repositories, weshalb die Installation auch schnell erledigt ist (ein installierter Apache mit PHP vorausgesetzt):
sudo apt-get install php5-xdebug
Anschließend muss man in der Datei /etc/php5/conf.d/xdebug.ini das Profiling aktivieren. Dabei empfiehlt es sich die Trigger-basierte Variante zu wählen, da ansonsten bei jeder Ausführung eines PHP-Skripte eine Profiler-Datei geschrieben wird, was bei umfangreichen Anwendungen schon mal einige Megabyte sein können.
; Laufendes Profiling deaktivieren
xdebug.profiler_enable = 0
; URL-Trigger ?XDEBUG_PROFILE aktivieren
xdebug.profiler_enable_trigger = 1
Standardmäßig werden die Profiler-Dateien in das Verzeichnis /tmp geschrieben. Dies lässt sich jedoch über die Option xdebug.profiler_output_dir nach belieben anpassen. Ruft man nun eines seiner PHP-Skripte mit dem zusätzlichen Parameter XDEBUG_PROFILE (z.B. http://localhost/MeinSkript.php?XDEBUG_PROFILE) auf, so landet eine Datei mit dem Namen cachegrind.out.???? im eingestellten Verzeichnis. Der Inhalt dieser Datei ist auf den ersten Blick nicht wirklich aufschlussreich, allerdings lässt sich das ändern.
Auswertung mit Webgrind
Als Mittel der Wahl zur Auswertung der Cachegrind-Dateien werden in der Xdebug-Dokumentation KCacheGrind und WinCacheGrind empfohlen. Möchte man aber weder KDE-Komponenten, noch das Betriebssystem aus Redmond auf seinem Rechner installieren, muss man sich nach einer Alternative umsehen. Als betriebssystemunabhängige und unkomplizierte Möglichkeit bietet sich Webgrind an.
Die Installation ist denkbar einfach und in drei Schritten erledigt (vorausgesetzt man hat einen lauffähigen Webserver, wovon auszugehen ist, wenn man PHP-Skripte testen will): 1. Herunterladen 2. An geeigneter Stelle entpacken 3. Im Browser aufrufen.
Wer für Xdebug ein anderes Verzeichnis für die Profiler-Dateien gesetzt hat, der muss allerdings noch den Pfad in der config.php entsprechend anpassen.
Sofern entsprechende Profiler-Dateien vorhanden sind, lassen sich diese unter Webgrind über die Dropdown-Box am oberen Bildrand auswählen und per Klick auf den Button auswerten. Die Auswertung lässt sich wahlweise prozentual, nach Milli- oder Mikrosekunden vornehmen. Die Übersicht bietet die Möglichkeit sich anzeigen zu lassen durch welche Funktion die jeweils betrachtete Funktion aufgerufen wurde und die dazugehörige Stelle lässt sich auch im Quelltext anzeigen.
Fazit
Mit Xdebug und Webgrind lässt sich relativ einfach ein kurzer Überblick, über die Laufzeiten der einzelnen Funktionen eines PHP-Skripts, erreichen. Flaschenhälse lassen sich so schnell identifizieren und potentiellen Problemen bei steigenden Besucherzahlen, kann somit vorgebeugt werden.