Mag ik de API achter een app zelf aanroepen?

Een lezer vroeg me:

De app van mijn bank is leuk en aardig, maar ik wil eigenlijk bepaalde kerncijfers in mijn thuisdashboard getoond hebben. Technisch kom ik daar wel uit, maar mag ik die API aanroepen voor mezelf? Het is in principe dezelfde informatie heen en weer als de app zou doen, maar ik doe het niet op de officiële manier. Krijg ik dan problemen?

Zuiver juridisch gezien zie ik hier geen probleem mee. Als je gerechtigd bent een API aan te roepen, dan is het niet strafbaar of onrechtmatig om die aan te roepen. Je gaat hier dus niet voor de cel in, en de bank zal ook geen schadeclaim kunnen indienen.

Als je rare trucs gaat toepassen om de API dingen te laten doen die niet de bedoeling zijn, dan kan dat anders liggen. Informatie opvragen waar je eigenlijk niet bijhoort, mag je niet zomaar doen. In theorie is dat computervredebreuk.

Praktisch gezien kun je er wel problemen mee krijgen, in ieder geval één simpele: als de bank jouw aanroepen ziet als misbruik of bedreiging, dan blokkeren ze die. Dat zal al snel betekenen dat je ook via de officiële app niet meer bij je bankgegevens kunt of overboekingen kunt doen, en dat lijkt me erg vervelend voor een consument. Want zonder internetbankieren je bankzaken doen is een hele uitdaging tegenwoordig.

Ik zou dit dus alleen doen als de bank het goedvindt, of als je zeker weet dat de aanroepen niet te onderscheiden zijn van ‘echte’ aanroepen.

Arnoud

26 reacties

  1. Dan vraag ik me vervolgens af hoe je er achter kunt komen of de bank dit goed vindt. Bellen of mailen met de helpdesk? Grote kans dat je iemand aan de lijn krijgt die geen flets idee heeft waar je het over hebt.

  2. Ach, de banken moeten toch binnenkort open API’s aanbieden (dankzij PSD2), dus waarom niet even wachten. De meeste banken houden nu al (open) hackathons, waarbij je hun API’s als eerste kan gebruiken, dus het lijkt me slimmer om daar aan mee te doen. Het voorkomt een hoop discussie en je krijgt nog support, (hopelijk goede) documentatie etc.

    P.S. Mocht iemand al aan de gang willen gaan met Ulster, RBS of BNP Paribas, kijk dan eens op https://openbankproject.com

  3. Dit specifieke probleem is binnenkort ook opgelost — vanwege PSD2 (Second Payment Services Directive) zijn banken binnenkort (ik meen 2018) verplicht een API open te stellen aan derden. Een aantal banken doet dat al (bv. Bunq, Monzo).

    1. Ik hoopte dat ik op basis van de Bunq API een desktop client zou kunnen maken: ik houd niet zo van smart phones, en vooralsnog is Bunq als “smart phone rekening” niet zo interessant voor mij. Nu hun API is gepubliceerd vraag ik me af of dit wel goed te doen is. Het lijkt gemaakt te zijn voor “server-to-server”, dus misschien moet ik een server opzetten waar mijn desktop-client mee kan verbinden. Een beetje omslachtig, lijkt me.

  4. Ik krijg een beetje jeuk van de term “dingen die niet de bedoeling zijn”. Bedoelingen zijn nogal subjectief: de één zijn bedoelingen zijn heel anders dan die van de ander. Wiens bedoelingen zijn bepalend, en waarom? Het gevaar bestaat dat deze term veel te breed wordt uitgelegd, waardoor je ongewenste toestanden krijgt, bijvoorbeeld dat mensen geen upgrades/reparaties op apparaten mogen uitvoeren omdat dat niet de “bedoeling” is van de fabrikant.

    Natuurlijk zijn er dingen die je niet zou moeten mogen doen, zoals het bekijken van andermans saldo-informatie, of het doen van transacties vanaf andermans rekening. Ik verwacht dat er gewoon wetten zijn die jou verbieden dat soort dingen te doen. Idealiter voorkomt de bank dit al server-side, zodat je er gewoonweg niet toe in staat bent, zelfs al reverse-engineer je de API, maar mocht de bank daar een steekje laten vallen, dan zou je het alsnog niet mogen. In het ideale geval heeft de bank een goed responsible disclosure beleid, zodat je zulke veiligheidslekken op een voor jou veilige manier kunt melden; hopelijk krijgen we in de toekomst wetgeving die bescherming van een “white hat hacker” garandeert, zelfs als bedrijven geen goed responsible disclosure beleid hebben (ik heb er nog geen vertrouwen in dat dat nu al goed is geregeld).

    Maar, zolang je niet op illegale manier anderen schade berokkent, met name als je alleen dingen doet die je via de bank-app ook al kan, zoals je eigen saldo-informatie bekijken en overschrijvingen van je eigen rekening doen, zie ik niet wat er mis mee is. Natuurlijk, als de bank het verschil met hun app kan detecteren zouden ze je kunnen blokkeren, maar ik zou dat zelf erg onredelijk vinden. Mochten ze het als een veiligheids-risico zien, dan zou ik het veel redelijker vinden als hun development-team gewoon contact met je opneemt om je code te bestuderen, en suggesties voor aanpassingen te doen. Voor een groot deel is beveiliging daarbij een gemeenschappelijk belang, dus er zou op vrijwillige basis wel een constructieve samenwerking mogelijk moeten zijn.

    1. Toch ben ik het niet helemaal met je eens. Wat nu als jij een handige tool bouwt die elke seconde je rekening informatie ophaalt en bij een wijziging je een email/sms/… stuurt.

      Als je dat tooltje vervolgens publiceert dan krijgt de bank te maken met een enorme vloed aan calls naar hun API.

      De “bedoeling” is juist wat onze maatschappij leefbaar houdt. Zo ga je niet met een zak chips in de Mediamarkt met je vrienden een film kijken. Hoewel je niets anders doet dan iemand die even komt kijken naar welk beeld het beste is, is het toch niet de “bedoeling”….

      1. Ja maar dan kun je die bedoeling toch expliciteren? Het gaat mis wanneer ‘de bedoeling’ als vage term in de specificatie opgenomen is: we vinden alles best zolang we het goed vinden, maar zo niet, dan niet. Helder.

        Wil je een stortvloed aan API calls voorkomen, dan zijn daar technische mogelijkheden voor. Veel web API’s gebruiken een key waarmee je toegang krijgt. Dan kun je bijvoorbeeld zeggen dat je per key 1000 calls per dag toelaat, of zo.

        1. Iemand zal er in eerste instantie geen rekening mee houden dat dit gebeurt. Ze bieden een app aan en geen API. Vervolgens word het ze kwalijk genomen dat er geen duidelijke limiet staat op het gebruik van de API.

          Als je iets gaat gebruiken wat niet aangeboden wordt, voldoet “de bedoeling” prima.

          1. Maar dan is het ook duidelijk toch? Dan zeg je gewoon expliciet dat het niet de bedoeling is om de API te gebruiken, en dat elk gebruik kan resulteren in afsluiting.

            Ik snap je punt wel. De maatschappij kent een hoop ongeschreven regels waardoor je zonder al teveel gedoe met elkaar om kunt gaan zonder elke keer de letter der wet erbij te halen. Het wordt echter gevaarlijk als “de bedoeling” juridische consequenties kan hebben. Dan wil ik liever dat expliciet wordt beschreven wat mag en niet mag.

  5. Één van de voordelen van cryptocurrencies zoals Bitcoin is dat je niemands toestemming nodig hebt om er toepassingen bovenop te bouwen. Alles is open source, dus je hoeft geen API te reverse-engineeren. Er is niemand die jouw toepassing blokkeert; mocht je lokale overheid Bitcoin-communicatie blokkeren, dan is dat snel opgelost met een VPN, of TOR of iets dergelijks (is tot nu toe niet nodig).

    Het is wel eens gebeurd dat mensen toepassingen ontwikkelden bovenop cryptocurrencies en dat, zodra het een beetje populair werd, ze ook meer dan welkom waren om de zelfde toepassing bij banken toe te passen.

      1. Het kan eigenlijke allebei. De bank zal zelf een private key willen hebben voor de generieke encryptie van de gegevens naar de bank. De app bevat dan de publieke key. Dit kan in principe al SSL zijn maar normaal zou je bij SSL eerst de public key opvragen bij de server en bij een bank-app zou die stap overgeslagen kunnen worden zodat je oudere versies van de app simpel kunt uitschakelen door de bijbehorende private key uit te schakelen. De App vraagt geen key op dus kan de app niet verder omdat de key ongeldig is geworden. Via deze encryptie kun je de complete communicatie dus mee beveiligen.

        Maar er kan natuurlijk ook een private key gebruikt worden binnen de App, die bij registratie van de app een public key naar de server verstuurt. Deze private key binnen de app dient dan als een digitale handtekening en kan eventueel met een specifieke hardware ID worden “gesalt” om de handtekening nog veiliger te maken. Die hardware ID dient dan bij de registratie van de app doorgegeven te worden en maakt de gehele encryptie en digitale handtekening nog lastiger om te hacken.

        Maar goed, een digitale handtekening is pas echt belangrijk als je geld gaat overmaken. Voor het inzien van de bankgegevens hoeft de beveiliging niet zo sterk te zijn, hoewel deze nog wel stevig moet zijn. Meestal is gebruikersnaam en wachtwoord voldoende om je bankgegevens te bekijken maar heb je een tancode of identifier nodig om opdrachten te versturen. De API zou in principe dus al bruikbaar zijn met alleen de public key voor de communicatie-beveiliging. (Maar die is dan niet via de server op te vragen maar is ingesloten in de App!)

  6. Ik denk dat de strafrechter dit niet anders zal beoordelen dan een SQL injectie en dat het dus als een strafbare computervredebreuk zal worden gezien. Daar komt dan nog bij dat die API ongetwijfeld zal vereisen dat er een code of andere authenticatie doorgegeven moet worden, die alleen bedoeld is om door de app gebruikt te worden en daarmee heeft te gelden als het gebruik van een niet aan deze gebruiker uitgegeven code.

    1. Ik zie de gelijkenis met SQL injectie niet. Daarvoor moet je misbruik maken van een kwetsbaarheid in de code waardoor je dingen voor elkaar krijgt die buiten de API vallen. Bijvoorbeeld in plaats van GetBalance(“Steven”), GetBalance(“Steven; UPDATE account SET balance = 1000000 WHERE firstname = ‘Steven’; –“) waardoor je ineens rijk bent (tenzij je 10M op de bank had, dan ben je ineens 9M lichter 😉 )

      Het gaat hier om normaal gebruik van de API maar door een andere applicatie dan de door de uitgever ontwikkelde app.

    1. Als de API goed gemaakt is zou deze geen toegang mogen geven tot gegevens van derden. Echter weten we ook dat een API een foutje kan bevatten. Als je er geen misbruik van maakt en problemen redelijk vlot (probeert te) melden verwacht ik niet dat je gauw problemen zult krijgen bij veel banken.

      Stel je krijgt toegang tot de bankrekening van een ander, met het overmaken van 1x 1 cent kun je al bewijzen dat je dat kunt. De schade is in dat geval minimaal.

      1. Met het daadwerkelijk overmaken van geld (zelfs 1 cent) van iemand anders ga je al veel te ver. Alleen het feit dat je toegang hebt tot een andere rekening is al voldoende om een melding te maken.

        Als je het wil testen kan je dat natuurlijk wel doen met de rekening van een vriend of bekende, mits je daar vooraf toestemming voor vraagt.

      2. Da’s dus een speculatieve situatie waarin de API een fout bevat, en je gaat die fout benutten om iets onrechtmatigs te doen. En misbruik was altijd al onrechtmatig, ongeacht of je dat via de API doet. Het aanroepen van de API (dat was de oorspronkelijke vraag) is niet ineens onrechtmatig geworden.

    2. Zelfs als een API goed in elkaar is gezet is het nog steeds mogelijk dat er misbruik van gemaakt kan worden. Er zijn veel boekhoudpakketten waar je een koppeling in kunt maken met je bankrekening. Ik heb daarbij pakketten gezien die letterlijk vragen om je inloggegevens om te onthouden zodat ze automatisch je bankgegevens kunnen ophalen. Moet ik even aangeven hoe riskant dat kan zijn? Vooral als het pakket zelf gehackt kan worden??

      Hackers zullen gaan voor de zwakste schakel in ieder systeem. Om die reden moet de beveiliging van de bank goed op orde zijn. Maar als derden via deze API’s applicaties kunnen ontwikkelen om bankzaken mee te regelen dan worden die applicaties al snel de zwakste schakel. en dan kan er al snel veel fout gaan…

      Voor de meest simpele vormen van misbruik hoef je niet eens geld op te kunnen nemen. Je kunt een PayPal account openen op naam van iemand anders en PayPal valideert je bankrekening vervolgens door twee kleine bedragen te storten op je rekening. Die twee kleine bedragen vormen de beveiligingscode voor PayPal en als je die vervolgens doorgeeft kun je via PayPal veel geld gaan opnemen voordat men het bedrog door heeft.

      Maar er zijn ook enkele webwinkels waar je kunt bestellen door de webwinkel een machtiging te geven om een bepaald bedrag van je bankrekening te halen. Daar heb je maar weinig informatie voor nodig, namelijk een naam en rekeningnummer. Je zou dus bij dergelijke sites bestellingen kunnen doen en de goederen doorsturen naar een katvanger en dan maar afwachten tot de site merkt dat de machtiging niet werkt en men het geld gaat eisen van de katvanger.

      Maar goed, je wil sowieso niet dat derden inzage krijgen in je bankgegevens. Dergelijke informatie is enorm privacygevoelig. En ja, je kunt van een API gebruik maken om je eigen gegevens in te zien, maar veel mensen zullen met een dergelijke API aan de slag gaan om hun werk uiteindelijk te delen met anderen die het ook een handig hulpmiddel vinden. En dan gaat het dus al snel fout…

      1. Als ik het goed begrijp beschrijf je een mogelijkheid waarbij iemand een nuttige App maakt, die stiekum onder water via de Api bij de inloggevens komt, om vervolgens Paypal- accounts of bestellingen uit te voeren. Tsja, dat was altijd al onrechtmatig.

        Is dit nu een argument om rechtmatig gebruik van de Api (inloggen-gegevens opvragen) te verbieden? Dus: “Onze Api slaat zeer onveilig inloggegevens op omdat dat voor ons zo makkelijk is, maar u maakt er misschien misbruik van (wij niet) en daarom is het voor u verboden de API aan te roepen” Klinkt … niet heel erg steekhoudend.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.