Signeren van gegevens in de browser, hoe?

[alienfruit]

Mijn vraag
Ik wil graag onderzoeken of het mogelijk is om een content te signeren in de browser op zo'n manier dat een keys zo min mogelijk beschikbaar zijn in de browser. Ik heb namelijk een webapplicatie waar ik gegevens wil delen met een andere applicatie middels een GET url. Alleen nu wil ik de query parameters graag signeren om er zekerder op te zijn dat ze niet aangepast.

Ik heb bijv. een URL https://app.nl?data1=blah&data2=bloh&data3=bleh nu dat ik misschien kan ik de url signeren en vervolgens de signatuur toevoegen dus dan zou het worden: https://app.nl?data1=blah...data3=bleh&signature=code

De webapplicatie op het domein app.nl moet vervolgens de signature controleren en als deze niet klopt of mist moeten ze de gegevens in de url negeren.

Nu lijkt mij het een goed idee om hiervoor dus HMAC voor te gebruiken genereren alleen dan zou de sleutel te lezen zijn in de broncode van de webapplicatie. Zijn er technieken om dit toch mogelijk te maken?

Of moet gaan werken met een POST request die de te delen inkomende data en deze request vervolgens een gesigneerde url terugstuurt wat vervolgens gebruikt kan worden in een link..


Relevante software en hardware die ik gebruik
Ik maak gebruik van de moderne browsers (Edge, Edge vintage, Firefox, Safari) en IE11, en Node.js

Wat ik al gevonden of geprobeerd heb
Ik heb gezocht naar hoe signeren urls werkt maar hier blijkt HMAC toch wel de standaard als je gebruik maakt van APIs. Maar ik kon niet veel informatie vinden hoe je gewoon webpagina links zou kunnen signeren zodat de andere partij kan verifiëren dat er niet mee gerommeld is.

[RobIII]

alienfruit schreef op maandag 1 februari 2021 @ 16:39:
Nu lijkt mij het een goed idee om hiervoor dus HMAC voor te gebruiken genereren alleen dan zou de sleutel te lezen zijn in de broncode van de webapplicatie

Dat zie ik even niet; je kunt die link toch server-side genereren en signen? Ja, je zult je key ergens moeten opslaan (in je config of ergens in een vault ofzo), maar dat wil toch niet zeggen dat je clients je key kunnen zien?

[alienfruit]

Ja, het liefst wel, maar dat lijkt mij niet een goed idee. Daarom ook mij andere voorstel om gebruik te maken van een POST request die link genereert die volgens kan worden gebruikt.

Het idee om enkele gegevens van onze applicatie te delen met app.nl. Nu kunnen we wel gewoon de query string gebruiken om de ingelogde gebruikers id over de lijn te gooien. Maar we willen app.nl enige zekerheid geven dat deze niet zijn aangepast en daarom willen we de link signeren.

[Voor 44% gewijzigd door alienfruit op 01-02-2021 16:54]

[RobIII]

alienfruit schreef op maandag 1 februari 2021 @ 16:51:
Daarom ook mij andere voorstel om gebruik te maken van een POST request die link genereert die volgens kan worden gebruikt.

Ik zie niet wat een POST request oplost of hoe dat überhaupt relevant is? Je zult nog steeds je key ergens vandaan moeten halen? En dus (server-side) moeten opslaan ergens En het is zaak dat die key never-ever-nooit bij de client terecht komt. Dus moet je server die link signen.

M.a.w.: Je zult 't signen hoe dan ook server-side moeten doen (want je wil je key geheim houden).

alienfruit schreef op maandag 1 februari 2021 @ 16:51:
Het idee om enkele gegevens van onze applicatie te delen met app.nl. Nu kunnen we wel gewoon de query string gebruiken om de ingelogde gebruikers id over de lijn te gooien. Maar we willen app.nl enige zekerheid geven dat deze niet zijn aangepast en daarom willen we de link signeren.

Bedoel je niet gewoon een JWT token?

[Voor 47% gewijzigd door RobIII op 01-02-2021 17:04]

[alienfruit]

[
Ik zie niet wat een POST request oplost of hoe dat überhaupt relevant is? Je zult nog steeds je key ergens vandaan moeten halen? En dus (server-side) moeten opslaan ergens

Ja klopt, dat gebeurd ook, er worden verschillende sleutels in Google Secret Manager opgeslagen. Momenteel voor server-side en één de browser.

Bedoel je niet gewoon een JWT token?

Nee, volgens mij niet.

Als voorbeeld neem een accountantspakket, de gebruiker van dit pakket, kan op een scherm zijn voor bepaalde klant, of factuur. Vervolgens willen we een knop aanbieden naar app.nl met de huidige geselecteerde factuur of klant, zodat men de overige informatie over deze factuur en/of klant kunnen inzien. Nu is de URL van app.nl de benodigde query parameters voor de factuur id of klant id bekent.

Nu is de wens om gegeneerde URL te signeren. Nu hebben willen wij iets vergelijkbaars doen, nu kan ik de URL signeren door de factuur of klant id via een POST request naar de server te sturen en vervolgens de teruggestuurde URL te gebruiken als men op de knop drukt. Nu vroeg mij af of zoiets ook mogelijk is zonder de POST request of dat dit de beste methode is. Of is het bovenstaande in zijn geheel niet redelijk veilig te krijgen?

[Voor 19% gewijzigd door alienfruit op 01-02-2021 17:07]

[RobIII]

alienfruit schreef op maandag 1 februari 2021 @ 17:04:
Nu is de wens om gegeneerde URL te signeren.

Ja, maar ik denk dat we langs elkaar praten.
Het signen van de URL zal server-side moeten gebeuren - hoe dan ook. Het is levensgevaarlijk om de key, op welke manier dan ook, bij de client bekend te maken. Als die key bekend wordt kan iedereen die 'm heeft (onderschept, afgetapt, MitM'ed, phished, whatever) dus dingen gaan signen. En dat wil je niet.

Je kunt een key per user of een enkele key of whatever gebruiken - dat is in 't verhaal niet (heel) relevant (hoewel een key per user veiliger is dan een enkele, 'universele', key natuurlijk). Either way, wat je wil is een functie die dit doet:

code:

function Sign($data) {
  return HMAC($user->session->key, $data);
}

En ik gebruik nu, in bovenstaand pseudo-code voorbeeld toevallig een key die in een user sessie staat, maar 't had ook een 'universele' ("app")key kunnen zijn uit je config of...

Of je die functie aanroept in je template of middels een AJAX request of whatever, boeie. Zolang je zeker weet dat die functie alleen maar 'veilig' aangeroepen kan worden (je moet bijv. ingelogd zijn) dan ben je er toch?

[Voor 42% gewijzigd door RobIII op 01-02-2021 17:11]

[alienfruit]

Ja, je hebt gelijk. Ik dacht misschien waren methode waar je met halve sleutels kon werken ofzo. Eentje bekend aan de server-side en eentje aan de browser kant. Je hebt een deel dat op de server is versleuteld, dat deel wordt dan samen met de browserdeel gecombineerd. Maar dan blijf je hetzelfde probleem hebben. 🙈

Dank je wel

[Mr. HTTP]

Ken je de OAuth 2.0 spec?

[Voor 5% gewijzigd door Mr. HTTP op 01-02-2021 17:34]

[alienfruit]

Ja, enkele van de OAuth specs maar niet allemaal. Maar al weer een tijd geleden dat ik dat heb doorgespit.

[RagingPenguin]

Je zou ook voor een compleet andere oplossing richting kunnen kiezen en geen singing te gebruiken. Dan zou je bijvoorbeeld in de backend een tabel kunnen maken met de parameters en een uuid. Als iemand een scherm wil delen dan klikken ze op een knop die via een api een record toevoegt aan die tabel en het uuid returned. Vervolgens deel je een link met die uuid (en zonder alle andere parameters). Als er iemand op een gedeelde link klikt kan je ze in de backend vervolgens redirecten naar de waardes uit de databases.

Misschien is dit simpeler, misschien niet, dat hangt er natuurlijk een beetje vanaf waar je mee werkt

[Voor 9% gewijzigd door RagingPenguin op 01-02-2021 19:37]

[alienfruit]

Hmm, dat kan ook een idee zijn daar had ik nog niet over nagedacht

Ja, ik wil een integratie mogelijkheid bieden waarbij applicatie 1 aan context propagation kan doen voor applicatie 2 via mij. Zodat de context (bijv. huidige geselecteerde klantcode) kan worden doorgegeven aan applicatie 2 die vervolgens analyses kan doen voor de informatie relevant voor de gekozen klantcode.

[raptorix]

Regel nummer 1 bij dit soort zaken: Ga dit niet zelf in elkaar hobbyen.
Kijk even naar de post van @Mr. HTTP de meeste talen/frameworks hebben hier gewoon prima ondersteuning voor, dan hou je de boel veilig, leesbaar en scheelt het je ook nog weken werk.

[alienfruit]

Bedoel de Signing Requests hoofdstuk van OAuth 1.0 specificatie? Ik zie namelijk niet in hoe OAuth 2 mij hier gaat helpen behalve het ingewikkelder te maken, door het nodig hebben van een OAuth systeem. Wat weer maanden ipv weken gaat duren.

Ik kwam dit vandaag nog tegen: https://tools.ietf.org/ht...bis-message-signatures-01

[Hydra]

Het probleem is hier dat je client niet secure is. Welke key je ook gebruikt, als de client diegene is die zijn uitput signed, dan kan je door de client te 'kraken' ook aan de key komen en zelf die URLs signen.

Ik denk dat je verder komt als je vertelt wat het echte probleem is achter wat je hier probeert te doen. Als je de client wil kunnen vertrouwen; dat is simpelweg onmogelijk. Dat is dus waarom altijd alle checks in de back-end zitten om te voorkomen dat kwaadwillenden dmv URLs aanpassen bij dingen kunnen waar ze niet bij mogen.

Dus wat probeer je nu precies op te lossen?

[com2,1ghz]

Alle encryptie en decryptie moet serverside gebeuren:
Hier een voorbeeld hoe wij het bij onze klant doen:

• Client logt in op server.
• Server geeft access token terug
• Client wilt resource downloaden
• Server geeft link terug die versleuteld is met de access token
• Client download resource
• Server ontsleutelt versleutelde link en indien valide geeft bestand terug.

Deze aanpak wordt ook gebruikt als oplossing tegen (OWASP)direct object references., waardoor je interne database/technische sleutels niet worden blootgesteld.

Iedere keer dat de server de link versleutelt, krijg je een andere versleuteling, welke wel weer te ontsleutelen is met dezelfde access token. Ook wel symetrische encryptie genoemd.


Eigenlijk wat @Mr. HTTP ook zegt.

[Voor 30% gewijzigd door com2,1ghz op 02-02-2021 08:24]

[BCC]

@alienfruit Kun je niet gewoon serverside een zipfile maken met een one-time password erop, dat opsturen naar de gebruiker en het password mailen/smsen ? Ik denk dat je wat meer moet vertellen over wat je probeert te doen, want er zijn heel veel manieren om dit soort dingen aan te pakken.

[Voor 36% gewijzigd door BCC op 02-02-2021 08:25]

[alienfruit]

Ik wil graag de ontvangende kant van de link (applicatie een mogelijkheid bieden om te controleren dat de query parameters in de link, tussen het generen van de link, en het ontvangen niet is aangepast en dus enige zekerheid kan hebben. Ook zou het mogelijke replay attacks moeilijker moeten maken. Daarom het idee om een signature te gebruiken.

Bijv.
https://mijnapp.nl?custom...76bf382213df354aa702df5b4


Inmiddels hebben we al geconcludeerd dat de link aan de server-side aangemaakt moet worden.

[Voor 22% gewijzigd door alienfruit op 02-02-2021 11:40]

[Mr. HTTP]

alienfruit schreef op dinsdag 2 februari 2021 @ 11:38:
Ik wil graag de ontvangende kant van de link (applicatie een mogelijkheid bieden om te controleren dat de query parameters in de link, tussen het generen van de link, en het ontvangen niet is aangepast en dus enige zekerheid kan hebben. Ook zou het mogelijke replay attacks moeilijker moeten maken. Daarom het idee om een signature te gebruiken.

Dat kan toch prima volgens de aangedragen oplossingen (of delen van die spec) zoals oAuth request signing en JWT.

Bijv.
https://mijnapp.nl?custom...76bf382213df354aa702df5b4

Voor een replay attact afvangen moet je dan de logica van een nonce gebruiken en bijvoorbeeld Redis gebruiken om deze te tellen.
Sowieso qua usability erg lastig als een URL maar 1 keer mag worden bezocht. Of zit daar weer een onveilige redirect achter? Of is het alleen voor writes? (POST, PUT...)

Inmiddels hebben we al geconcludeerd dat de link aan de server-side aangemaakt moet worden.

Dus die "accountant" is ingelogd via een stukje software (web of desktop) en doet bijvoorbeeld een API call. getInvoiceURL() - (dit zit dan achter een knop in een stukje software). Krijgt die URL terug en kan hem vervolgens 1 keer openen in de browser (!?).

Misschien moet je niet zozeer ons overtuigen van jouw bedachte idee of geconstateerde beren op de weg (op basis van dat idee) maar gewoon vertellen wat je wilt bewerkstelligen.

Sowieso zeg ik niet dat je oAuth moet implementeren maar dat je de spec moet begrijpen en WAAROM deze zo is. Met die kennis kan je jouw systeem vervolgens veiliger en logischer opzetten!

[Mr. HTTP]

alienfruit schreef op dinsdag 2 februari 2021 @ 03:11:
Ik kwam dit vandaag nog tegen: https://tools.ietf.org/ht...bis-message-signatures-01

Dit is voor gehele HTTP messages, het is een draft en lijkt meer voor API's te zijn omdat browsers hun eigen saus over elke HTTP request gooien (zoals bijv. de syntax van een boundary parameter op een Content-Type header field in een POST HTTP request voor file uploads of de volgorde waarin header fields worden verstuurd... ). Vandaar ook de aandacht voor Canonicalization in de draft.

[alienfruit]

Dus die "accountant" is ingelogd via een stukje software (web of desktop) en doet bijvoorbeeld een API call. getInvoiceURL() - (dit zit dan achter een knop in een stukje software). Krijgt die URL terug en kan hem vervolgens 1 keer openen in de browser (!?).

Nee, ik wil ontwikkelaars van de URL (applicatie 2) de mogelijkheid bieden te verifiëren dat de link van ons komt en dat er ook niet onderweg mee geklungeld is. En mijn originele vraag was of er een manier was om dit allemaal on browser/client-side te doen ipv server-side.

[Voor 11% gewijzigd door alienfruit op 02-02-2021 12:20]

[Mr. HTTP]

alienfruit schreef op dinsdag 2 februari 2021 @ 12:19:
Nee, ik wil ontwikkelaars van de URL (applicatie 2) de mogelijkheid bieden te verifiëren dat de link van ons komt en dat er ook niet onderweg mee geklungeld is.

Dan werkt een shared private key (tussen jou en een key per developer) + signature op de HTTP request toch prima? Kijk naar de logica van JWT...

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

Maar hoe verloopt die communicatie dan, wordt die URL publieke gedeeldt? Want als het allemaal geautomatiseerde communicatie tussen computers is dan zijn er weer andere oplossingen mogelijk.
Wat is de use-case?

En mijn originele vraag was of er een manier was om dit allemaal on browser/client-side te doen ipv server-side.

Nee dat kan dus niet.

[Voor 11% gewijzigd door Mr. HTTP op 02-02-2021 12:39]

[BCC]

alienfruit schreef op dinsdag 2 februari 2021 @ 12:19:
[...]


Nee, ik wil ontwikkelaars van de URL (applicatie 2) de mogelijkheid bieden te verifiëren dat de link van ons komt en dat er ook niet onderweg mee geklungeld is. En mijn originele vraag was of er een manier was om dit allemaal on browser/client-side te doen ipv server-side.

Dat doe je normaliter via https toch? Eventueel met een client certificaat - dat kan prima in een browser.

[Voor 3% gewijzigd door BCC op 02-02-2021 12:58]

[alienfruit]

Mr. HTTP schreef op dinsdag 2 februari 2021 @ 12:35:
Dan werkt een shared private key (tussen jou en een key per developer) + signature op de HTTP request toch prima? Kijk naar de logica van JWT...

Klopt, je hebt helemaal gelijk. Ik ga voor deze oplossing gezien je andere commentaar qua niet mogelijk in de browser. Ik had stille hoop

Maar hoe verloopt die communicatie dan, wordt die URL publieke gedeeldt? Want als het allemaal geautomatiseerde communicatie tussen computers is dan zijn er weer andere oplossingen mogelijk.

Nou ja, de gebruiker moet wel ingelogd zijn, maar de url zelf wordt wel publieke gedeeld in de browser.

Wat is de use-case?

Neem bijvoorbeeld dit topic, jij wilt de mogelijkheid bieden om een snelknop aan te bieden zodat de moderators snel naar je webapplicatie kunnen linken bijv. via mijn user id (of andere context) wat vervolgens ML-oplossing aanbied voor analyse ofzo. Natuurlijk hoeft het niet user id te zijn, kan van alles zijn. Alleen je webapplicatie wil zeker van zijn dat de gegevens die via de weblink worden verstuurd van Tweakers en niet een nep-Tweakers afkomen.(in echt is wat complexer maar dit is het idee, moet je eerst abonnement op je webapp nemen etc)

Dat doe je normaliter via https toch? Eventueel met een client certificaat - dat kan prima in een browser.

Ja, klopt, voor de server-server communicatie gebruik ik mutual TLS met inderdaad client certificaat.

[Voor 7% gewijzigd door alienfruit op 02-02-2021 13:32]