/
RFC0058 Duidelijkheid over url encoding
Document toolboxDocument toolbox

Let op: deze space wordt momenteel gemigreerd.
Wijzigingen worden niet meer meegenomen.

RFC0058 Duidelijkheid over url encoding

Owned by Former user (Deleted)
Last updated: Sept 10, 2021Version comment

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


OplossingsrichtingIn het Afsprakenstelsel een expliciete uitspraak opnemen (bovenop de OAuth2 specificatie) die de wijze van encodering voorschrijft.


Aanpassing vanAfsprakenstelsel


Impact op rollenDVP, DVZA (gezien het feit dat er tot nu toe geen problemen zijn opgetreden, is de impact waarschijnlijk klein)


Impact op beheerGeen


Impact op RnAGeen


Impact op AcceptatieJa, 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


Implementatietermijn1.5


Motivatie verkorte RFC procedure (patch)Nvt


Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
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:

  1. in het authorization request MOET de redirect_uri urlencoded worden 
  2. in het token request MOET de redirect_uri urlencoded worden 
  3. 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

  1. zodanig dat de erin opgenomen hostname gelijk is aan de client_id en er geen poortnummer is opgenomen
  2. de redirect_uri moet volledig zijn en verwijzen naar een https-beschermd endpoint
  3. 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

  1. dezelfde waarde als in het voorafgaande authorization request
  2. 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.

DreigingKansImpactDreigingsID (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 leidenLH

In Acceptatie controleren op correct gebruik redirect_uri in requests.


Bijlagen

  File Modified
No files shared here yet.