Smoobu-Verfügbarkeiten per HMAC sicher in die Website einbinden

Auf einigen der von mir betreuten Websites läuft im Hintergrund eine kleine selbst gebaute WordPress-Erweiterung, die aktuelle Verfügbarkeiten von Ferienunterkünften direkt aus Smoobu holt. Daraus entsteht dann auf der Website eine übersichtliche Darstellung mit freien Zeiten, Preisen, Ausstattung und Buchungsmöglichkeit.

Bislang war das technisch angenehm unspektakulär: Zugangsschlüssel mitsenden, Antwort bekommen, fertig.

Dann kündigte Smoobu an, das Verfahren umzustellen. Künftig reicht der einfache Schlüssel nicht mehr aus. Jede Anfrage muss zusätzlich kryptografisch signiert werden.

Also hieß es: bestehende Lösung umbauen – aber bitte so, dass im laufenden Betrieb nichts ausfällt.

Ausgangslage

Die Verfügbarkeitsanzeige ist für den Betreiber (booking.rgs.group) kein nettes Zusatzfeature, sondern ziemlich wichtig. Wenn die Schnittstelle nicht mehr antwortet oder die Authentifizierung fehlschlägt, verschwinden im schlimmsten Fall einfach die freien Unterkünfte von der Website.

Nicht schön.

Das bisherige Verfahren war simpel: API-Schlüssel mitschicken und fertig. Beim neuen Verfahren wird jede Anfrage zusätzlich mit einer Signatur versehen. Die Gegenseite kann damit prüfen, ob die Anfrage tatsächlich von einem berechtigten Absender kommt und unterwegs unverändert geblieben ist.

Sicherheitstechnisch sinnvoll. In der Umsetzung allerdings etwas empfindlicher.

Denn bei solchen Signaturen reicht schon ein einziges abweichendes Zeichen, eine andere Reihenfolge oder eine leicht andere Schreibweise – und beide Seiten berechnen unterschiedliche Ergebnisse. Dann heißt es schlicht: nicht autorisiert.

Zielsetzung

Mir war wichtig, dass die Umstellung nicht nach dem Prinzip „neuen Code hochladen und schauen, was passiert“ läuft.

Deshalb sollte der bisherige Zugang erst einmal vollständig erhalten bleiben.

Das neue Verfahren musste parallel dazu eingebaut werden, sodass ich jederzeit zwischen alt und neu wechseln kann. Außerdem wollte ich die neue Authentifizierung separat testen können, ohne die laufende Verfügbarkeitsanzeige anzufassen.

Und ganz wichtig: nicht erst zwei Tage vor irgendeinem Abschalttermin anfangen, hektisch an produktiven Websites herumzuschrauben.

Vorgehen im Labor

Also habe ich den neuen Signierweg zusätzlich eingebaut, ohne den alten anzurühren.

Im Administrationsbereich gibt es jetzt einen Umschalter zwischen beiden Verfahren. Standardmäßig blieb zunächst die bisherige Variante aktiv.

Dazu kam ein eigener Testknopf. Der schickt genau eine Anfrage mit dem neuen Verfahren an Smoobu und zeigt anschließend, ob sie akzeptiert wurde oder nicht.

Das war mir wichtiger als irgendeine besonders elegante theoretische Lösung. Ich wollte einen Knopf drücken können und anschließend wissen: funktioniert – oder funktioniert nicht.

So ließ sich die neue Authentifizierung gegen die echte Schnittstelle testen, während die normale Website einfach weiterlief.

Sorgfalt bei den Zugangsdaten

Bei solchen Dingen gehört für mich nicht nur die eigentliche Signatur zur Sicherheit.

Auch der Umgang mit den Zugangsdaten muss passen.

Der alte und der neue Schlüssel werden getrennt gespeichert. Das geheime Material für die Signatur wird nach dem Speichern nicht wieder sichtbar in die Administrationsseite geschrieben. Und bei Diagnoseausgaben werden sensible Werte maskiert.

Das klingt erst einmal nach Kleinkram. Aber meistens sind es genau solche Kleinigkeiten, durch die aus einer theoretisch sicheren Lösung eine tatsächlich brauchbare wird.

Als zertifizierter Datenschutzbeauftragter schaue ich bei solchen Integrationen ohnehin etwas genauer hin, was irgendwo gespeichert, ausgegeben oder unnötig offengelegt wird.

Der Stolperstein

Natürlich funktionierte es beim ersten echten Versuch nicht. Wäre ja auch langweilig gewesen.

Smoobu antwortete auf die signierte Anfrage schlicht mit „nicht autorisiert“.

Zeitstempel da. Zufallswert da. Prüfsummen da. Signatur da.

Also begann das übliche Spiel: Wo unterscheiden sich die Daten, die ich signiere, von den Daten, die Smoobu auf seiner Seite erwartet?

Und da wird es bei solchen Verfahren schnell kleinlich.

Die Anfrage muss vor dem Signieren in eine ganz bestimmte Form gebracht werden. Zeichenfolge, Reihenfolge, Darstellung – alles muss exakt passen.

Am Ende lag es tatsächlich an einem einzigen unscheinbaren Detail bei dieser Normalisierung.

Ein Zeichen anders interpretiert – komplette Signatur falsch.

Korrigiert, Testknopf gedrückt: funktioniert.

Welches Detail es genau war, behalte ich hier für mich. Ein bisschen Werkstattgeheimnis darf schließlich bleiben.

Zur Methode

Interessant war für mich bei diesem Projekt auch die Arbeitsweise.

Ich habe die Umsetzung mit mehreren KI-Assistenten entwickelt und geprüft. Einer half beim Aufbau und bei der Umsetzung, ein zweiter bekam anschließend eher die Rolle des skeptischen Gegenlesers.

Also nicht: „KI, bau mir das mal.“

Sondern eher: Lösung entwickeln, prüfen lassen, Schwachstellen suchen, Dokumentation vergleichen, testen.

Dabei kamen tatsächlich noch zwei sinnvolle Verbesserungen beim Umgang mit den Zugangsdaten heraus, bevor überhaupt der erste echte Test lief.

Beim eigentlichen Fehler half dann allerdings keine schlaue Vermutung, sondern nur das, was bei Schnittstellenproblemen fast immer hilft: zurück zur Originaldokumentation und Zeichen für Zeichen vergleichen.

Diese Kombination gefällt mir inzwischen ziemlich gut. KI ist dabei Werkzeug und Sparringspartner – entscheiden und testen muss am Ende trotzdem jemand.

Ergebnis

Die Integration läuft inzwischen live mit dem neuen signierten Verfahren.

Für den Besucher hat sich dabei exakt nichts geändert – und das ist in diesem Fall das beste Ergebnis.

Verfügbarkeiten, Preise und Buchungsmöglichkeiten erscheinen weiterhin wie vorher. Im Hintergrund läuft jetzt lediglich die neue Authentifizierung.

Während der Umstellung blieb das alte Verfahren als Rückfallmöglichkeit erhalten. Der Testmechanismus bleibt ebenfalls bestehen, falls sich an der Schnittstelle später noch einmal etwas ändert.

Das Ganze konnte innerhalb des Übergangszeitraums umgesetzt und getestet werden, ohne dass die produktive Website dabei auch nur kurz ausfiel.

Und genau das ist für mich eigentlich der interessante Teil an solchen Arbeiten.

Nicht die Kryptografie.

Sondern dass mitten im laufenden Betrieb eine geschäftskritische Schnittstelle ihr Schloss austauscht – und der Besucher davon überhaupt nichts merkt.