Ausnutzbar?

[Allandor]

Ist das überhaupt ausnutzbar?
Wenn ich das richtig verstehe wird ein verschlüsselter HTTPs Call an den Webserver gemacht. Das alle Infos dabei in der URL stehen kann ich mir zwar nicht vorstellen, denn solche Daten stehen normalerweise im Body damit sie auf jeden Fall mitverschlüsselt werden.
D.h. wenn jemand das ganze abfangen würde, müsste er erst mal die eingesetzte HTTPS-Verschlüsselung knacken seine Anfrage anhängen und neu kodieren.
Da ich mal nicht davon ausgehe würde das heißen, das der Angreifer müsste sich bereits in der Anwendung befinden, damit diese Lücke auch nur irgendwie ausgenutzt werden kann.
Wenn ich mich eh schon dort befinde, ist eh alles zu spät. Da dürfte das meine geringste Sorge sein, denn der Angreifer dürfte dann auch bereits über die Möglichkeiten Verfügen von der Software entsprechende abfrage gültig verschlüsselt und signiert abzuschicken. Der "Huckepack"-Hack wäre da gar nicht nötig.

[Schnarchnase]

Allandor schrieb:
--------------------------------------------------------------------------------
> Das alle Infos dabei in der URL stehen kann ich mir zwar nicht vorstellen,
> denn solche Daten stehen normalerweise im Body damit sie auf jeden
> Fall mitverschlüsselt werden.

Die URL selbst wird auch verschlüsselt.

[Mingfu]

Also erst einmal wie schon geschrieben: Bei HTTPS wird auch die Anfrage-URL verschlüsselt. Der Client baut eine TCP-Verbindung zum Webserver (üblicherweise an Port 443) auf, dann wird die Verschlüsselung ausgehandelt und schließlich wird über die verschlüsselte Verbindung das HTTP-Protokoll gefahren (insbesondere wird damit also auch die URL eines GET-Requests mitverschlüsselt). Ein Außenstehender sieht nur, an welche IP-Adresse und an welchen Port eine Verbindung aufgebaut wird, nicht aber, welche HTTP-Anfragen erfolgen.

Und nun zum Inhaltlichen: Es handelt sich einfach um einen Validierungsfehler auf Serverseite. Wenn man den elektronischen Personalausweis verwendet, baut der Client eine Verbindung zu einer Beglaubigungsinstanz auf. Diese kommuniziert verschlüsselt mit dem Personalausweis, lässt sich von ihm die gespeicherten Daten zuschicken und beglaubigt sie anschließend mit ihrer eigenen Signatur. Diese signierten Daten werden an den Client zurückgeschickt, der sie nun gegenüber Dritten als Beweis seiner Identität einsetzen kann. Es handelt sich dabei einfach um signierte URL-Parameter mit den Ausweisdaten.

Und hier entsteht nun beim eigentlichen Webserver, der die Daten haben will, ein Verifizierungsproblem: Er liest die URL-Paramter und prüft zunächst die Signatur. Wenn die stimmt, liest er nochmals die URL-Parameter ein und verarbeitet sie dann entsprechend. Allerdings wird beim Prüfen der Signatur bei doppelten URL-Parametern genau andersherum verfahren wie beim späteren Verarbeiten. Wenn der Client also die URL modifiziert, so dass Parameter mit dem gleichen Namen doppelt vorkommen, so wird beim Prüfen der Signatur das letzte Auftreten des Parameters mit dem dortigen Wert überprüft, beim späteren nochmaligen Einlesen aber das erste Auftreten des Parameters verarbeitet. Man kann also Wunschdaten vorn in die URL eintragen und weiter hinten hängt man dann die Daten einer beglaubigten Kopie an. Die wird akzeptiert, verarbeitet werden aber später die Daten vorn, die man sich einfach nur ausgedacht hat.