RFC0058 Duidelijkheid over url encoding

Samenvatting

Arjan van Krimpen Casper van der Harst

Waarom is deze RFC nodig?	De OAuth2 specificaties doen geen (harde) uitspraak over of/hoe urls die als parameter in een Oauth2 request of response worden meegegeven, moeten worden encoded. Dit kan potentieel tot problemen leiden wanneer bij het verwerken van een request/response een url 'dubbel' of 'anders' geencodeerd wordt en daarna niet correct meer kan worden verwerkt. Denk bijvoorbeeld aan de redirect_uri. De ruimte die OAuth laat, heeft tot nu toe nog niet in de praktijk geleid tot problemen. Wel is ontstond recent een probleem in de tooling van Acceptatie, waarbij een proxy automatisch url's encodeerde. Om problemen te voorkomen dat toekomstige ontwikkelomgevingen en tools ook een 'automagische encoding' toepassen zal een eenduidige afspraak worden toegevoegd aan het AS. Voorstel is om alle redirect_uri's verplicht te url_encoden
Oplossingsrichting	In het Afsprakenstelsel een expliciete uitspraak opnemen (bovenop de OAuth2 specificatie) die de wijze van encodering voorschrijft.
Aanpassing van	Afsprakenstelsel
Impact op rollen	DVP, DVZA (gezien het feit dat er tot nu toe geen problemen zijn opgetreden, is de impact waarschijnlijk klein)
Impact op beheer	Geen
Impact op RnA	Geen
Impact op Acceptatie	Ja, aanpassingen aan scripts waar url's voorkomen in aanroepen. Uitbreiden testen met controle op encodering op voorgeschreven manier.
PIA noodzakelijk
Gerelateerd aan (Andere RFCs, PIM issues)
Eigenaar
Implementatietermijn	1.5
Motivatie verkorte RFC procedure (patch)	Nvt

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

Principe's

Principe		Principe
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal		11 Stelselfuncties worden vanaf de start ingevuld
2 Dienstverleners zijn transparant over de gegevensdiensten		12 Het afsprakenstelsel is een groeimodel
3 Dienstverleners concurreren op de functionaliteiten		13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
4 Dienstverleners zijn aanspreekbaar door de gebruiker		14 Uitwisseling is een keuze
5 De persoon wisselt gegevens uit met de zorgaanbieder		15 Het MedMij-netwerk is gebruiksrechten-neutraal
6 MedMij spreekt alleen af wat nodig is		16 De burger regisseert zijn gezondheidsinformatie als uitgever
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener		17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
9 De dienstverleners zijn deelnemers van het afsprakenstelsel		18 Afspraken worden aantoonbaar nageleefd en gehandhaafd
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling		19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat
Toelichting

Uitwerking

In MedMij wordt in het OAuth2 protocol de redirect_uri alleen statisch toegepast om beveiligingsredenen (conform https://tools.ietf.org/html/rfc6819#section-5.2.3.3). Daarnaast mag conform OAuth2 geen fragment worden toegepast.

https://willekeurigpgo.nl/over/there?srvr=hst0#frgmnt
\_____/ \_________________/\__________/ \_________/ \_____/
| | | | |
scheme authority path query fragment

Dit betekent in de praktijk dat een redirect_uri binnen MedMij zal zijn opgebouwd uit een scheme, authority/domein, path en query deel :

de redirect_uri MOET een absolute URI zijn, zoals gedefinieerd in RFC 3986, Sectie 4.3.
de redirect_uri MAG een query bevatten, zoals beschreven in RFC 3986, Sectie 3.4. Deze query moet geformatteerd zijn volgens de principes van application/x-www-form-urlencoded Media Type. (Overigens leert een scan van de ZAL dat er nog geen deelnemers zijn die het query deel toepassen.)

RFC 6749, Appendix B zegt dat

de namen en waardes in de query UTF-8 geformatteerd MOETEN zijn volgens het encoding scheme. Zie RFC 3629.
Als alles UTF-8 geformatteerd is MOETEN namen en waardes moet geformatteerd worden volgens de principes van W3c.REC-html401-19991224.

Dit betekent dat de in ieder geval het query deel URLEncoded MOET zijn.

Om eenduidig gebruik te garanderen zou binnen het Afsprakenstels daarom de volgende eis toegevoegd moeten worden:

in het authorization request MOET de redirect_uri urlencoded worden
in het token request MOET de redirect_uri urlencoded worden
url_encoding moet conform https://datatracker.ietf.org/doc/html/rfc3986 (in praktijk zouden standaardimplementaties deze specificatie moeten volgen)

Op pagina Authorization interface toevoegen:

redirect_uri
zodanig dat de erin opgenomen hostname gelijk is aan de client_id en er geen poortnummer is opgenomen
de redirect_uri moet volledig zijn en verwijzen naar een https-beschermd endpoint
de redirect_uri moet urlencoded zijn (conform https://datatracker.ietf.org/doc/html/rfc3986)
Zie verantwoordelijkheden 1 en 2a op de pagina Interfaces.
De tweede eis is een maatregel tegen beveiligingsrisico's 4.1.5, 4.2.4, 4.4.1.1, 4.4.1.5 en 4.4.1.6 in RFC 6819. Zie bovendien Token interface, de toelichting onder verantwoordelijkheid 4.

Op pagina Token interface toevoegen:

redirect_uri
dezelfde waarde als in het voorafgaande authorization request
de redirect_uri moet urlencoded zijn (conform https://datatracker.ietf.org/doc/html/rfc3986
NB: De redirect_uri MOET NIET dubbel encoded worden(!)

Er is geen impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Dreiging

Kans

Impact

DreigingsID (intern)

Maatregelen

DVZA kan authorization of token request niet verwerken door encode url in request.

L

H

In Acceptatie controleren op correct gebruik redirect_uri in requests.

Afwijkende implementatie van url_encoding in verschillende ontwikkelplatforms kan tot problemen leiden

L

H

In Acceptatie controleren op correct gebruik redirect_uri in requests.

Bijlagen

	File	Modified

No files shared here yet.