Hoe elimineer je de security-risico’s van PSD2?

Voor banken en TPP’s betekent PSD2 dat ze hun processen en infrastructuur moeten aanpassen. Dit brengt naast de nodige performance-uitdagingen voor beide partijen ook security-risico’s met zich mee.  Zo elimineer je deze risico’s.  

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.

PSD2 is een Europese richtlijn. Aangezien de richtlijn niet aangeeft hoe deze technisch geïmplementeerd moet worden, ontwikkelt iedere bank een eigen oplossing om te voldoen aan de functionele eisen van PSD2. Op dit moment is de implementatie van PSD2 bij de meeste banken nog in ontwikkeling. Toch kunnen we wel enkele aannames doen over hoe het proces er bij een gemiddelde bank uit zal zien.

Access delegation kan zorgen voor kwetsbare infrastructuur

Neem als voorbeeld een rekeninghouder die via een TTP gegevens wil opvragen van zijn bank. Daarvoor vinden de volgende stappen plaats:

1. De rekeninghouder verzoekt een TPP om informatie

2. De TPP stuurt de rekeninghouder door naar de bank

3. De rekeninghouder logt in bij de bank

4. De rekeninghouder geeft de bank toestemming om zijn gegevens te delen

5. De bank stuurt de rekeninghouder terug naar een endpoint bij de TPP en geeft hierbij een toegangscode mee

6. 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 banken 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 banken bij implementatie PSD2

1. Verstuur geen toegangscodes in URL’s

Om een TPP toegang te verschaffen, zal de bank waarschijnlijk toegangscodes gaan versturen naar de TPP via de rekeninghouder. Een logische manier om deze codes te versturen is ze mee te sturen als parameter in de URL. Dit levert echter al snel risico’s op. URL’s worden namelijk op veel plekken opgeslagen, zoals in de URL-geschiedenis van browsers, of in proxy logs. Dit vergroot het risico dat deze codes uitlekken. Ook kunnen codes uitlekken via de Referer-header. Het is daarom verstandiger om toegangscodes niet als URL parameter, maar in de POST body te versturen.

2. Controleer de waarde van de parameter van de URL

Om een toegangscode te verkrijgen, stuurt de TPP de rekeninghouder door naar een specifieke URL bij de bank. In sommige protocollen, zoals bij OAuth 2.0, kan aan deze URL ook een parameter worden toegevoegd die specificeert naar welke URL bij de TPP de toegangscode moet worden gestuurd. Het is belangrijk om als bank de waarde van deze parameter goed te controleren: de gebruiker mag alleen doorgestuurd worden als deze URL overeenkomt met de URL die door de TPP is geregistreerd. De URL moet overeenkomen qua protocol (http/https), de host, poort en pad. Als deze controle niet wordt uitgevoerd, bestaat het risico dat toegangscodes per abuis worden doorgestuurd naar externe partijen.

3. Sta geen redirects toe naar http-pagina’s

Het is onverstandig om toegangscodes door te sturen over onbeveiligde http-verbindingen. Aanvallers die de verbinding tussen jou en de rekeninghouder uitlezen kunnen hiermee de toegangscodes onderscheppen. Het is daarom aan te raden om geen redirects naar endpoints over het http-protocol toe te staan.

4. Selecteer het juiste grant type bij het gebruik van OAuth 2.0

Wanneer je gebruikmaakt van OAuth 2.0, is het van belang om het goede ‘grant type’ te selecteren. OAuth 2.0 ondersteunt namelijk verschillende grant types, die elk hun eigen werking hebben. Ook brengt ieder van deze types andere beveiligingsrisico’s met zich mee. Daarom is het belangrijk om het grant type ‘authorization grant’ te gebruiken, dit biedt het hoogste beveiligingsniveau.

5. Voorkom open redirects bij het gebruik van OAuth 2.0

Volgens het OAuth 2.0-protocol moet een gebruiker die een onjuiste scope doorgeeft worden doorgestuurd naar een door de gebruiker opgegeven URL. Wanneer de OAuth 2.0-specificatie op dit punt gevolgd wordt, levert het een open redirect op. Dit betekent dat het voor een aanvaller mogelijk is een link op te stellen waarmee de gebruiker naar een willekeurige URL wordt doorgestuurd. Dit is een risico, omdat een open redirect bijvoorbeeld gebruikt kan worden in phishing-campagnes. Het is daarom verstandig op dit punt niet de OAuth 2.0-specificatie aan te houden, en bijvoorbeeld een error te tonen in plaats van de gebruiker te redirecten.

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.