Foutmelding wanneer niet-gespecificeerde parameter wordt gebruikt

[fsamwel]

Wanneer een query parameter wordt gebruikt die niet is gespecificeerd zou ik een foutmelding verwachten.

Bijvoorbeeld "https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten?rsin=857567433&grondoppervlakte=106"

Nu wordt dit (niet-gespecificeerde parameter "grondoppervlakte") volledig genegeerd, ook in de self link:

{
    "_links": {
        "self": {
            "href": "http://api.acceptatie.kadaster.nl/haalcentraal-api/wozobjecten?rsin=857567433"
        }
    }
}

Zie ook https://github.com/VNG-Realisatie/Haal-Centraal-WOZ-bevragen/pull/49/files:

Rule: alleen gespecificeerde parameters mogen worden opgegeven
    Abstract Scenario: Niet gespecificeerd parameter
        Als '/wozobjecten?<parameter>=123456789' wordt aangeroepen
        Dan bevat de response de volgende kenmerken
        | naam   | waarde                                                     |
        | title  | Een of meerdere parameters zijn niet correct.              |
        | status | 400                                                        | 
        | detail | Zoeken met parameter '<parameter>' wordt niet ondersteund. |
        En bevat de response de volgende invalidParams
        | name        | reason                 |
        | <parameter> | wordt niet ondersteund |

        Voorbeelden:
        | description                                                                      | parameter     |
        | gebruik van een WOZ-object kenmerk die niet wordt ondersteund als zoek parameter | identificatie |
        | willekeurig string als zoek parameter                                            | bestaatniet   |

[kad-tromps]

@fsamwel Dit is niet standaard voor een api, of wat voor een url dan ook. We kijken naar bestaande parameters, en of deze correct worden mee gegeven, maar niet naar alle andere mogelijke parameters die niet gebruikt worden door de API.

De self link is dan ook in feite correct. Aangezien de parameter grondoppervlakte niet bestaat op de API, heeft deze parameter ook geen effect op de uitkomst van de API, en is dus identiek aan de aanroep zonder de niet bestaande parameter.

[fsamwel]

@MelvLee jij hebt deze foutmelding gedefinieerd. Kan jij uitleggen waarom jij wel graag een foutmelding hierop wilt krijgen? (of het uit je pull request halen wanneer het eigenlijk toch niet zo nodig is)

Overigens is het wel goed de werking van de API te specificeren op dit punt, want de verschillende Haal Centraal API's reageren verschillend op dit punt. De BAG API geeft hierop een fout, de BRK API negeert de onbekende parameter, maar neemt deze wel op in de self-link, de BRP API (implementatie in Den Haag) geeft ook een foutmelding en de WOZ API negeert de parameter en neemt deze ook niet op in de self-link.

[MelvLee]

@MelvLee jij hebt deze foutmelding gedefinieerd. Kan jij uitleggen waarom jij wel graag een foutmelding hierop wilt krijgen? (of het uit je pull request halen wanneer het eigenlijk toch niet zo nodig is)

Dit is een copy-paste actie uit de foutafhandeling feature in HC Common.

Of het nodig is weet ik niet. Het hangt af van de gewenste functionaliteit. We kunnen ervoor kiezen om alleen de parameters te valideren die in de OAS specificaties staan en andere te negeren. Dit is wat .NET standaard doet en ik verwacht dat de Spring framework ook standaard doet. Dit is dus het makkelijkst voor de provider. Dit betekent ook wel dat je sommige situaties niet kan detecteren, zoals een letter invullen in huisnummer. In dat geval krijgt je in .NET code voor huisnummer de waarde 0.

Volgens mij kan het geen kwaad om het te negeren, maar 100% durf ik het niet te zeggen, want het zou heel goed kunnen dat het security wise een bad practice is.

[kad-tromps]

Dit is wat .NET standaard doet en ik verwacht dat de Spring framework ook standaard doet.

Exact dit. Ik heb hier nog geen mooie algemene specificatie van kunnen vinden, zoals een w3c rfc oid, maar heb wel wat rond gezocht op willekeurige urls, door achter de root een niet bestaande parameter te zetten, en ben nog nergens een foutmeldig tegen gekomen. Daar moet ik wel bij zeggen, dit is voor zover ik weet altijd het standaard gedrag geweest van Spring boot, dus het is ook iets waar ik helemaal geen rekening meer mee houd. Geeft maar weer het gevaar van aannames weer.

Dit betekent ook wel dat je sommige situaties niet kan detecteren, zoals een letter invullen in huisnummer. In dat geval krijgt je in .NET code voor huisnummer de waarde 0.

Deze volg ik niet helemaal. Als parameters gespecificeerd zijn op het endpoint kunnen we deze valideren op welke manier we ook willen. Dus wanneer zoeken op huisnummer is geïmplementeerd, kunnen we die ook valideren op numeriek.

[fsamwel]

Als parameters gespecificeerd zijn op het endpoint kunnen we deze valideren op welke manier we ook willen. Dus wanneer zoeken op huisnummer is geïmplementeerd, kunnen we die ook valideren op numeriek.

helemaal mee eens. Als je een niet-gespecificeerde parameter negeert zie ik daar ook niet veel schadelijks aan. Als je een gespecificeerde parameter krijgt moet die gevalideerd worden, bijvoorbeeld huisnummer=1b moet denk ik een foutmelding geven.

De Security gevolgen weet ik zo niet. Voor een website zou het ongevalideerd doorzetten van invoer een cross site scripting risico zijn. We geven de gebruikersinvoer immers ongewijzigd terug in de self link. Maar wat dat betreft is het maar de vraag of een foutmelding heel veel helpt als we gebruikersinvoer ook in de instance property in een foutmelding teruggeven.

[kad-tromps]

We geven de gebruikersinvoer immers ongewijzigd terug in de self link. Maar wat dat betreft is het maar de vraag of een foutmelding heel veel helpt als we gebruikersinvoer ook in de instance property in een foutmelding teruggeven.

Dit is iets wat ook opgelost wordt door Spring's implementatie van REST. Voor zo ver Spring weet, zijn alleen de parameters die op het endpoint zijn gespecificeerd mee gegegeven. Dit heeft als tweede effect dat, tenzij ik er specifiek rekening mee houd, alleen gespecificeerde parameters kunnen verschijnen in de self link. Kort gezegd, wat de server betreft, bestaan niet gedefinieerde parameters helemaal niet.

(Ik zou ze vast wel ergens diep uit de servlet request kunnen vissen, maar dan moet je er echt naar gaan zoeken).

Als de parameters nergers worden geinterpreteerd, is er volgensmij ook geen XSS risico

[fsamwel]

voor nu wordt deze geparkeerd. Hoeft nu niet te worden opgelost.

[MelvLee]

Dit betekent ook wel dat je sommige situaties niet kan detecteren, zoals een letter invullen in huisnummer. In dat geval krijgt je in .NET code voor huisnummer de waarde 0.

Deze volg ik niet helemaal. Als parameters gespecificeerd zijn op het endpoint kunnen we deze valideren op welke manier we ook willen. Dus wanneer zoeken op huisnummer is geïmplementeerd, kunnen we die ook valideren op numeriek.

Wat ik bedoel is dat in .NET in het geval van huisnummer zonder custom code niet kan achterhalen of een consumer geen huisnummer, een ongeldig huisnummer (1A of alleen A) of 0 heeft opgegeven. In alle drie gevallen krijgt je standaard 0.

[fsamwel]

Ik concludeer uit de reacties van @kad-tromps en @MelvLee dat we niet gespecificeerde parameters kunnen negeren en die ook niet opnemen in instance en _links.self.

@MelvLee pas jij dat ook aan in de feature(s)?

[MelvLee]

Ik concludeer uit de reacties van @kad-tromps en @MelvLee dat we niet gespecificeerde parameters kunnen negeren en die ook niet opnemen in instance en _links.self.

@MelvLee pas jij dat ook aan in de feature(s)?

Feature is al aangepast