Ondergrens API beveiliging: key in url acceptabel?

[Yucon]

Ik worstel een beetje met een situatie die ik bij klant tegengekomen ben. Het werk dat ik doe zou je het beste als consultant op het gebied van data management kunnen omschrijven. Niet hardcore tech in ieder geval, maar het schuurt wel een beetje tegen die richting aan. Lang geleden ben ik web developer geweest dus ik ben wel een beetje bekend met die materie en men verwacht ook dat ik wat algemene ondersteuning op IT gebied lever.

Er wordt data ontsloten via een API vanuit een symfony backend. Mijn vraag gaat over de beveiliging, want er wordt gebruik gemaakt van een API key die via een parameter in de url doorgegeven wordt. Dus iets als https://www.dezesite.nl/api/v1/producten?apikey=kkdsflgkdf#%$#534AAA4534

De meeste API's waar ik de laatste tijd mee heb gewerkt werken met OAuth2. Een enkeling gebruikt een vaste API key maar dan wel in ieder geval nog in de headers zodat je ze niet in logfiles en history ziet. De variant die het in de url stopt heb ik al heel erg lang niet meer gezien. Dit volgt ook niet de symfony best practices en ik krijg ook een erg ongemakkelijk gevoel van deze constructie.

Maar hoe erg is dit nu concreet? Het doel van dit topic is niet dat ik mijn gelijk wil halen. Eerder het tegenovergestelde.. Ik zoek eigenlijk juist naar een soort verzachtende omstandigheden om zo te kunnen bepalen of ik misschien te kritisch ben.

Google maakt me niet veel wijzer. Ik kom wel die best practices tegen waarbij het in symfony 2.x al niet meer zo hoorde, en verder kom ik vooral resultaten tegen hoe het wel zou moeten. Wat vinden jullie? Zou het een 2, een 5 of een 6- zijn als je het in een rapportcijfer uit zou moeten drukken?

[Juup]

Hangt nogal af van de data die er opgehaald wordt.
Een paar plaatjes? => Niet zo erg.
Zeer geheime data? => Zeer erg.

[Yucon]

Juup schreef op zondag 21 juli 2024 @ 19:48:
Hangt nogal af van de data die er opgehaald wordt.
Een paar plaatjes? => Niet zo erg.
Zeer geheime data? => Zeer erg.

De data op zichzelf is niet zo heel geheim. Ik maak me er meer zorgen over of dit tekenend is voor de rest, want ik kan me heel moeilijk voorstellen dat iemand die wist wat hij doet dit een goed idee vond toen het gebouwd werd. Met dezelfde moeite stop je het in de headers en dat is weer net een slag veiliger.. dus waarom dan in de url?

Maar ik sta ervoor open dat ik dat laatste misschien verkeerd zou kunnen zien.

[orf]

Juup schreef op zondag 21 juli 2024 @ 19:48:
Hangt nogal af van de data die er opgehaald wordt.
Een paar plaatjes? => Niet zo erg.
Zeer geheime data? => Zeer erg.

Precies dit. Ik heb vroeger wel eens gezien dat een postcode-API met een key in de url werkte. Die API had dan ook nog een whitelisting op IP. Dan vind ik het niet zo boeiend. Maar als het bijvoorbeeld om persoonsgegevens gaat: dan is het zeker een probleem.

[Haan]

Het verdient misschien niet de schoonheidsprijs, maar het is ook weer niet heel fout imo. Server logs zou ik me niet heel druk om maken, met de aanname dat er 1 partij is die de api keys beheert en de server runt. Als dit is uitbesteed bij een derde partij heb je wel een potentieel probleem.

[remco_k]

Juup schreef op zondag 21 juli 2024 @ 19:48:
Hangt nogal af van de data die er opgehaald wordt.
Een paar plaatjes? => Niet zo erg.
Zeer geheime data? => Zeer erg.

We zitten op Tweakers, dus: waarom?

[Haan]

OWASP heeft er een pagina aan gewijd, dat geeft wel een mooi overzicht van potentiele risico's: https://owasp.org/www-com...ough_query_strings_in_url

Zoals gezegd is het grootste probleem dat de querystring gelogd wordt in server logs en eventuele proxies (we hebben het hier over een api, dus ik sluit browser history voor het gemak even uit). Of dit een probleem is, is niet te zeggen zonder meer kennis van hoe de infrastructuur in elkaar steekt en welke personen hier toegang toe hebben.

Het is dus wel aan te bevelen om de key in een header mee te geven. Een api key op zichzelf is weinig mis mee als je gewoon een simpele koppeling tussen twee systemen wilt realiseren.

[mikka]

Op kleine schaal zal het niet veel kwaad doen als het algemene informatie ophaalt of zoiets dergelijks. Als het gevoelige informatie is raad ik dit sterk af. Ik weet niet of het mogelijk is maar lukt het niet via headers een authoritative sleutel te sturen?

[Anoniem: 80910]

Bij muziek heb je geen custom header, dus gebruik ik daar een key.

[Umbrah]

Niet alles snapt headers. Heeft de key een scope/referrer server side, een expiration, en losse renewal api? An sich kán token in URI Veilig zijn, maar het is heel erg afhankelijk van de implementatie

[Yucon]

Nee geen expiration. Beheer gaat via een mailtje dat door een mens verstuurd wordt. Volgens mij drukt iemand ergens in een admin portal op een knop om er een te genereren.

Al met al is de heersende mening zo te zien dat het er net mee door kan. Dat was het soort indicatie dat ik nodig had. Bedankt allemaal!

[ Voor 18% gewijzigd door Yucon op 24-07-2024 20:06 ]

[RobIII]

Anoniem: 80910 schreef op woensdag 24 juli 2024 @ 19:16:
Bij muziek heb je geen custom header

Wat bedoel je daar mee? Élk HTTP request (en respons) heeft headers (en dus ook de mogelijkheid tot custom headers).

[dfijma]

Het grote probleem is inderdaad dat de API-key in logs en caches blijft plakken. Zelfs als je de log als redelijk vertrouwelijk beschouwd kan dat problematisch zijn. Als eenvoudige replay van het request (gevoelige) persoonsgegevens levert, dan ben je feitelijk indirect die gevoelige gegevens aan het loggen, wat mogelijk een onrechtmatige verwerking is in het kader van de AVG.

En waarom zou je het NIET in een header doen, ik zie weinig tot geen scenarios voor een API waarin dat geen werkbaar alternatief is. En dat dan nog even los van dat er uberhaupt betere alternatieven zijn op een onveranderlijke API-key (op zijn minst een gesigned token met een beperkte geldigheidsduur op basis van een API-key)

[Anoniem: 80910]

RobIII schreef op woensdag 24 juli 2024 @ 20:21:
[...]

Wat bedoel je daar mee? Élk HTTP request (en respons) heeft headers (en dus ook de mogelijkheid tot custom headers).

Bij de audio tag is een custum header, zoals een bearer token, momenteel nog niet mogelijk

[ThomasG]

Anoniem: 80910 schreef op donderdag 25 juli 2024 @ 08:53:
[...]

Bij de audio tag is een custum header, zoals een bearer token, momenteel nog niet mogelijk

Maar daarvoor gebruik je geen API-sleutel in een URL. De server die de HTML-pagina weergeeft, genereert een tijdelijke sleutel die geldig is voor die URL met een maximale tijdsduur. De server die het verzoek naar deze URL ontvangt, kan deze sleutel vervolgens verifiëren. Als het klopt, krijg je de inhoud terug; zo niet, een foutmelding. De sleutel in die URL is uniek per URL en per verzoek. Een statische API-sleutel hoort nooit in een URL. Dat gebeurde 10-20 jaar geleden, vooral met legacy software. Tegenwoordig is dat simpelweg not done.

[Yucon]

dfijma schreef op woensdag 24 juli 2024 @ 20:31:
En waarom zou je het NIET in een header doen, ik zie weinig tot geen scenarios voor een API waarin dat geen werkbaar alternatief is. En dat dan nog even los van dat er uberhaupt betere alternatieven zijn op een onveranderlijke API-key (op zijn minst een gesigned token met een beperkte geldigheidsduur op basis van een API-key)

Dit is precies m'n probleem ermee. Ik kan heel moeilijk een echt goed voordeel bedenken om het zo te doen, dus het komt op me over als ofwel luiheid cq desintresse, ofwel onwetendheid.

En als iemand dit ok vindt, wat vindt hij dan nog meer ok dat ik niet gezien heb?

[Janoz]

Anoniem: 80910 schreef op donderdag 25 juli 2024 @ 08:53:
[...]

Bij de audio tag is een custum header, zoals een bearer token, momenteel nog niet mogelijk

Zelfde geld natuurlijk voor een image tag, maar in die situaties kun je beter een cookie gebruiken.

[CAPSLOCK2000]

Yucon schreef op zondag 21 juli 2024 @ 19:41:
De variant die het in de url stopt heb ik al heel erg lang niet meer gezien. Dit volgt ook niet de symfony best practices en ik krijg ook een erg ongemakkelijk gevoel van deze constructie.

Maar hoe erg is dit nu concreet? Het doel van dit topic is niet dat ik mijn gelijk wil halen. Eerder het tegenovergestelde.. Ik zoek eigenlijk juist naar een soort verzachtende omstandigheden om zo te kunnen bepalen of ik misschien te kritisch ben.

Google maakt me niet veel wijzer. Ik kom wel die best practices tegen waarbij het in symfony 2.x al niet meer zo hoorde, en verder kom ik vooral resultaten tegen hoe het wel zou moeten. Wat vinden jullie? Zou het een 2, een 5 of een 6- zijn als je het in een rapportcijfer uit zou moeten drukken?

Excuses als ik een open deur in trap:
Volgens mij moet je hier naar je professionele gevoel luisteren. Het gaat er niet om of het in het algemeen een 5 of een 6 is, want dan kan het hier ook een 4 of een 8 zijn. Het gaat hier om de rode waarschuwingsvlaggen zoals afwijken van best practices.

Belangrijk is de vraag of het een bewuste en weloverwogen keuze is of dat er iemand heeft zitten rommelen?
Als iemand kan uitleggen dat er een afweging is gemaakt (inclusief dataveiligheid) en op grond daarvan heeft besloten dat dit de beste keuze is dan zit het waarschijnlijk wel goed. Zo niet dan is er waarschijnlijk meer mis.

Zaken die ik zou meenemen in het gesprek met de klant:
- Wat voor data is het? (persoonsgegevens -> dpia?)
- Hoe lang is de key geldig? (Kort, lang, oneindig)
- Is het voor eenmalig gebruik of vaker?
- Zijn er aanvullende maatregelen om het risico te verkleinen? (bv ratelimiter tegen brute force)
- Is de keuze gedocumenteerd?

Terzijde: Ik baseer dit allemaal op het afwijken van best practices, maar er is natuurlijk niks mis met afwijken van best practices als je dat kan uitleggen. Beste practices blind volgen is ook niet goed. Wie nooit afwijkt heeft waarschijnlijk nooit goed nagedacht over het nut en doel van de best practices. Omgekeerd is "Je moet x doen want het is best practice" een erg zwak argument, dan weet je nog niks. Ik probeer dus te voorkomen dat ik mensen aanval op het wel of niet volgen van best practices alsof dat een doel op zich is.

[drm]

Het probleem is inderdaad deels of datgene dat met die URL ontsloten wordt gevoelige data is (al een aantal keer genoemd), maar belangrijker is nog: waar kan de token nog meer voor gebruikt worden?

Mijn ervaring is dat over het algemeen nog al losjes wordt omgesprongen met tokens en wat voor privileges daar allemaal achter zitten, dus het is sowieso een big-ass red flag als er tokens in URL's staan. Ook al verloopt de token (snel), en is de data die met die URL ontsloten wordt niet gevoelig, de kans is heel groot dat met die token nog heel veel meer schade aangericht kan worden dan alleen een plaatje ophalen.

M.a.w., tokens in URLs gebruiken is een major red flag, tenzij echt gegarandeerd kan worden dat er met die token niks anders gedaan kan worden dan die URL ophalen. Ik geef je op een briefje dat als je al twijfels hebt bij de security awareness van e.e.a., dat dat zeker niet het geval is.

edit:

Mijn devies zou dus altijd zijn: Een token is private, dus nee, een key in een url is nooit acceptabel, ook al zijn er scenario's te bedenken waarin het wel acceptabel is; de garanties die je in die scenario's moet kunnen geven (en continueren) leggen in de praktijk te veel druk op auditing en development.

[ Voor 14% gewijzigd door drm op 31-07-2024 17:59 ]

[CrazyFool]

Ben het met jullie allemaal eens, maar puur uit interesse hoe oud is dit product/api?

Want er is ooit een tijdperk geweest waar het mee sturen van de api key als GET parameter vrij normaal was (voor simpele api’s).

Uit de leeftijd van de api kun je al voorzichtig conclusies trekken. Jonger dan 2012… Dan hadden ze op z’n minst oauth 2.0 moeten introduceren. Ouder… oauth 1.0 was een pain in the *as en dan kan ik die sleutel nog wel ergens begrijpen.

Ouder of Jonger dan 2012, en nog steeds api sleutel? Hard rennen )

[drm]

Want er is ooit een tijdperk geweest waar het mee sturen van de api key als GET parameter vrij normaal was.

Mja, wat "normaal" was en veilig zijn wel echt twee heel verschillende dingen. Er is ook een tijdperk geweest waarin we vrolijk vrijwel alles (inclusief shell sessions naar een server; telnet anyone?) onversleuteld over het internet verstuurden.

[Mavamaarten]

Een API key kan potentieel ook voor andere doeleinden dienen dan het identificeren van een gebruiker. Het kan ook dienen om een bepaald type gebruiker of systeem te identificeren en op basis daarvan een andere respons te genereren. Op die manier is de "API key" een soort lookup key voor een set aan parameters, en kan het geen kwaad om deze als query param door te geven. In andere gevallen is het ... op zijn minst questionable.