URLs verschlüsseln

[Matt]

Watch out,

ich gebe momentan ein paar Informationen per URL weiter. Die Customer-ID wird selbstverständlich nach Login in der Session gespeichert. Aber es gibt anderer Infos die ich per URL in diesem Stil weitergebe: sSole.php?id=112&action=add

Kann man den Teil für die GET-Metohde irgendwie sicher (halbwegs...) verschlüsseln? Also nicht was in Richtung MD5, was nicht wirklich rückgängig gehen würde. Auf der aufgerufenen Page sollte es ja wieder entschlüsselbar sein.

Wie sieht es da mit der _mcrypt library_ aus?
Oder andere Vorschläge?

Cheers, Matt

[Sven Rautenberg]

Moin!

ich gebe momentan ein paar Informationen per URL weiter. Die Customer-ID wird selbstverständlich nach Login in der Session gespeichert. Aber es gibt anderer Infos die ich per URL in diesem Stil weitergebe: sSole.php?id=112&action=add

Kann man den Teil für die GET-Metohde irgendwie sicher (halbwegs...) verschlüsseln?

Nein. Warum auch? Was planst du? Insbesondere: Was soll das Angriffsszenario sein?

- Sven Rautenberg

[Matt]

Nein. Warum auch? Was planst du? Insbesondere: Was soll das Angriffsszenario sein?

• Sven Rautenberg

Hi,

danke euch Beiden.

Ich möchte nicht, dass durch einfache Parameterveränderung bei der URL möglicherweise ein Benutzer etwas sehen kann, was nicht sein soll.

Ich sichere die Abfragen von Daten ja immer ab, dass ein Kunde immer nur seine Daten sieht und wenn er versucht die ID zu ändern, eine leere Rückgabe bzw. keine bekommt, wenn hinter dieser ID nicht seine CustomerID liegt.

Mir geht es nur darum, dass man soetwas nicht in der URL sehen kann.

Das ganze jedesmal per Session mitzugeben scheint mir auch nicht gerade mit wenig Aufwand verbunden zu sein?

[Matt]

Mir geht es nur darum, dass man soetwas nicht in der URL sehen kann.

z.B. dass aus:
link.php?id=10112&action=add

das hier wird:
link.php?audh6773gtas762ay

[Horst]

Hallo,

z.B. dass aus:
link.php?id=10112&action=add

das hier wird:
link.php?audh6773gtas762ay

Mit einer synchronen Verschlüsselung geht sowas. Evntl. hinterher noch mit Base64 encoden. Aber ich würde nicht den kopletten QUERY_STRING verknoten, sondern nur die einzelnen Parameter. Das macht das Parsen einfacher. Da sind zwar noch die Parameternamen (id, action) zu sehen, aber nicht die nackten Values.

Auf jeden Fall ist es immer wichtig, serverseitig zu prüfen, ob die Parameter überhaupt gültig sind. Wenn möglich, deren Wertebereiche auch noch einschränken.

Viele Grüße,
Hotte

[Sven Rautenberg]

Moin!

Ich möchte nicht, dass durch einfache Parameterveränderung bei der URL möglicherweise ein Benutzer etwas sehen kann, was nicht sein soll.

Dann verhindere das serverseitig.

Denn auch "mit Verschlüsselung" würde dein Server ja sonst die Daten rausrücken, obwohl der Benutzer das nicht sehen darf. Denn die Verschlüsselung kann man ja problemlos nachvollziehen, wenn die clientseitig passiert, und mit geänderten Parametern versorgen.

Ich sichere die Abfragen von Daten ja immer ab, dass ein Kunde immer nur seine Daten sieht und wenn er versucht die ID zu ändern, eine leere Rückgabe bzw. keine bekommt, wenn hinter dieser ID nicht seine CustomerID liegt.

Mir geht es nur darum, dass man soetwas nicht in der URL sehen kann.

Wenn du die URL nett haben willst, verwende POST.

Das ganze jedesmal per Session mitzugeben scheint mir auch nicht gerade mit wenig Aufwand verbunden zu sein?

Du kannst nichts "per Session mitgeben", wenn es sich um Userinteraktion handelt.

- Sven Rautenberg

[Matt]

Dann verhindere das serverseitig.

Klingt einleuchtend.
Wie ist das möglich?

[Sven Rautenberg]

Moin!

Dann verhindere das serverseitig.

Klingt einleuchtend.
Wie ist das möglich?

Die Frage, die du zu beantworten hast:

Darf User X Zugriff auf Datensatz Y haben? Oder genauer: Darf User X mit Datensatz Y Aktion Z ausführen?

Unter Datensatz ist u.U. das gesamte Konglomerat zu verstehen, nicht nur ein Eintrag in einer DB-Tabelle.

Unter Aktion ist mindestens das typische "CRUD" zu verstehen (create, retrieve, update, delete), oder auch umfangreichere Dinge - hängt von der Applikation ab.

Da du ja derzeit irgendwie hinkriegst, dass ein User X nicht alle Links zu allen Datensätzen angezeigt bekommt, gibt es ja offensichtlich Regeln, anhand derer du prüfen kannst, ob eine vom User veranlaßte Aktion einen für ihn erlaubten Datensatz betrifft, und auch, ob die Aktion überhaupt erlaubt ist.

Eine Verschlüsselung der Aktionsparameter bewirkt nur, dass dein Debuggingaufwand steigt, aber nicht automatisch, dass der User nicht trotzdem Dinge tut, die nicht zulässig sind. Das mußt du also zwingend serverseitig prüfen, denn alles, was vom User zurückkommt, ist potentiell böse - auch wenn es verschlüsselt ist.

- Sven Rautenberg

[Alexander (HH)]

Das mußt du also zwingend serverseitig prüfen, denn alles, was vom User zurückkommt, ist potentiell böse

AMEN! Das sollte jedem, der irgendeine Software mit Netwerkanbindung oder User-Interaktion schreibt, intensivst eingebleut werden.

Leider vergeigen auch riesige Firmen immer noch die Überprüfung der Daten, mit denen ihre Client-, Server- oder Anwendungssoftware arbeiten. Jede Anwendung sollte davon ausgehen, dass ALLE Benutzereingaben und ALLE Daten aus dem Netz sowie ALLE Dateien bösartig sind, bis eine Validierung das Gegenteil beweist.

Perls Taint-Mode ist ein kleiner Schritt in die richtige Richtung, der zumindest die Weitergabe von unvalidierten Eingaben an kritische Betriebssystemfunktionen unterbindet.

Alexander

[Marc Reichelt]

Hallo Matt,

Kann man den Teil für die GET-Metohde irgendwie sicher (halbwegs...) verschlüsseln? Also nicht was in Richtung MD5, was nicht wirklich rückgängig gehen würde. Auf der aufgerufenen Page sollte es ja wieder entschlüsselbar sein.

Wie sieht es da mit der _mcrypt library_ aus?
Oder andere Vorschläge?

Ich würde dir vorschlagen dein Sicherheitskonzept nochmal zu überdenken.

1. Bei brisanten Daten lohnt sich ein SSL-Zertifikat und die Abwicklung des gesamten Datenverkehrs über HTTPS. Das ist sicher, kostet aber auch etwas. Es gibt zwar auch CAcert, das ist aber immer noch nicht durch den Audit.
2. Sensible Daten gehören auch in die Session - nicht nur die Customer-ID.
3. Wenn sensible Daten an den Server übertragen werden müssten diese bereits vor dem Absenden (sprich: Auf der Client-Seite) verschlüsselt werden. Das wäre mit JavaScript ziemlich aufwendig, ist aber möglich.

Grüße

Marc Reichelt || http://www.marcreichelt.de/