Sicherheitslücke mit mod Rewrite und Query-String Append

[hotti]

Mein Artikel hierzu ist praktisch das, was ich hier schon einmal ins Forum gepostet habe.

Es ist von mir getestet, das Problem ist also nachvollziehbar: Hier leckts ;)

MfG

[Mitleser]

Mein Artikel hierzu ist praktisch das, was ich hier schon einmal ins Forum gepostet habe.
Es ist von mir getestet, das Problem ist also nachvollziehbar: Hier leckts ;)

RewriteRule ^(.*).html /index.php?page=$1 [QSA,L]
Mit Kenntnis der RewriteRule lässt sich das Passwort umgehen, der Eindringling ruft folgende URL's im Browser auf:
http://example.com/user.html?page=admin

Wo ist bei Kenntnis der RewriteRule hier der sicherheitsrelevante Unterschied zu Perl?
http://example.com/cgi-bin/index.pl?page=admin

Du hast eine Sicherheitslücke, wenn Dein Mechanismus auf einem erwarteten Auflösungsmechanismus beruht.

[Matthias Apsel]

Om nah hoo pez nyeetz, hotti!

Mein Artikel hierzu ist praktisch das, was ich hier schon einmal ins Forum gepostet habe.

Es ist von mir getestet, das Problem ist also nachvollziehbar: Hier leckts ;)

Hm. Es ist wahrscheinlich nicht klug, alles an eine index.php weiterzureichen.

Abhilfe könnte

^([\w-]*).html /index.php?page=$1 [QSA,L]  

oder auch

^([A-Za-z0-9-]*).html /index.php?page=$1 [QSA,L]  

oder erlaubt der Indianer keine Zeichenklassen?

Insgesamt vermisse ich in deinem Artikel Lösungsvorschläge. So ist er nur hilfreich, wenn man sich die Seite tatsächlich durch_arbeitet_. Manche lesen „?page=user&page=admin“, fragen sich „Wer macht denn solch einen Blödsinn“ und verlassen die Seite. Nicht einmal die Information „Nutze besser Perl!“ kommt an.

Matthias

[1UnitedPower]

Meine Herren!

Mein Artikel hierzu ist praktisch das, was ich hier schon einmal ins Forum gepostet habe.

Es ist von mir getestet, das Problem ist also nachvollziehbar: Hier leckts ;)

hotti… du solltest vorsichtiger damit sein, was du als Sicherheitslücke bezeichnest.

Die Sicherheitslücke ist nicht in PHP oder Apache zu finden, sondern nur in deiner Beispiel-Anwendung. Und selbst in deinem Beispiel fehlt der relevante Teil, der die vermeintliche Sicherheitslücke demonstrieren soll, nämlich die index.php.

Ich nehme an, deine index.php-Datei soll irgendwie so aufgebaut sein:

<?php readfile( urlecnode( $_GET['page'] ) );

Wenn du als Programmier nicht willst, dass der Nutzer sich auf diese Art jede beliebige Datei anschauen können soll, dann ist das natürlich ein Programmierfehler.

Wenn du möchtest, dass PHP beim Lesen der Datei den HTTP-Access Schutz respektiert, dann musst du die Datei eben über das HTTP-Protokoll lesen und nicht direkt vom Datei-System.

<?php readfile( 'http://example.com/' . urlencode( $_GET['page'] );

Den Bezug zum $_GET-Array, den du in deiner Einleitung herstellst, kann ich auch nicht nachvollziehen.

Um das nochmal in aller Ausdrücklichkeit zu formulieren: Dein Code ist kein Exploit zu einer Sicherheitslücke, die du entdeckt hast, sondern nur eine Demonstration, wie man sich selbst eine klaffende Sicherheitslücke schaffen kann, wenn man nicht aufpasst.

[hotti]

hi,

Den Bezug zum $_GET-Array, den du in deiner Einleitung herstellst, kann ich auch nicht nachvollziehen.

Oh, hier musst Du mal was tun, damit Du meinen Artikel verstehst. Was die Array-Bildung mit PHP betrifft, teste die Rules

RewriteRule ^(.*).html /index.php?page=$1 [QSA,L]
RewriteRule ^(.*).html /index.php?page[]=$1 [QSA,L]
RewriteRule ^(.*).html /index.php?page[secret]=$1 [QSA,L]
RewriteRule ^(.*).html /index.php?page[secret][strong]=$1 [QSA,L]

und Du wirst sehen, dass allesamt manipulierbar sind für einen, der die Rule kennt.

MfG

[Sven Rautenberg]

Moin!

hi,

Den Bezug zum $_GET-Array, den du in deiner Einleitung herstellst, kann ich auch nicht nachvollziehen.

Oh, hier musst Du mal was tun, damit Du meinen Artikel verstehst. Was die Array-Bildung mit PHP betrifft, teste die Rules

RewriteRule ^(.*).html /index.php?page=$1 [QSA,L]
RewriteRule ^(.*).html /index.php?page[]=$1 [QSA,L]
RewriteRule ^(.*).html /index.php?page[secret]=$1 [QSA,L]
RewriteRule ^(.*).html /index.php?page[secret][strong]=$1 [QSA,L]

und Du wirst sehen, dass allesamt manipulierbar sind für einen, der die Rule kennt.

Und wo ist da das Problem? Es ist anerkannter Sicherheitsstandard, dass Skripte die Werte, die sie verwenden sollen, validieren auf gültigen Wertebereich.

Es ist irrelevant, dass der User dem PHP-Skript beliebige Werte im $_GET-Array ANBIETET. Relevant ist, dass der Programmierer diese Werte ungeprüft NUTZT!

PHP hat keine Sicherheitslücke, Apache hat keine Sicherheitslücke. Dein Skript hat eine Sicherheitslücke - und um die genauer zu analysieren, solltest du dein Skript im Quelltext vorlegen, dann kann man dir erklären, wo genau das Problem liegt, damit du es verstehst.

- Sven Rautenberg

[M.]

Mahlzeit,

und Du wirst sehen, dass allesamt manipulierbar sind für einen, der die Rule kennt.

Versteh ich deine Aussage jetzt richtig, weil du Parameter nicht prüfen willst, ist die Programmiersprache unsicher? Mal ehrlich, dann müssen sofort alle Server abgeschalten werden, da jede Programmiersprache diesen "Fehler" hat.

Deinen Beitrag sehe ich als Konstruktion eines Problemes, dass es nur gibt, weil du (oder andere) es erfindest. Qualitativ würde ich den Beitrag unter "absolut sinnlos" einordnen.

[hotti]

Ach Leute, während ich meinen Artikel vervollständige, hagelt es hier Sternchen ;)

Nicht einmal die Information „Nutze besser Perl!“ kommt an.

Ist ja auch nicht meine Information, das sind Worte, die mir hier untergejubelt werden, wie so oft.

Ein "Stern Blind" für diejenigen, die nicht lesen können. Das Problem ist die Parametrisierung von URLs verbunden mit einer Authorization Basic. Das hat mit Perl überhaupt nichts zu tun, wer jedoch mit PHP arbeitet, tappt da voll rein, aber sowas von!

Die Lösung scheibe ich auch noch auf: Verwende keine internen IDs, wenn Authorization Basic im Spiel ist, denn das führt zu Inkonsistenzen und dies wiederum zu einer Sicherheitslücke.

Übrigens weiß ich gar nicht, ob das Problem, was systematischer Natur ist, überhaupt mit Perl lösbar ist. Bisher kenne ich "nur" jede Menge andere Probleme, die mit derartigen RewriteRules verbunden sind. Überflüssig, zu sagen, dass ich in meinen Webanwendungen solche RewriteRules nicht verwende.

Na, dann klopft Euch mal weiterhin auf die Schultern und seht zu, dass Ihr Euch in den dadurch ausgelösten Staubwolken danach wiederfindet ;)

MfG

[Christian Kruse]

Moin hotti,

Nicht einmal die Information „Nutze besser Perl!“ kommt an.

Ist ja auch nicht meine Information, das sind Worte, die mir hier untergejubelt werden, wie so oft.

Das wurde dir nicht untergejubelt. Matthias schrieb „nichtmal die Information,” er sagte also, dass du das nicht geschrieben hast.

Ein "Stern Blind" für diejenigen, die nicht lesen können. Das Problem ist die Parametrisierung von URLs verbunden mit einer Authorization Basic. Das hat mit Perl überhaupt nichts zu tun, wer jedoch mit PHP arbeitet, tappt da voll rein, aber sowas von!

Naja, es ist ein unglückliches Zusammenspiel verschiedener Quirks, aber es ist eine Sicherheitslücke in deinem Code bzw. deiner Konfiguration, nicht in Apache oder mod_rewrite oder PHP.

Weiterhin gilt zu beachten, dass der Zugriffsschutz auf URLs, die umgeschrieben werden sollen, eh problematisch ist. mod_rewrite arbeitet in den beiden Phasen URL-to-filename translation hook und Fixup hook. Der erste Hook ist der Hook, der z.B. bei <VirtualHost>-Direktiven zum Einsatz kommt. Der findet jedoch vor der Autorisierungs-Phase statt. Der zweite Hook wird aufgerufen, wenn die Per-Directory-Hooks vorbei sind (nach der Autorisierungs-Phase). Das bedeutet, dass ein Basic Auth auf Per-Server-RewriteRules nicht möglich ist, durchaus aber auf RewriteRules, die in einer .htaccess definiert werden. Dieses Verhalten ist dokumentiert.

Du siehst also, was Autorisierung und mod_rewrite angeht, musst du eh vorsichtig sein.

LG,
 CK

[1UnitedPower]

Meine Herren!

Ein "Stern Blind" für diejenigen, die nicht lesen können.

Musst du gleich mit einer Beleidigung auf die Kritik reagieren?

Das Problem ist die Parametrisierung von URLs verbunden mit einer Authorization Basic.

Das ist kein Problem. Das Problem steckt in deiner index.php, die Datei müsste man sehen, um sagen zu können wo hier eine Sicherheitslücke besteht. Im Allgemeinen macht HTTP-Authorisierung mit mod_rewrite aber keine Probleme.

Das hat mit Perl überhaupt nichts zu tun, wer jedoch mit PHP arbeitet, tappt da voll rein, aber sowas von!

Demonstrier das doch mal bitte an einem Codebeispiel. Was muss man in falsch machen, um sich diese Sicherheitslücke aufzureißen.

Die Lösung scheibe ich auch noch auf: Verwende keine internen IDs

Und was ist eine interne ID in diesem Kontext? Und wo soll man sie nicht verwenden? Aus deinem Artikel kann man entnehmen, dass du damit die Bezeichner der Query-String-Parameter meinst. Was aber möchtest du uns mit "intern" sagen? Ich sehe kein Problem damit in einer RewriteRule einen Query-String-Parameter zu benutzen, weder auf der linken noch auf der rechten Seite.

Übrigens weiß ich gar nicht, ob das Problem, was systematischer Natur ist, überhaupt mit Perl lösbar ist.

Du schriebst eben, das Problem hätte mit Perl nichts zu tun.

Bisher kenne ich "nur" jede Menge andere Probleme, die mit derartigen RewriteRules verbunden sind. Überflüssig, zu sagen, dass ich in meinen Webanwendungen solche RewriteRules nicht verwende.

Dass du "jede Menge andere Probleme" mit der RewriteRule hast, ist für die Diskussion, ob sie eine Sicherheitslücke darstellt, irrelevant. Die RewriteRule ist ansich vollkommen harmlos.

[M.]

Mahlzeit,

Übrigens weiß ich gar nicht, ob das Problem, was systematischer Natur ist, überhaupt mit Perl lösbar ist.

Da es kein Problem gibt, muss es auch nicht lösbar sein.
Wenn du, als Programmierer, eine Sicherheitslücke schaffst und die dann in der nächsten Ebene zu beheben versuchst, hast du ein Verständnisproblem.

Eine Sicherheitslücke gehört da behoben, wo sie entsteht. Wenn sie durch mod_rewrite entsteht, muss das Problem genau da behoben werden. Alles andere ist Symptombehandlung und das ist grundsätzlich schlecht.

[Matthias Apsel]

Om nah hoo pez nyeetz, hotti!

Ach Leute, während ich meinen Artikel vervollständige, hagelt es hier Sternchen ;)

Dein Selbstbewusstsein ist wirklich bewundernswert. Wenn du nichts dagegen hast, würde ich den Thread trotzdem gerne auf no-archive setzen oder gleich löschen. Das sollte mMn. auch in deinem Sinne sein. Sag Bescheid, hier oder per Mail.

Matthias

[hotti]

Mein Artikel hierzu ist praktisch das, was ich hier schon einmal ins Forum gepostet habe.

Es ist von mir getestet, das Problem ist also nachvollziehbar: Hier leckts ;)

Im Archiv 2005 gibt es einen Hinweis auf dasselbe Problem (Dennis).

Issue

Der Authorization Part von URI's wird auf Parameter abgebildet (Parametrisierung). Parameter werden in einer RewriteRule an einen Indexer angehängt (QSA). Zum Parsen der Parameter wird serverseitig PHP eingesetzt.

Lösung

Nutzen Sie für das Routing per RewriteRule den vollständigen Authorization Part eines URI und nicht nur einen Teil davon, wenn Sie gleichzeitig Authorization Basic einsetzen und bilden Sie den Authorization Part NICHT auf Parameter ab.

Ausführliche Beschreibung siehe Link.

Ihr könnt das jetzt in aller Ruhe Euren Vorgesetzten beibringen ;)

MfG

[1UnitedPower]

Meine Herren!

Mein Artikel hierzu ist praktisch das, was ich hier schon einmal ins Forum gepostet habe.

Es ist von mir getestet, das Problem ist also nachvollziehbar: Hier leckts ;)

Im Archiv 2005 gibt es einen Hinweis auf dasselbe Problem (Dennis).

Und gibst du uns den Link? Dann können wir die Fälle auch vergleichen. Denn ein richtiges Zitat aus dem Beitrag von Dennis scheint das ja nicht gewesen zu sein, denn die Suche danach erbrachte bei mir keine Treffer.

Ihr könnt das jetzt in aller Ruhe Euren Vorgesetzten beibringen ;)

Können wir Debatte bitte wieder inhaltlich anstatt arrogant führen?

[M.]

Mahlzeit,

Ihr könnt das jetzt in aller Ruhe Euren Vorgesetzten beibringen ;)

Kann ich nicht, hab ich keinen. Ausser ich definiere meine Kunden als Vorgesetzten ;)
Allerdings bleibt weiterhin: Das Problem existiert nur, weil du es konstruierst.

Wenn du bei deinem Auto die Bremsschläuche durchschneidest macht es keinen Sinn, einen Bremsfallschirm einzubauen.

[hotti]

hi,

Allerdings bleibt weiterhin: Das Problem existiert nur, weil du es konstruierst.

Das Beispiel für die Beschreibung ist konstruiert für meine Testumgebung, um das Problem, das ich schon länger kenne, mal nachzustellen. Unabhängig vom Beispiel hast Du das Problem in dem Moment wo der Path-Part eines URI auf Parameter abgebildet wird, das Routing über Parameter erfolgt und mit Authorization Basic eine Zugangskontrolle realisiert werden soll.

Und ich kenne Einige, bei denen sich nicht nur die Vorgesetzten freuen, sondern auch die Kunden, wenn sie meinen Artikel lesen ;)

Wenn du bei deinem Auto die Bremsschläuche durchschneidest macht es keinen Sinn, einen Bremsfallschirm einzubauen.

Genau: Ein Helm wiegt Dich vielleicht in Sicherheit, erhöht diese jedoch nicht. Aber auch dieser Vergleich hinkt ;)

MfG

[M.]

Mahlzeit,

Unabhängig vom Beispiel hast Du das Problem in dem Moment wo der Path-Part eines URI auf Parameter abgebildet wird, das Routing über Parameter erfolgt und mit Authorization Basic eine Zugangskontrolle realisiert werden soll.

Und genau damit konstruierst du ein Problem, das nur entsteht, wenn du eine bestimmte Kombination an Ablauf-Prozessen hast. Wenn dadurch ein Sicherheitsloch entsteht, gibt es dafür eine einfache Bezeichnung: BUG

Und ich kenne Einige, bei denen sich nicht nur die Vorgesetzten freuen, sondern auch die Kunden, wenn sie meinen Artikel lesen ;)

Klar, denn jeder, der ein wenig Hintergrundwissen hat, wird deinen Artikel als Belustigung sehen. Nicht ganz so schlimm wie dieser hier, aber dennoch belustigend.

Genau: Ein Helm wiegt Dich vielleicht in Sicherheit, erhöht diese jedoch nicht. Aber auch dieser Vergleich hinkt ;)

Stimmt, dein Vergleich hinkt (nicht nur, der ist ja schon beinamputiert und kan nicht mal mehr hinken), denn ein Helm erhöht die Sicherheit massiv, egal ob auf dem Motorrad oder im Auto. Das heisst, meine Aussage trifft zu, deine (wieder mal) nicht.

[Gunnar Bittersmann]

@@M.:

nuqneH

Nicht ganz so schlimm wie dieser hier,

Ach du Scheiße!

„Das Responsive Design, legt wie der Name bereits andeutet, viel Wert auf ein ,schönes Äußeres‘.“

Warum maßen sich immer wieder Leute an, über RWD zu schreiben, die davon nicht die geringste Ahnung haben?

„Bei einer mobilen Website hingegen liegt der Fokus auf der Usability.“

Bei diesem Artikel liegt der Fokus auf Schwachsinn.

Qapla'

[M.]

Mahlzeit,

Bei diesem Artikel liegt der Fokus auf Schwachsinn.

Und den haben sie dann in den Kommentaren zu begründen versucht. Und der Autor arbeitet beim selbsternannten Marktführer für Shoplösungen :D