Saubere URLs I: Aber sicher doch!

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.