SR Tekstaanpassingen verantwoordelijkheden op beveiligingsrisico's

Omschrijving Changelog, met daarin:

Op pagina Verantwoordelijkheden staat onjuist vermeld in een toelichting onder core.autorisatie.204 dat beveiligingsrisico’s op refresh-tokens niet van toepassing zijn omdat tijdens de autorisatieflow alleen een access-token gebruikt wordt. Dit is een verouderde tekst: sinds de introductie van langdurige toestemming gebruiken wij uiteraard refresh-tokens en beveiligingsmaatregelen zijn daar al op van kracht. Hoewel een refresh-token niet expliciet deel uitmaakt van de autorisatieflow, is de toelichting hier verouderd en verwarrend.

De toelichting onder het kopje Beveiliging vermeldt om dezelfde verouderde reden ook dat bedreigingen 4.1.2 en 4.1.3 niet van toepassing zijn, terwijl deelnemers die langdurige toestemming implementeren wel refresh-tokens gebruiken en de beveiligingsmaatregelen daarop toepassen. Toelichting aangepast om de werkelijke situatie te verduidelijken.

Verschillende onjuiste linkverwijzingen repareren wij.

Impact op:

Moeten afbeeldingen/mockups aangepast worden?

Aan te passen versies afsprakenstelsel

v2.5.2, v2.6

Classificatie

Implementatietermijn

geen

Gerelateerde tickets

 AF-847, AF-855, AF-856

Status

Akkoord bevonden door

MedMij Core > Verantwoordelijkheden, Core

core.beveiliging.203

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

core.beveiliging.203

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

Voeg nieuwe regels in op tabel

MedMij Core > Verantwoordelijkheden, Core

core.beveiliging.204

De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

core.beveiliging.204

De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

Voeg nieuwe regels in op tabel

MedMij Core > Verantwoordelijkheden, Core

core.autorisatie.204

Toelichting

Dit is een maatregel tegen de beveiligingsrisico's 4.4.1.1 en 4.4.1.3 uit RFC 6819. Bovendien wordt de hele flow van de functie Verzamelen ononderbroken uitgevoerd. De 900 seconden moeten dan voldoende zijn voor de OAuth Client om het access-token aan de OAuth Authorization Server aan te bieden. Een refresh-token is dan niet nodig.

core.autorisatie.204

Toelichting

Dit is een maatregel tegen de beveiligingsrisico's 4.4.1.1 en 4.4.1.3 uit RFC 6819. Bovendien wordt de hele flow van de functie Verzamelen ononderbroken uitgevoerd. De 900 seconden moeten dan voldoende zijn voor de OAuth Client om het access-token aan de OAuth Authorization Server aan te bieden.

MedMij Core > Verantwoordelijkheden, Core > Beveiliging

Toelichting

Voor het opstellen van bovenstaande verantwoordelijkheden is gebruikgemaakt van RFC 6819 van IETF, dat een uitgebreide inventarisatie van die risico's bevat, inclusief een reeks van maatregelen per risico. Waar het risico van toepassing is op het gebruik van OAuth binnen MedMij, en de maatregelen passen binnen de MedMij-principes, zijn zij opgenomen in het afsprakenstelsel.

Met betrekking tot het gestelde in sectie 3.1 van RFC 6819 kan gesteld worden dat MedMij uitgaat van:

• handles i.p.v. assertions, zodat de OAuth Resource Server moet kunnen refereren aan data van de OAuth Authorization Server;

• bearer-tokens i.p.v. proof-tokens.

In hoofdstuk 4 van RFC 6819 staat een uitgebreide lijst van beveiligingsrisico's. Niet van toepassing zijn, voor de deze release van het afsprakenstelsel:

• bedreiging 4.1.2: Obtaining Refresh Tokens, omdat het afsprakenstelsel niet met refresh tokens werkt;

• bedreiging 4.2.3: Malicious Client Obtains Existing Authorization by Fraud, omdat in het afsprakenstelsel de autorisatie (vooralsnog) strikt eenmalig mag worden gebruikt;

• bedreiging 4.3.4: Obtaining Client Secret from Authorization Server Database, omdat authenticatie van OAuth Clients in MedMij werkt op basis van PKI-servercertificaten, niet op basis van client secrets;

• bedreiging 4.3.5: Obtaining Client Secret by Online Guessing, omdat authenticatie van OAuth Clients in MedMij op basis van PKI-servercertificaten wordt gedaan, niet op basis van client secrets.

Wel van toepassing zijn:

• bedreiging 4.1.3: Obtaining Access Tokens;

• bedreiging 4.1.4: End-user Credential Phished Using Comprised or Embedded Browser;

• bedreiging 4.1.5: Open Redirectors on Client;

• bedreiging 4.2.1: Password Phishing by Counterfeit Authorization Server;

• bedreiging 4.2.2: User Unintentionally Grants Too Much Access Scope;

• bedreiging 4.2.4: Open Redirector;

• bedreiging 4.3.1: Eavesdropping Access Tokens;

• bedreiging 4.3.2: Obtaining Access Tokens from Authorization Server Database;

• bedreiging 4.3.3: Disclosure of Client Credentials during Transmission;

• bedreiging 4.1.1: Obtaining Client Secrets;

• bedreiging 4.4.1.1: Eavesdropping or Leaking Authorization Code;

• bedreiging 4.4.1.2: Obtaining Authorization "codes" from Authorization Server Database;

• bedreiging 4.4.1.3: Online Guessing of Authorization "codes";

• bedreiging 4.4.1.4: Malicious Client Obtains Authorization;

• bedreiging 4.4.1.5: Authorization "code" Phishing;

• bedreiging 4.4.1.6: User Session Impersonation;

• bedreiging 4.4.1.7: Authorization "code" Leakage through Counterfeit Client;

• bedreiging 4.4.1.8: CSRF against redirect-URI;

• bedreiging 4.4.1.9: Clickjacking Attack against Authorization;

• bedreiging 4.4.1.10: Resource Owner Impersonation;

• bedreiging 4.4.1.11: DoS Attacks That Exhaust Resources;

• bedreiging 4.4.1.12: DoS Using Manufactured Authorization "codes";

• bedreiging 4.4.1.13: Code Substitution (OAuth Login).

Toelichting

Voor het opstellen van bovenstaande verantwoordelijkheden is gebruikgemaakt van RFC 6819 van IETF, dat een uitgebreide inventarisatie van die risico's bevat, inclusief een reeks van maatregelen per risico. Waar het risico van toepassing is op het gebruik van OAuth binnen MedMij, en de maatregelen passen binnen de MedMij-principes, zijn zij opgenomen in het afsprakenstelsel.

Met betrekking tot het gestelde in sectie 3.1 van RFC 6819 kan gesteld worden dat MedMij uitgaat van:

• handles i.p.v. assertions, zodat de OAuth Resource Server moet kunnen refereren aan data van de OAuth Authorization Server;

• bearer-tokens i.p.v. proof-tokens.

In hoofdstuk 4 van RFC 6819 staat een uitgebreide lijst van beveiligingsrisico's. Niet van toepassing zijn, voor de deze release van het afsprakenstelsel:

• bedreiging 4.3.4: Obtaining Client Secret from Authorization Server Database, omdat authenticatie van OAuth Clients in MedMij werkt op basis van PKI-servercertificaten, niet op basis van client secrets;

• bedreiging 4.3.5: Obtaining Client Secret by Online Guessing, omdat authenticatie van OAuth Clients in MedMij op basis van PKI-servercertificaten wordt gedaan, niet op basis van client secrets.

Wel van toepassing zijn:

• bedreiging 4.1.2: Obtaining Refresh Tokens;

• bedreiging 4.2.3: Malicious Client Obtains Existing Authorization by Fraud;

• bedreiging 4.1.3: Obtaining Access Tokens;

• bedreiging 4.1.4: End-user Credential Phished Using Comprised or Embedded Browser;

• bedreiging 4.1.5: Open Redirectors on Client;

• bedreiging 4.2.1: Password Phishing by Counterfeit Authorization Server;

• bedreiging 4.2.2: User Unintentionally Grants Too Much Access Scope;

• bedreiging 4.2.4: Open Redirector;

• bedreiging 4.3.1: Eavesdropping Access Tokens;

• bedreiging 4.3.2: Obtaining Access Tokens from Authorization Server Database;

• bedreiging 4.3.3: Disclosure of Client Credentials during Transmission;

• bedreiging 4.1.1: Obtaining Client Secrets;

• bedreiging 4.4.1.1: Eavesdropping or Leaking Authorization Code;

• bedreiging 4.4.1.2: Obtaining Authorization "codes" from Authorization Server Database;

• bedreiging 4.4.1.3: Online Guessing of Authorization "codes";

• bedreiging 4.4.1.4: Malicious Client Obtains Authorization;

• bedreiging 4.4.1.5: Authorization "code" Phishing;

• bedreiging 4.4.1.6: User Session Impersonation;

• bedreiging 4.4.1.7: Authorization "code" Leakage through Counterfeit Client;

• bedreiging 4.4.1.8: CSRF against redirect-URI;

• bedreiging 4.4.1.9: Clickjacking Attack against Authorization;

• bedreiging 4.4.1.10: Resource Owner Impersonation;

• bedreiging 4.4.1.11: DoS Attacks That Exhaust Resources;

• bedreiging 4.4.1.12: DoS Using Manufactured Authorization "codes";

• bedreiging 4.4.1.13: Code Substitution (OAuth Login).

Merk op dat 4.1.2 en 4.1.3 verschuiven van lijst ‘Niet van toepassing zijn’ naar ‘Wel van toepassing zijn’.

MedMij Core > Verantwoordelijkheden, Core > Tokeninterface

core.tknint.201

refresh_token

Conform verantwoordelijkheid core.autorisatie.211

core.tknint.201

refresh_token

Conform verantwoordelijkheid core.autorisatie.211

De link onder core.autorisatie.211 is onjuist en mag verwijzen naar https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/verantwoordelijkheden-core#core.autorisatie.211

MedMij Core > Verantwoordelijkheden, Core > Tokeninterface

core.tknint.205

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie verantwoordelijkheid core.beveiliging.205).

Met het oog op de parameters client_id en redirect_uri in de authorization request en de access token request geldt dat:

• de client_id in de authorization request overeen moet komen met de hostname van de redirect_uri in diezelfde authorization request (verantwoordelijkheid 1 bij Authorization interface);

• de redirect_uri in de access token request overeen moet komen met de redirect_uri in de authorization request (deze verantwoordelijkheid).

In de access token request speelt de redirect_uri dan niet de rol van adressering van de response, zoals in de authorization request wel, maar enkel als terugverwijzing naar de redirect_uri van het Authorization interface. Bij de afhandeling van het unnamed link wordt helemaal niet geredirect; die speelt zich geheel op het backchannel af.

core.tknint.205

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie verantwoordelijkheden core.beveiliging.201 en core.beveiliging.204).

Met het oog op de parameters client_id en redirect_uri in de authorization request en de access token request geldt dat:

• de client_id in de authorization request overeen moet komen met de hostname van de redirect_uri in diezelfde authorization request (verantwoordelijkheid 1 bij Authorization interface);

• de redirect_uri in de access token request overeen moet komen met de redirect_uri in de authorization request (deze verantwoordelijkheid).

In de access token request speelt de redirect_uri dan niet de rol van adressering van de response, zoals in de authorization request wel, maar enkel als terugverwijzing naar de redirect_uri van het Authorization interface. Bij de afhandeling van het token request wordt helemaal niet geredirect; die speelt zich geheel op het backchannel af.

(Unnamed link verwijderen wij.)

MedMij Core > Verantwoordelijkheden, Core > Authorization interface

7

core.authint.206

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie verantwoordelijkheid core.beveiliging.205). Zie ook verantwoordelijkheid core.tknint.206.

7

core.authint.206

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie verantwoordelijkheden core.beveiliging.201 en core.beveiliging.204). Zie ook verantwoordelijkheid core.tknint.205.

Link mag worden: https://afsprakenstelsel.medmij.nl/asverplicht/mmverplicht/token-interface#core.tknint.205

MedMij Core > Verantwoordelijkheden, Core > Tokeninterface

8

core.tknint.204

De Authorization Server voert een authorization code af, wanneer het eenmaal door een OAuth Client is aangeboden.

Toelichting

Dit is een maatregel tegen beveiligingsrisico 4.1.1 uit RFC 6819 (zie toelichting bij verantwoordelijkheden core.beveiliging.202, core.beveiliging.203, core.beveiliging.204). Het afvoeren van een authorization code houdt in dat de Authorization Server van een eenmaal uitgegeven authorization code bijhoudt of die al eens gebruikt is voor het verkrijgen van een access token. Mocht een authorization code voor een tweede of volgende keer worden aangeboden ter verkrijging van een access token, dan zal de Authorization Server dat weigeren en de flow afbreken. Als de Client aan wie die geweigerd wordt te kwader trouw was, is hiermee een gevaar afgewend. Was hij wel te goeder trouw en handelde hij conform het MedMij Afsprakenstelsel, dan was hij niet degene die al eerder dezelfde authorization code aanbood en blijkt er dus sprake geweest te zijn van een security breach.

8

core.tknint.204

De Authorization Server voert een authorization code af, wanneer het eenmaal door een OAuth Client is aangeboden.

Toelichting

Dit is een maatregel tegen beveiligingsrisico 4.4.1.1 uit RFC 6819 (zie toelichting bij verantwoordelijkheden core.beveiliging.202, core.beveiliging.203, core.beveiliging.204). Het afvoeren van een authorization code houdt in dat de Authorization Server van een eenmaal uitgegeven authorization code bijhoudt of die al eens gebruikt is voor het verkrijgen van een access token. Mocht een authorization code voor een tweede of volgende keer worden aangeboden ter verkrijging van een access token, dan zal de Authorization Server dat weigeren en de flow afbreken. Als de Client aan wie die geweigerd wordt te kwader trouw was, is hiermee een gevaar afgewend. Was hij wel te goeder trouw en handelde hij conform het MedMij Afsprakenstelsel, dan was hij niet degene die al eerder dezelfde authorization code aanbood en blijkt er dus sprake geweest te zijn van een security breach.

Verwijzing naar beveiligingsrisico 4.1.1 nu meer-specifiek naar 4.4.1.1 met de link https://datatracker.ietf.org/doc/html/rfc6819#section-4.4.1.1