Afgelopen februari is PSD2, de nieuwe Europese richtlijn voor het betalingsverkeer, van kracht geworden. PSD2 biedt rekeninghouders de mogelijkheid om derde partijen, zogenaamde third party providers (TPP's), toegang te geven tot de betaalrekening bij hun bank. Banken zijn verplicht hieraan mee te werken door verschillende diensten aan derden aan te bieden zoals het opvragen van account-informatie en het initialiseren van betalingen. Voor banken en TPP’s betekent PSD2 dat ze hun processen en infrastructuur moeten aanpassen. Dit brengt echter naast de nodige performance-uitdagingen voor beide partijen ook security-risico’s met zich mee. Gelukkig is het niet lastig om beveiligingsmaatregelen tegen dergelijke risico’s te nemen. Lees hier welke risico's dit zijn en check de tips om te zorgen dat je als TPP deze risico’s elimineert.
Lees in dit artikel mijn 5 adviezen voor third party providers om de security issues bij PSD2 te elimineren.
Matthijs Melissen, Security Specialist bij Computest
Access delegation kan zorgen voor kwetsbare infrastructuur
Neem als voorbeeld een rekeninghouder die via een TPP gegevens wil opvragen van zijn bank. Daarvoor vinden de volgende stappen plaats:
- De rekeninghouder verzoekt een TPP om informatie
- De TPP stuurt de rekeninghouder door naar de bank
- De rekeninghouder logt in bij de bank
- De rekeninghouder geeft de bank toestemming om zijn gegevens te delen
- De bank stuurt de rekeninghouder terug naar een endpoint bij de TPP en geeft hierbij een toegangscode mee
- De TPP legt contact met de bank via een API om rekeninggegevens op te vragen, en autoriseert zich hierbij met zijn toegangscode
Dit proces is niet nieuw en staat bekend als ‘access delegation’. Banken kunnen dit proces zelf implementeren, maar kunnen ook bestaande protocollen gebruiken voor access delegation, zoals het OAuth 2.0-protocol. Access delegation is al gemeengoed in andere sectoren, zoals in het onderwijs en bij sociale netwerken. Daar is echter gebleken dat het ook serieuze beveiligingsrisico’s met zich mee kan brengen. Kleine fouten bij de implementatie van access delegation kunnen grote gevolgen hebben. Om dit te voorkomen adviseer ik TPP's de onderstaande 5 tips na te leven om te zorgen dat de security bij de implementatie en het gebruik van access delegation voor PSD2 gewaarborgd blijft.
5 security-tips voor third party providers bij implementatie PSD2
1) Valideer en escape data van de bank
Als third party provider ben je misschien geneigd de data van de bank te vertrouwen. Je hebt die data immers via een beveiligd communicatiekanaal verkregen. Dat wil echter nog niet zeggen dat de data te vertrouwen is. Wie weet heeft een rekeninghouder wel HTML-codes gebruikt in de naam van een bankrekening. Of wat gebeurt er als een rekeninghouder de tekst '; DROP TABLES;-- gebruikt in de omschrijving van zijn overschrijving, is dan je database weg? De boodschap is duidelijk: beschouw alle informatie komende vanaf de bank als onvertrouwde gebruikersinvoer en pas dezelfde validatie- en escape-technieken toe als voor andere gebruikersinvoer.
2) Definieer een specifieke redirect-URL
In de meeste gevallen moet je als TPP je endpoint registreren bij de bank, zodat deze weet naar welke pagina's de gebruiker mag worden doorgestuurd. Het is belangrijk om hier een zo specifiek mogelijke URL te registreren. Registreer je bijvoorbeeld je hele domein als toegestane redirect-URL, dan heb je het risico dat toegangscodes worden doorgestuurd naar pagina's die hier niet voor bedoeld zijn. Dit zorgt voor security-risico’s. Bevat je domein ergens een redirect naar een extern domein? Dan zou een aanvaller deze redirect kunnen gebruiken om toegangscodes naar dat externe domein door te sturen.
3) Maak van je endpoint een redirect
De inhoud van de endpoint is ook van belang. Staat er op de endpoint externe content, zoals afbeeldingen of links naar externe sites? Dan bestaat het risico dat toegangscodes meegestuurd worden in Referer-headers. De externe partij kan zo in het bezit komen van toegangscodes. Daarom is het slim om van de endpoint ook weer een redirect te maken.
4) Bescherm je endpoint tegen cross-site request forgery
Op het moment dat een bank toestemming heeft verleend om gegevens van een rekeninghouder met een TPP te delen, stuurt de bank de rekeninghouder door naar de endpoint van de TPP. Wat gebeurt er echter als een kwaadwillende rekeninghouder deze link doorstuurt naar een andere rekeninghouder, en die andere rekeninghouder klikt hierop? De TPP zal dan misschien het TPP-account van de tweede rekeninghouder koppelen aan de bankrekening van de kwaadwillende rekeninghouder. Dat is natuurlijk niet de bedoeling. Zo'n aanval staat ook wel bekend als cross-site request forgery (CSRF). De gebruikelijke verdedigingsmechanismen tegen CSRF moeten ook hier worden ingebouwd: genereer een random token, koppel deze aan de sessie van de gebruiker, stuur het token mee naar de bank (bijvoorbeeld in de OAuth 2.0-state), en controleer als de bank een response terug stuurt of het token hoort bij de huidige sessie.
5) Gebruik authorization tokens niet als identiteitscontrole
Wanneer je als TPP een rekeninghouder doorstuurt naar de bank, en je ontvangt vervolgens een geldig token terug, dan neem je al aan dat het token hoort bij de rekeninghouder die op dat moment ingelogd is. Het OAuth 2.0-protocol biedt die garantie echter niet. Het token geeft je toestemming om de gegevens van een bepaalde rekeninghouder in te zien, maar je hebt niet de garantie dat die rekeninghouder dezelfde persoon is als de rekeninghouder die nu bij jou is ingelogd. Je kunt namelijk aangevallen worden door een andere TPP. Zo kan een andere TPP die samenspant met een van jouw klanten, de toegangscodes die hij heeft ontvangen van een van zijn eigen klanten aan jou kunnen doorsturen om zich voor te doen als die klant. De reden dat dit vaak werkt, is dat toegangscodes niet altijd vermelden voor welke TPP ze bedoeld zijn. Een verdediging hiertegen is dan ook dat banken in de toegangscodes specifiek opnemen voor welke TPP deze bedoeld is. Een protocol als OpenID Connect doet dit standaard al, en is daarom een goede oplossing tegen deze aanval.
Tip: Lees ook de 5 security-tips voor banken bij de implementatie van access delegation voor PSD2 >>
Controle en advies PSD-implementatie door Security Specialist
De meeste beveiligingsrisico’s bij de implementatie van access delegation voor PSD2 zijn gelukkig eenvoudig te voorkomen. Wil jij zeker weten of bij jouw organisatie PSD2 op een veilige wijze geïmplementeerd is? Of ben je juist nog in de beginfase van PSD2-implementatie en wil je zorgen dat er al vroeg in het ontwikkelproces aandacht is voor beveiliging?
Wij bieden nu voor TPP's een PSD2-beveiligingsconsult aan. We komen graag bij je langs voor een consult op maat. Meer weten? Lees meer over een PSD2-beveiligingsconsult of neem contact op met Team Finance.
Over de auteur
Matthijs Melissen is werkzaam als Security Specialist bij Computest in Team Finance. De beveiliging van access delegation protocols zoals OAuth 2.0 heeft zijn bijzondere interesse. Matthijs heeft onder andere ervaring met het beveiligen van access delegation protocollen in het onderwijs.
