FormBuilder: Eigene Action

  • Hallo Community,

    ich habe eine Form erstellt mit dem FormBuilder und möchte bei Submit der Form an eine FooPdfExporAction weiterleiten.


    Derzeit überschreibe ich die save() Methode mit:

    Code
    HeaderUtil::redirect(
        LinkHandler::getInstance()->getLink('FooPdfExport')
    )

    Dies klappt auch, aber wie übergebe ich die Parameter der Form an die Action? Derzeit nutze ich den SessionHandler um Variablen zu registrieren und greife auf diese in der Action-Klasse zu. Klappt auch alles, fühlt sich nur falsch an. Über GET-Parameter soll es aber auch nicht sein.

    Jemand einen Tipp für mich? :saint:

  • Ich wüsste nicht, was gegen den SessionHandler spricht. Am saubersten wäre meiner Meinung nach die Übergabe einer ID (eines DatabaseObjects) oder eines Hashes (wenn das DatabaseObject nicht einem Nutzer zugeordnet ist und eine Zugangskontrolle darüber nicht abgefragt werden kann) per GET-Parameter.

    Wenn der FormBuilder gar keine Daten persistent speichert und diese nur "on-the-fly" existieren, kannst du diese auch verschlüsselt per GET-Parameter über CryptoUtil::createSignedString übergeben.

  • Wie der Name der Methode impliziert, sind die Daten nicht verschlüsselt, sondern signiert.

    An der Stelle auch mal zwei Fragen. Wie ich sehe wird hash_hmac() verwendet, demnach:

    1) Es handelt sich doch um eine Verschlüsselung? „Die Nachricht“ wird verschlüsselt und kann nur mit dem Secret entschlüsselt werden, der aber nur Server-seitig bekannt ist (oder eben nur dem Empfänger und/oder Sender). Würde gerne verstehen weshalb dies nicht als Verschlüsselung zu sehen ist.

    2) Wo definiert man im WoltLab den Secret Key? Derzeit wird scheinbar fix eine Konstante SIGNATURE_SECRET mitgegeben? Ich kann aus der Klasse nicht erkennen, wo dieser definiert wird. Oder ich hab Tomaten 🍅 auf den Augen 👀

    • Offizieller Beitrag

    Hallo,

    Würde gerne verstehen weshalb dies nicht als Verschlüsselung zu sehen ist.

    eine HMAC ist, wie der Name impliziert, ein Hash-basierter Wert, der eine Nachricht authentifiziert. In der Natur eines Hashes liegt, dass er unumkehrbar ist. Die Rückgabe von getSignedString() enthält neben der HMAC (zur Authentifizierung) aber auch noch die Original-Nachricht in base64-kodierter Form. Bei der Überprüfung wird dann die Nachricht noch einmal durch die HMAC gejagt und beide Werte verglichen – wie bei einem Kennwort.

    2) Wo definiert man im WoltLab den Secret Key? Derzeit wird scheinbar fix eine Konstante SIGNATURE_SECRET mitgegeben? Ich kann aus der Klasse nicht erkennen, wo dieser definiert wird. Oder ich hab Tomaten 🍅 auf den Augen 👀

    Der wird bei der Installation zufällig erzeugt, kann aber auch irgendwo im ACP geändert werden. Eine Änderung führt aber u.a. dazu, dass alle Sessions ungültig werden.

  • eine HMAC ist, wie der Name impliziert, ein Hash-basierter Wert, der eine Nachricht authentifiziert. In der Natur eines Hashes liegt, dass er unumkehrbar ist. Die Rückgabe von getSignedString() enthält neben der HMAC (zur Authentifizierung) aber auch noch die Original-Nachricht in base64-kodierter Form. Bei der Überprüfung wird dann die Nachricht noch einmal durch die HMAC gejagt und beide Werte verglichen – wie bei einem Kennwort.

    Vielen Dank für deine Ausführung, soweit verstanden. Somit gehe ich aber doch richtig in der Annahme, wenn ich sage, dass der Empfänger - oder der üble Hacker in der „Mitte“ - die Nachricht nur entschlüsseln kann, wenn der Key bekannt ist?

    Ich frage, weil Christopher Walz mich auf eine Idee gebracht hat und ich so möglicherweise GET Parameter generieren könnte wie bspw. eine ID eines Objekts, die ein Dritter gar nicht nachvollziehen kann - selbst wenn er die URL sieht. Erst einmal nur theoretisch. Beispiel: Benutzer können z. B. Support-Anfragen (Tickets, whatever) erstellen, die persistent gespeichert werden. Angenommen ein Benutzer erstellt eine Anfrage am Montag und am Sonntag. Auf Grundlage der neu generierten ID am Sonntag kann der Benutzer jetzt vielleicht Rückschlüsse auf die Auslastung des Teams ziehen. Hat die ID am Montag den Wert 4711 und am Sonntag 4712, gab es von anderen Benutzern womöglich (bzw. sicher nachvollziehbar) keine Anfragen. :/

    • Offizieller Beitrag

    Vielen Dank für deine Ausführung, soweit verstanden. Somit gehe ich aber doch richtig in der Annahme, wenn ich sage, dass der Empfänger - oder der üble Hacker in der „Mitte“ - die Nachricht nur entschlüsseln kann, wenn der Key bekannt ist?

    Nein, denn die Daten sind in base64-kodierter Form Bestandteil des Wertes und damit ohne Schwierigkeiten auslesbar.

    Der Sinn und Zweck von HMAC ist es, dass die Daten nicht geheim, aber fälschungssicher sind. Wir machen uns dies beispielsweise bei den Sessions zu Nutze, bei dem das „Erraten“ einer gültigen Session-ID nicht ausreichend ist, um sich authentifizieren zu können. Die Daten im Cookie sind mittels HMAC kryptografisch signiert, so dass der Angreifer zwar eine gefälschte Session-ID vorzeigen kann, aber der Server dies auf Grund der fehlerhaften Signatur ablehnt.

    Ein typisches Szenario sind auch JWTs, bei denen der Browser die Daten von Server A an Server B weitergibt. Dem Browser wird dabei nicht vertraut, so dass mittels HMAC sichergestellt ist, dass die Daten, die der Browser an Server B übermittelt auch tatsächlich unverändert von Server A stammt.

    Auf Grundlage der neu generierten ID am Sonntag kann der Benutzer jetzt vielleicht Rückschlüsse auf die Auslastung des Teams ziehen. Hat die ID am Montag den Wert 4711 und am Sonntag 4712, gab es von anderen Benutzern womöglich (bzw. sicher nachvollziehbar) keine Anfragen. :/

    Eine ID muss nicht unbedingt rein numerisch sein, das beste Beispiel sind die Sessions. Diese verwenden einen String der lediglich aus den Zeichen 0-9 und a-f besteht.

  • Hallo,

    Nein, denn die Daten sind in base64-kodierter Form Bestandteil des Wertes und damit ohne Schwierigkeiten auslesbar.

    Achso, okay. :) Mir ging es primär um die alleinige Benutzung von hmac, ohne den Wert als base64 noch zusätzlich verfügbar zu machen. Eine Entschlüsselung wäre somit nur durch Bekanntgabe des private Keys möglich, oder nicht? So hatte ich es mal mit „Alice und Bob“ gelernt. 8o

    Der Sinn und Zweck von HMAC ist es, dass die Daten nicht geheim, aber fälschungssicher sind. Wir machen uns dies beispielsweise bei den Sessions zu Nutze, bei dem das „Erraten“ einer gültigen Session-ID nicht ausreichend ist, um sich authentifizieren zu können. Die Daten im Cookie sind mittels HMAC kryptografisch signiert, so dass der Angreifer zwar eine gefälschte Session-ID vorzeigen kann, aber der Server dies auf Grund der fehlerhaften Signatur ablehnt.

    Vielen Dank für deine Ausführung. Ich habe das jetzt etwas sacken lassen, aber das System hinter den Sessions hier interessiert mich dann doch :saint: Sorry wenn ich noch einmal nachfrage, aber: Angenommen ich bin an einem fremden Computer, kopiere / fotografiere mir die Session-ID aus dem Session-Cookie ab und benutze diese anschließend an einem anderen Endgerät. Dann hat diese von mir benutzte Session-ID doch zeitgleich auch den kryptographischen Wert und somit die Signatur - oder wo genau wird die Signatur gespeichert? Notfalls fotografiere ich mir den Wert des Cookies eben einfach noch mit ab. Oder geht es hierbei wirklich nur um das reale „erraten“ einer Sitzungs-ID?

    Danke vorab.

    JAY

    • Offizieller Beitrag

    Achso, okay. :) Mir ging es primär um die alleinige Benutzung von hmac, ohne den Wert als base64 noch zusätzlich verfügbar zu machen. Eine Entschlüsselung wäre somit nur durch Bekanntgabe des private Keys möglich, oder nicht? So hatte ich es mal mit „Alice und Bob“ gelernt. 8o

    Was du meinst, ist eine Verschlüsselung.

    Ein Hash ist aber eine Prüfsumme, bei dem die "Zurückrechnung" des ursprünglichen Wertes nicht möglich sein soll. Deshalb setzt man auch nie "HMAC" ein sondern beispielsweise "HMAC-SHA256", denn die Nutzung einer Hash-Funktion ist integraler Teil von "HMAC".

    Und wenn du davon sprichst, HMAC ohne den Wert als base64 zu verwenden, dann bleibt nur noch der Hash übrig. Oder eben eine Verschlüsselung.

    Angenommen ich bin an einem fremden Computer, kopiere / fotografiere mir die Session-ID aus dem Session-Cookie ab und benutze diese anschließend an einem anderen Endgerät. Dann hat diese von mir benutzte Session-ID doch zeitgleich auch den kryptographischen Wert und somit die Signatur - oder wo genau wird die Signatur gespeichert? Notfalls fotografiere ich mir den Wert des Cookies eben einfach noch mit ab. Oder geht es hierbei wirklich nur um das reale „erraten“ einer Sitzungs-ID?

    Auf https://jwt.io/ gibt es einen praktischen Debugger für JWT, als Signatur kommt häufig HS256 (HMAC-SHA256) zum Einsatz. Ich wähle diese Seite, weil du dort sehr schön sehen kannst, wie die farbigen Fragmente links mit den Daten rechts korrelieren. Die ersten beiden Fragmente sind lediglich base64-kodiert, du kannst sie auch rauskopieren und in der Browser-Console durch atob() jagen :)

    Der Sinn von HMAC ist es nicht, den Inhalt geheim zu halten, sondern die Echtheit der Daten zu bestätigen. Im Session-Cookie steht übrigens der HMAC: Wenn du den also abgreifst, kannst du diesen so auch verwenden. Wir verwenden HMAC damit ein Angreifer nicht einfach wild Session-IDs ausprobieren kann, das ist ein ganz anderes Szenario.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!