Api key van 3e partij (mis/ge)bruiken

[Marco1994]

Mijn vraag
Voor mijn stageopdracht moet ik een app bouwen welke wat gegevens van een sporthorloge ophaalt. Om een situatie te schetsen zal ik beschrijven wat de stappen zijn hoe het horloge synced met de website. Je start op het sporthorloge een exercise, na het sporten stop je deze. Vervolgens sync je het sporthorloge met de website en kun je mooie grafiekjes zien. De bedoeling is een stuk of honderd parameters op te zoeken en deze naar een eigen database pompen zodat hier statistieken en analyses over uitgevoerd kunnen worden.

Het probleem WAS echter dat ze geen publieke api hebben. Na wat netwerksniffing ben ik erachter gekomen dat ze vanuit de app een api aanspreken en in de url hun api key meesturen. Toen dacht ik hé wat handig, een paar uur later had ik alle data die nodig was. Na contact op te hebben genomen met het bedrijf wat de horloges aanbied willen ze me geen api key verschaffen.

Mijn vraag is nu, mag ik op deze manier verder, is het legaal, illigaal of grijs gebied om deze api key te (mis/ge)bruiken?

[EngineerCoding]

Ik ben verre van een jurist op dit gebied, echter lijkt het mij geen best practise om te doen. Dit baseer ik puur op het feit dat je eigenlijk handmatig je API key zou moeten opgeven mocht je de website willen gebruiken voor je eigen data analyse en klinkt niet heel gebruiksvriendelijk. Stel dat het puur je eigen data is, voorzie ik geen problemen. Maar wanneer de website echt publiekelijk live gaat, denk ik dat je in een grijs gebied bevindt.
Staat hier heel misschien iets over in de algemene voorwaarden van het product?

Overigens ben ik er vanuit gegaan dat elk horloge zijn eigen key heeft, wat beveiligingstechnisch logisch zou zijn. Anders kan het malafide problemen opleveren gok ik zo.

[Marco1994]

EngineerCoding schreef op donderdag 16 februari 2017 @ 07:58:
Ik ben verre van een jurist op dit gebied, echter lijkt het mij geen best practise om te doen. Dit baseer ik puur op het feit dat je eigenlijk handmatig je API key zou moeten opgeven mocht je de website willen gebruiken voor je eigen data analyse en klinkt niet heel gebruiksvriendelijk. Stel dat het puur je eigen data is, voorzie ik geen problemen. Maar wanneer de website echt publiekelijk live gaat, denk ik dat je in een grijs gebied bevindt.
Staat hier heel misschien iets over in de algemene voorwaarden van het product?

Overigens ben ik er vanuit gegaan dat elk horloge zijn eigen key heeft, wat beveiligingstechnisch logisch zou zijn. Anders kan het malafide problemen opleveren gok ik zo.

Ik kan over de specifieke use case niet te diep ingaan helaas. De website zal echter niet publiekelijk zijn. Ik zie op de website van de fabrikant hier niets van terug aangezien ze de api niet publiekelijk aanbieden.

Overigens een leuk feitje, ik kan via de api op basis van een email adres en userkey alle gegevens opvragen die er beschikbaar zijn, van hartslag tot tijden wanneer ze sporten...

[ Voor 8% gewijzigd door Marco1994 op 16-02-2017 08:03 ]

[Montaner]

Marco1994 schreef op donderdag 16 februari 2017 @ 08:01:
[...]

Ik kan over de specifieke use case niet te diep ingaan helaas. De website zal echter niet publiekelijk zijn. Ik zie op de website van de fabrikant hier niets van terug aangezien ze de api niet publiekelijk aanbieden.

Overigens een leuk feitje, ik kan via de api op basis van een email adres en userkey alle gegevens opvragen die er beschikbaar zijn, van hartslag tot tijden wanneer ze sporten...

Dat gaat richting een datalek denk ik dan... misschien een melding van maken? Terwijl je dan wel jezelf in je voet schiet...maar goed; wil jij dat een andere ontwikkelaar jouw gegevens zo tevoorschijn haalt?

[Marco1994]

Montaner schreef op donderdag 16 februari 2017 @ 08:08:
[...]

Dat gaat richting een datalek denk ik dan... misschien een melding van maken? Terwijl je dan wel jezelf in je voet schiet...maar goed; wil jij dat een andere ontwikkelaar jouw gegevens zo tevoorschijn haalt?

Dat is ons uiteindelijke plan ook inderdaad, het is precies wat je zegt, je schiet jezelf in je voet. Ik wou echter eerst informatie vergaren of dit legal wise mag.

[Sebazzz]

Het lijkt mij sowieso een datalek. Als jij de api calls kan afluisteren betekent het dat die niet over HTTPS gaan of dat het HTTPS certificaat niet gevalideerd wordt.

[Marco1994]

Het lijkt me vrij logisch dat het hier gaat om een datalek, heb ik hier een meldplicht in?
Overigens is het zo als ik via die api voor de eerste keer gegevens van een gebruiker probeer op te halen, krijgt deze een melding of die toegang wil verschaffen aan deze site. 9/10 gebruikers zal hier gewoon op ja klikken

[ Voor 55% gewijzigd door Marco1994 op 16-02-2017 08:17 ]

[emnich]

Het is gewoon strafbaar onder Art 138ab Strafrecht.

Je gebruikt een valse sleutel in de zin dat je een key gebruikt die niet aan jou gegeven is voor de toegang maar die je 'gevonden' hebt. Je behoort geen toegang te hebben tot dat systeem en je verschaft je nu toch toegang mbv die valse sleutel.

[Marco1994]

emnich schreef op donderdag 16 februari 2017 @ 08:21:
Het is gewoon strafbaar onder Art 138ab Strafrecht.

Je gebruikt een valse sleutel in de zin dat je een key gebruikt die niet aan jou gegeven is voor de toegang maar die je 'gevonden' hebt. Je behoort geen toegang te hebben tot dat systeem en je verschaft je nu toch toegang mbv die valse sleutel.

Helder

[CurtPoindexter]

-

[ Voor 100% gewijzigd door CurtPoindexter op 19-10-2019 04:14 . Reden: Leeg ivm privacy ]

[laurens0619]

Waarom is dit een datalek?
Je kunt bij je eigen gegevens of bij de gegevens van een ander als je hun email adres + userkey hebt of als ze expliciet toegang geven via een site (?)

[kwaakvaak_v2]

CurtPoindexter schreef op donderdag 16 februari 2017 @ 12:57:
Maar het datalek zou ik melden bij AP en bij de fabrikant.

Melden bij AP heeft alleen nut als het een site is die in NL gevestigd is.

[Marco1994]

laurens0619 schreef op donderdag 16 februari 2017 @ 14:35:
Waarom is dit een datalek?
Je kunt bij je eigen gegevens of bij de gegevens van een ander als je hun email adres + userkey hebt of als ze expliciet toegang geven via een site (?)

Als jij zon horloge hebt kan ik zien wanneer je bijvoorbeeld rent, op gps positie waar je rent en hoe snel je gaat, je hartslag, etc.

[laurens0619]

Marco1994 schreef op donderdag 16 februari 2017 @ 17:11:
[...]

Als jij zon horloge hebt kan ik zien wanneer je bijvoorbeeld rent, op gps positie waar je rent en hoe snel je gaat, je hartslag, etc.

Hmm das niet zo mooi, welke gegevens heb je nodig van mij om dat te kunnen zien?

[tim-405]

laurens0619 schreef op donderdag 16 februari 2017 @ 18:28:
[...]


Hmm das niet zo mooi, welke gegevens heb je nodig van mij om dat te kunnen zien?

Marco1994 schreef op donderdag 16 februari 2017 @ 08:01:
[...]

Ik kan over de specifieke use case niet te diep ingaan helaas. De website zal echter niet publiekelijk zijn. Ik zie op de website van de fabrikant hier niets van terug aangezien ze de api niet publiekelijk aanbieden.

Overigens een leuk feitje, ik kan via de api op basis van een email adres en userkey alle gegevens opvragen die er beschikbaar zijn, van hartslag tot tijden wanneer ze sporten...

[laurens0619]

tim-405 schreef op donderdag 16 februari 2017 @ 19:10:
[...]


[...]

Ja precies, maar ik wil eerst eens weten wat die "user key" dan is.
Ik bedoel, nu interpreteer ik user-key als een wachtwoord (of sterker nog, certificaat).

Als dat zo is dan is het niet echt een data lek. Als ik jouw credentials heb (en je geen 2 factor ingeschakeld hebt) kan ik bij al je email door gebruik te maken van de "mail api". Is dat dan ook ene data lek?

Maar voor ik op de feiten vooruit loop, eerst maar eens horen wat die user key is

[ Voor 15% gewijzigd door laurens0619 op 16-02-2017 21:16 ]

[Gomez12]

emnich schreef op donderdag 16 februari 2017 @ 08:21:
Het is gewoon strafbaar onder Art 138ab Strafrecht.

Je gebruikt een valse sleutel in de zin dat je een key gebruikt die niet aan jou gegeven is voor de toegang maar die je 'gevonden' hebt. Je behoort geen toegang te hebben tot dat systeem en je verschaft je nu toch toegang mbv die valse sleutel.

Is het wel zo zwart-wit? Is een parameter in een url voldoende om te classificeren als "sleutel", moet het niet sterker zijn?

Want met deze interpretatie pleeg je dus al bijna computervredebreuk als je een url aanpast. En elke corporate proxy en internet filter etc die pikt dus een herbruikbare sleutel mee.

Ik vind het wel een extreem ruime interpretatie die verregaande gevolgen heeft als je die lijn doortrekt.

Ik verwacht voor een sleutel toch eerder een challenge response of minimaal https oid.

laurens0619 schreef op donderdag 16 februari 2017 @ 21:15:
[...]
Ja precies, maar ik wil eerst eens weten wat die "user key" dan is.
Ik bedoel, nu interpreteer ik user-key als een wachtwoord (of sterker nog, certificaat).

Als dat zo is dan is het niet echt een data lek. Als ik jouw credentials heb (en je geen 2 factor ingeschakeld hebt) kan ik bij al je email door gebruik te maken van de "mail api". Is dat dan ook ene data lek?

Maar voor ik op de feiten vooruit loop, eerst maar eens horen wat die user key is

Tja, ik interpreteer die user key eerder als een vaste key die gewoon in elk device anders is en waarvoor je dus eerst het device moet sniffen of via een proxy de url's loggen.

En dan vind ik het een twijfelachtig iets, want deels vind ik het geen beveiliging, maar aan de andere kant vind ik het ook niet echt een groot datalek, want je hebt bijna wel fysieke toegang tot het device nodig, het is niet alsof je remote iets kan doen.

[Glashelder]

emnich schreef op donderdag 16 februari 2017 @ 08:21:
Het is gewoon strafbaar onder Art 138ab Strafrecht.

Je gebruikt een valse sleutel in de zin dat je een key gebruikt die niet aan jou gegeven is voor de toegang maar die je 'gevonden' hebt. Je behoort geen toegang te hebben tot dat systeem en je verschaft je nu toch toegang mbv die valse sleutel.

Het gaat toch wel heel ver om een API key die verstrekt is door de derde partij en die gekoppeld is aan een account en device die jou toebehoren als een 'valse' sleutel te bestempelen.

Ik ben ook geen jurist maar volgens mij werkt het niet zo .

Sterker nog, wat de TS doet zou bestempeld kunnen worden als het reverse engineeren van een applicatie dat interoperabiliteit als doel heeft. En reverse engineeren is in dat geval toegestaan. Zolang de TS het alleen maar bij gegevens houdt die uitsluitend bij zijn account horen.

[ Voor 19% gewijzigd door Glashelder op 16-02-2017 22:06 ]

[Rukapul]

Hergebruik van een API key is waarschijnlijk onrechtmatig. Het erbij halen van het strafrecht is iets verder gezocht, maar zou kunnen.

Voor bovenstaande geldt geen vereiste dat zo'n sleutel een bepaald kenmerk moet hebben of op een bepaalde (veilige) manier gebruikt moet worden.

Het is geen datalek als er een userkey benodigt is om informatie op te vragen. Kern van de zaak is immers om een specifieke app instance te koppelen aan een bepaald account en toegang te geven tot die data. Er is meer nodig om het een datalek te maken, specifiek iets waardoor de userkey omzeilt, geraden of anderzins verkregen kan worden.

[emnich]

Gomez12 schreef op donderdag 16 februari 2017 @ 21:44:
[...]

Is het wel zo zwart-wit? Is een parameter in een url voldoende om te classificeren als "sleutel", moet het niet sterker zijn?

Want met deze interpretatie pleeg je dus al bijna computervredebreuk als je een url aanpast. En elke corporate proxy en internet filter etc die pikt dus een herbruikbare sleutel mee.

Ik vind het wel een extreem ruime interpretatie die verregaande gevolgen heeft als je die lijn doortrekt.

Ik verwacht voor een sleutel toch eerder een challenge response of minimaal https oid.

Het is nooit zwart/wit bij juridische kwesties dus het hangt af van de details. Het aanpassen van een url kan wel degelijk computervredebreuk zijn. Bijvoorbeeld als ik in mijn medisch dossier de url aanpas van patient_id=123 naar patient_id=124. De mate van beveiliging maakt daarbij niet uit.

Net als dat het niet uitmaakt of ik het slot van jouw huis kan openmaken met een paperclip of daar 6 gecertificeerde sleutels voor nodig heb.

Glashelder schreef op donderdag 16 februari 2017 @ 22:01:
[...]

Het gaat toch wel heel ver om een API key die verstrekt is door de derde partij en die gekoppeld is aan een account en device die jou toebehoren als een 'valse' sleutel te bestempelen.

Ik ben ook geen jurist maar volgens mij werkt het niet zo .

De sleutel is gegeven aan het device niet aan de gebruiker. Door de sleutel van het device te gebruiken, doe je je voor als dat device en daarmee is het een valse sleutel.

Glashelder schreef op donderdag 16 februari 2017 @ 22:01:
[...]
Sterker nog, wat de TS doet zou bestempeld kunnen worden als het reverse engineeren van een applicatie dat interoperabiliteit als doel heeft. En reverse engineeren is in dat geval toegestaan. Zolang de TS het alleen maar bij gegevens houdt die uitsluitend bij zijn account horen.

Reverse enginering gaat over auteursrecht en dat speelt hier niet. Het gaat er om of hij toegang tot die server mag hebben.

[ Voor 14% gewijzigd door emnich op 16-02-2017 22:25 ]

[laurens0619]

We weten niets van die user key, die kan prima via een challenge-response of https verkregen zijn. Sterker nog het is aannemelijk dat je op de app de eerste keer inlogt via bv credentials en er daarna een sessie token wordt bewaard (wat dus user key kan zijn). De link met url parameters snap ik niet, was de user key een url parameter?

Sniff je verkeer maar eens naar bv gmail, zal je zien dat je "slechts" door een sessieId uit een cookie ingelogd bent. Is dat dan een datalek?

Toegegeven daar helpt https in maar grote kans dat de api van de ts ook https gebruikt, is met de nodige truuken prima te sniffen.

Het is pas een datalek als je dm door de gesniftte api bij meer gegevens kan dan je bij zou mogen kunnen (bv via de app). dit lijkt nu niet het geval, je kunt alleen de data opvragen van de kngelogde gebruiker.

Een voorbeeld van wanneer dit wel een datalek zou kunnen zijn is bv wat tijd geleden bij de efteling app is gebeurd. Iemand had die app zitten sniffen en kwam erachter dat voor basic info de app een api gebruikte die veel meer data aanbood. De app filterde dat echter dus in de app zag je niets teveel. Direct met de api echter zat je opeens in het halve backend van de efteling....

[ Voor 38% gewijzigd door laurens0619 op 16-02-2017 22:44 ]

[Gomez12]

emnich schreef op donderdag 16 februari 2017 @ 22:10:
[...]

Het is nooit zwart/wit bij juridische kwesties dus het hangt af van de details. Het aanpassen van een url kan wel degelijk computervredebreuk zijn. Bijvoorbeeld als ik in mijn medisch dossier de url aanpas van patient_id=123 naar patient_id=124. De mate van beveiliging maakt daarbij niet uit.

Ik blijf het een extreem ruime interpretatie vinden die jij hanteert en ik betwijfel of die ergens houdbaar is.
Jij negeert namelijk 1 dingetje wat Arnoud wel noemt, hij zegt dat je een verkeerde intentie moet hebben.

En dat is imho een redelijk kansloos dingetje imho, want zolang jij zegt dat je geen verkeerde intentie hebt is het omgekeerde zo goed als niet te bewijzen.
Maar ik begrijp (denk ik) wel waarom Arnoud dat vermeld, anders wordt het wel een heel makkelijk te misbruiken wet, want dan berust het enkel op de site-beheerder die random kan bepalen of jij de wet overtreed of niet.
Wil je een concurrent in de problemen brengen dan hoef je enkel maar hem een anoniem mailtje te sturen met een link naar patient_id=124 en als hij daarop klikt kan jij hem aanklagen voor computervredebreuk.

Dat is niet echt hoe we de wet in NL willen hebben zeg maar.

Net als dat het niet uitmaakt of ik het slot van jouw huis kan openmaken met een paperclip of daar 6 gecertificeerde sleutels voor nodig heb.

Huis is privé-terrein, dat is appels met peren vergelijken. Beter zou je het kunnen vergelijken met een openbare ruimte (bijv een winkel) waar 10 deuren zijn, 9 mag je gewoon openen alleen bij deur nr 10 zou je huisvredebreuk plegen, dan geldt dat enkel als er iets aangegeven is dat het niet mag of als de deur afgesloten is oid, als het niet anders is als de andere 9 deuren is het geen huisvredebreuk hoor.

[Gomez12]

laurens0619 schreef op donderdag 16 februari 2017 @ 22:37:
Sniff je verkeer maar eens naar bv gmail, zal je zien dat je "slechts" door een sessieId uit een cookie ingelogd bent. Is dat dan een datalek?

Ehm, nee zo werkt gmail niet... Daar zit toch echt wel iets meer achter hoor.
Mail jij die sessieId en/of cookie maar eens door naar je werk en probeer hem daar maar eens werkbaar te maken. Aan die sessie-id hangen server-side wel redelijk wat fingerprinting kenmerken die op een andere computer veelal anders zijn.

Toegegeven daar helpt https in maar grote kans dat de api van de ts ook https gebruikt, is met de nodige truuken prima te sniffen.

Interessant, heb je daar wellicht wat linkjes oid voor. Want in principe is https bij een correcte implementatie aan beide zijden niet te sniffen.
Je kan rustig miljoenen/miljarden verdienen als je het tegendeel kan bewijzen. Dus ik zou zeggen maak je woord maar eens waar.

Het is pas een datalek als je dm door de gesniftte api bij meer gegevens kan dan je bij zou mogen kunnen (bv via de app). dit lijkt nu niet het geval, je kunt alleen de data opvragen van de kngelogde gebruiker.

Ehm, het feit dat je bij meer info kan komen dan onder je eigen mailadres is al meer info dan je zou mogen hebben. Wat er hier wordt gesuggereerd (even afhankelijk van of je het beveiliging noemt of niet) is nu net het schoolvoorbeeld van een data lek. Je kan bij data waar je niet bij mag komen (namelijk die van iemand anders)

Een voorbeeld van wanneer dit wel een datalek zou kunnen zijn is bv wat tijd geleden bij de efteling app is gebeurd. Iemand had die app zitten sniffen en kwam erachter dat voor basic info de app een api gebruikte die veel meer data aanbood. De app filterde dat echter dus in de app zag je niets teveel. Direct met de api echter zat je opeens in het halve backend van de efteling....

Efteling was veel meer als enkel een datalek...
Wat jij nu doet is het doodknuppelen van een persoon noemen als voorbeeld voor lichte mishandeling. Ja, het is ook lichte mishandeling, maar ook zware en ook gelijk moord.

[emnich]

@Gomez12: zoals ik al zei, het is nooit zwart wit. Intentie wordt volgens mij niet genoemd door Arnoud, wel dat je zou moeten weten dat je ergens niet mag komen.

Dat lijkt me in deze zaak het geval. Ts kon de gegevens niet verkrijgen maar door zich voor te doen als een device opeens wel.

Ik verwacht niet dat het OM tot vervolging over zou gaan in deze zaak maar strikt genomen lijkt het mij toch echt computer vrede breuk.

[laurens0619]

Gomez12 schreef op donderdag 16 februari 2017 @ 23:03:
[...]

Ehm, nee zo werkt gmail niet... Daar zit toch echt wel iets meer achter hoor.
Mail jij die sessieId en/of cookie maar eens door naar je werk en probeer hem daar maar eens werkbaar te maken. Aan die sessie-id hangen server-side wel redelijk wat fingerprinting kenmerken die op een andere computer veelal anders zijn.


[...]

Interessant, heb je daar wellicht wat linkjes oid voor. Want in principe is https bij een correcte implementatie aan beide zijden niet te sniffen.
Je kan rustig miljoenen/miljarden verdienen als je het tegendeel kan bewijzen. Dus ik zou zeggen maak je woord maar eens waar.


[...]

Ehm, het feit dat je bij meer info kan komen dan onder je eigen mailadres is al meer info dan je zou mogen hebben. Wat er hier wordt gesuggereerd (even afhankelijk van of je het beveiliging noemt of niet) is nu net het schoolvoorbeeld van een data lek. Je kan bij data waar je niet bij mag komen (namelijk die van iemand anders)


[...]

Efteling was veel meer als enkel een datalek...
Wat jij nu doet is het doodknuppelen van een persoon noemen als voorbeeld voor lichte mishandeling. Ja, het is ook lichte mishandeling, maar ook zware en ook gelijk moord.

Ik denk dat mijn punt niet overkomt gmail zal vast nog wat extra zaken doen maar ging mij meer om hoe authentication/sessies in de praktijk werkt en wat je op een lijn ziet. Google maar eens op sessiom hijacking (gmail) en je zal zien dat t allemaal niet zo spannend is. Het is ook geen groot probleem omdat je door https het sessie/cookie niet zomaar kunt inderscheppen. Maar dat was het punt niet, het punt was dat een device kan comuniceren dmv een code/token wat eerder dmv credentials is verkregen. Dat heeft meer te maken dat http stateless is en het conceptueel zo werkt.

Ik schrijf nergens dat ssl lek is, ik schrijf dat de api van de ts waarsch ook https was en hij dat heeft kunnen sniffen. Dat is echt niet speciaal als je controle hebt over endpoint en apps veelal nog geen cert pinning hanteren.


Ik heb nog steeds nergens gelezen dat je bij data kan waar je niet bij mag komen. Ik lees tot nu toe alleen dat je bij data kan komen van je eigen profiel.
Maar dat verschil zit hem erin dat we nog steeds niet weten of er een probleem in de user-key zit en je makkelijk kunt inloggen als een ander.
Zolang dat er niet is zie ik geen datalek probleem slechts omdat de api "zichtbaar" is. (Wat de feiten voor nu zijn)

[ Voor 15% gewijzigd door laurens0619 op 17-02-2017 02:55 ]

[Anoniem: 172410]

emnich schreef op donderdag 16 februari 2017 @ 22:10:
Het is nooit zwart/wit bij juridische kwesties dus het hangt af van de details. Het aanpassen van een url kan wel degelijk computervredebreuk zijn. Bijvoorbeeld als ik in mijn medisch dossier de url aanpas van patient_id=123 naar patient_id=124. De mate van beveiliging maakt daarbij niet uit.

Dat kan je pas beweren als hier jurisprudentie van te vinden is en die lijkt er niet te zijn. Dat is ook niet gek, want Nederlandse rechters zullen hierbij ook naar billijkheid en proportionaliteit kijken.

[emnich]

Anoniem: 172410 schreef op vrijdag 17 februari 2017 @ 03:03:
[...]

Dat kan je pas beweren als hier jurisprudentie van te vinden is en die lijkt er niet te zijn. Dat is ook niet gek, want Nederlandse rechters zullen hierbij ook naar billijkheid en proportionaliteit kijken.

Volgens mij had ik het niet genuanceerder kunnen stellen met 'het hangt af van de details' en ' het kan'. De andere mogelijkheden zijn dat het nooit computervredebreuk is of het altijd wel is. Dat lijkt me, gezien de wettekst, beide onmogelijk te stellen.

[Marco1994]

Okay, een hoop berichten. Om de userkey te verduidelijken: Ik weet nu wel vrij zeker dat het een datalek is, http://urlvanapi.com/priv...ey=keyvanapi&userkey=xxxx ga krijg ik zijn email adres. Ik kan dus een sloot aan cijfers loopen en dan krijg ik het bijhorende emailadres. Een userkey ziet er als volgt uit(althans de mijne en een paar andere) 123456789

[Rukapul]

Marco1994 schreef op vrijdag 17 februari 2017 @ 08:35:
Okay, een hoop berichten. Om de userkey te verduidelijken: Ik weet nu wel vrij zeker dat het een datalek is, http://urlvanapi.com/priv...ey=keyvanapi&userkey=xxxx ga krijg ik zijn email adres. Ik kan dus een sloot aan cijfers loopen en dan krijg ik het bijhorende emailadres. Een userkey ziet er als volgt uit(althans de mijne en een paar andere) 123456789

De userkey voldoet dus niet aan de eisen van een (geheime, niet raadbare, niet voorspelbare) sleutel. Blijkbaar is het geimplementeerd als eenvoudige identifier.

De userkey met de aangegeven lengte heeft per definitie te weinig entropie.

Nu kun je ook nog wat leren van responsible disclosure... mits je (bedrijf) het risico wil nemen ontdekt te worden als onrechtmatig gebruiker van de API. Leuk dilemma

[laurens0619]

Marco1994 schreef op vrijdag 17 februari 2017 @ 08:35:
Okay, een hoop berichten. Om de userkey te verduidelijken: Ik weet nu wel vrij zeker dat het een datalek is, http://urlvanapi.com/priv...ey=keyvanapi&userkey=xxxx ga krijg ik zijn email adres. Ik kan dus een sloot aan cijfers loopen en dan krijg ik het bijhorende emailadres. Een userkey ziet er als volgt uit(althans de mijne en een paar andere) 123456789

Ai dat is lelijk en lijkt idd op een beveilingslek. Als je die key+email hebt, kun je dan meteen data ophalen? Of was er nog een popup die de (ingelogde?) gebruiker moet approven.

Either way lijkt het op een slechte implementatie en zou ik dit melden aan de eigenaar van api.

[Marco1994]

Rukapul schreef op vrijdag 17 februari 2017 @ 08:56:
[...]

De userkey voldoet dus niet aan de eisen van een (geheime, niet raadbare, niet voorspelbare) sleutel. Blijkbaar is het geimplementeerd als eenvoudige identifier.

De userkey met de aangegeven lengte heeft per definitie te weinig entropie.

Nu kun je ook nog wat leren van responsible disclosure... mits je (bedrijf) het risico wil nemen ontdekt te worden als onrechtmatig gebruiker van de API. Leuk dilemma

Ik ben nu onderweg naar de klant om het voor te leggen, ik ben maar de stagiair. Mijn voorstel gaat zijn om naar de 3e partij te stappen en alles voor te leggen, in ruil hiervoor wordt het op prijs gesteld als we een eige rechtmatige api key krijgen.

[Marco1994]

laurens0619 schreef op vrijdag 17 februari 2017 @ 09:01:
[...]


Ai dat is lelijk en lijkt idd op een beveilingslek. Als je die key+email hebt, kun je dan meteen data ophalen? Of was er nog een popup die de (ingelogde?) gebruiker moet approven.

Either way lijkt het op een slechte implementatie en zou ik dit melden aan de eigenaar van api.

Als ik jouw key+email gebruik krijg je inderdaad eerst een popup, echter is deze zo generiek dat je heb waarschijnlijk wel accepteert. Het is iets als: "wilt u toegang verschaffen tot uw account"

[Rukapul]

Marco1994 schreef op vrijdag 17 februari 2017 @ 09:01:
[...]

Ik ben nu onderweg naar de klant om het voor te leggen, ik ben maar de stagiair. Mijn voorstel gaat zijn om naar de 3e partij te stappen en alles voor te leggen, in ruil hiervoor wordt het op prijs gesteld als we een eige rechtmatige api key krijgen.

Een ruil past niet bij responsible disclosure.

Er zijn zelfs casussen waar dit als afpersing wordt beschouwd.

[Marco1994]

Rukapul schreef op vrijdag 17 februari 2017 @ 09:04:
[...]

Een ruil past niet bij responsible disclosure.

Er zijn zelfs casussen waar dit als afpersing wordt beschouwd.

Daarom zeg ik, op prijs worden gesteld

[laurens0619]

Marco1994 schreef op vrijdag 17 februari 2017 @ 09:03:
[...]

Als ik jouw key+email gebruik krijg je inderdaad eerst een popup, echter is deze zo generiek dat je heb waarschijnlijk wel accepteert. Het is iets als: "wilt u toegang verschaffen tot uw account"

Dat is wel lelijk, je zou verwachten dat requestaccess alleen via een geauthenticeerde sessie van dezelfde gebruiker mogelijk zou zijn. Dit klinkt wel lelijk.
Geen enorme security flaw wamt je moet eerst de gebruikers tricken om in te loggen in hun account en te approven maar dat zou moeten lukken dmv social engineering. Maar zeker een kwetsbaarheid die ze zouden moeten oplossen.

Nu ben ik wel nieuwschierig, het klinkt een beetje als de garmin connect api?

[Marco1994]

laurens0619 schreef op vrijdag 17 februari 2017 @ 09:15:
[...]

Dat is wel lelijk, je zou verwachten dat requestaccess alleen via een geauthenticeerde sessie van dezelfde gebruiker mogelijk zou zijn. Dit klinkt wel lelijk.
Geen enorme security flaw wamt je moet eerst de gebruikers tricken om in te loggen in hun account en te approven maar dat zou moeten lukken dmv social engineering. Maar zeker een kwetsbaarheid die ze zouden moeten oplossen.

Nu ben ik wel nieuwschierig, het klinkt een beetje als de garmin connect api?

Je wordt warm, maar helaas geen garmin

[laurens0619]

Misschien idee als je in 1 plaat beschrijft hoe je aanval eruit ziet op het platform. Geeft in dit topic een helder beeld en kun je gebruiken voor het gesprek met de leverancier.

[Marco1994]

laurens0619 schreef op vrijdag 17 februari 2017 @ 09:35:
Misschien idee als je in 1 plaat beschrijft hoe je aanval eruit ziet op het platform. Geeft in dit topic een helder beeld en kun je gebruiken voor het gesprek met de leverancier.

Ik denk dat dat een beetje overkill is, het is allemaal geen hogere wiskunde, door het netwerk te sniffen krijg ik de url van hun api en een key. Dan kan ik dmv een userkey(zie verhaal een paar posts terug) en een email al jouw gegevens zien

[Gomez12]

Marco1994 schreef op vrijdag 17 februari 2017 @ 09:01:
[...]

Ik ben nu onderweg naar de klant om het voor te leggen, ik ben maar de stagiair. Mijn voorstel gaat zijn om naar de 3e partij te stappen en alles voor te leggen, in ruil hiervoor wordt het op prijs gesteld als we een eige rechtmatige api key krijgen.

Ik zou dan wel de klant adviseren om ook een zak geld mee te nemen.

Dit klinkt niet echt als een foutje in de beveiliging. Maar simpelweg als een slecht uitgedachte/opgezette beveiliging.
Het nadeel van het 2e is dat de directie waarschijnlijk denkt dat het veilig is, daar hebben ze immers om gevraagd. Terwijl bij de techniek de kennis ontbreekt om het veilig op te zetten.

Het nadeel hiervan is dat je en de directie en de techniek moet overtuigen dat het niet veilig is, dat ze dan ook nog alletwee met de billen bloot moeten tegenover jou.
In de praktijk praat het een stuk makkelijker als de interne techniek ook kan zien waar de fout zit en het kan bevestigen tegenover de directie.

En een aai-key zou ik dan ook niet direct ter sprake brengen, maar pas als hun echt doordrongen zijn van het feit dat hun opzet foutief is.

[Hydra]

Marco1994 schreef op vrijdag 17 februari 2017 @ 08:35:
Okay, een hoop berichten. Om de userkey te verduidelijken: Ik weet nu wel vrij zeker dat het een datalek is, http://urlvanapi.com/priv...ey=keyvanapi&userkey=xxxx ga krijg ik zijn email adres. Ik kan dus een sloot aan cijfers loopen en dan krijg ik het bijhorende emailadres. Een userkey ziet er als volgt uit(althans de mijne en een paar andere) 123456789

Yup. Da's een enumeration attack.

In onze API maakt een mobiele applicatie verbinding met een soort 'gatekeeper' proxy die een device specifiek ID vertaalt naar een user-ID. Deze user ID wordt dan als header meegestuurd naar de services hierachter. Zowel de device ID als user IDs zijn UUIDs en dus onmogelijk te raden.

[ Voor 19% gewijzigd door Hydra op 17-02-2017 10:23 ]