Ik heb gehoord dat het vrijgeven van database-ID’s (bijvoorbeeld in URL’s) een veiligheidsrisico is, maar ik begrijp niet waarom.
Enige meningen of links over waarom het een risico is, of waarom het dat niet is?
EDIT: natuurlijk is de toegang beperkt, b.v. als je bron foo?id=123niet kunt zien, krijg je een foutpagina. Anders zou de URL zelf geheim moeten zijn.
EDIT: als de URL geheim is, zal deze waarschijnlijk een gegenereerde token bevatten met een beperkte levensduur, b.v. geldig voor 1 uur en kan slechts één keer worden gebruikt.
BEWERKEN (maanden later): mijn huidige voorkeurspraktijk hiervoor is om UUIDS voor ID’s te gebruiken en deze bloot te leggen. Als ik volgnummers gebruik (meestal voor prestaties op sommige DB’s) als ID’s, genereer ik graag een UUID-token voor elk item als een alternatieve sleutel, en laat dat zien.
Antwoord 1, autoriteit 100%
Er zijn risico’s verbonden aan het vrijgeven van database-ID’s. Aan de andere kant zou het erg omslachtig zijn om een webapplicatie te ontwerpen zonder ze helemaal bloot te leggen. Het is dus belangrijk om de risico’s te begrijpen en deze aan te pakken.
Het eerste gevaar is wat OWASP “onveilige directe objectreferenties” noemde.Als iemand de id van een entiteit ontdekt en uw toepassing onvoldoende autorisatiecontroles heeft om dit te voorkomen, kunnen ze dingen doen die u niet van plan was.
Hier volgen enkele goede regels:
- Gebruik op rollen gebaseerde beveiliging om de toegang tot een bewerking te beheren. Hoe dit wordt gedaan, hangt af van het platform en het raamwerk dat je hebt gekozen, maar velen ondersteunen een declaratief beveiligingsmodel dat browsers automatisch omleidt naar een authenticatiestap wanneer een actie enige autoriteit vereist.
- Gebruik programmatische beveiliging om de toegang tot een object te regelen. Dit is moeilijker te doen op kaderniveau. Vaker is het iets dat u in uw code moet schrijven en daarom foutgevoeliger is. Deze controle gaat verder dan op rollen gebaseerde controle door er niet alleen voor te zorgen dat de gebruiker autoriteit heeft voor de bewerking, maar ook over de nodige rechten voor het specifieke object dat wordt gewijzigd. In een op rollen gebaseerd systeem is het gemakkelijk om te controleren of alleen managers loonsverhogingen kunnen geven, maar verder moet u ervoor zorgen dat de werknemer tot de afdeling van de betreffende manager behoort.
Er zijn schema’s om de echte identifier voor een eindgebruiker te verbergen (bijvoorbeeld een kaart tussen de echte identifier en een tijdelijke, gebruikersspecifieke identifier op de server), maar ik zou zeggen dat dit een vorm van beveiliging door onduidelijkheid is. Ik wil me concentreren op het bewaren van echte cryptografische geheimen, niet proberen applicatiegegevens te verbergen. In een webcontext druist het ook in tegen het veelgebruikte REST-ontwerp, waar identifiers vaak worden weergegeven in URL’s om een bron aan te spreken, die onderhevig is aan toegangscontrole.
Een andere uitdaging is de voorspelling of ontdekking van de identifiers. De gemakkelijkste manier voor een aanvaller om een ongeautoriseerd object te ontdekken, is door het te raden aan de hand van een nummeringsreeks. De volgende richtlijnen kunnen dat helpen verminderen:
-
Alleen onvoorspelbare identifiers zichtbaar maken. Omwille van de prestaties kunt u volgnummers gebruiken in externe-sleutelrelaties in de database, maar elke entiteit waarnaar u wilt verwijzen vanuit de webtoepassing moet ook een onvoorspelbare surrogaat-ID hebben. Dit is de enige die ooit aan de klant zou moeten worden blootgesteld. Het gebruik van willekeurige UUID’s hiervoor is een praktische oplossing voor het toewijzen van deze surrogaatsleutels, ook al zijn ze niet cryptografisch veilig.
-
Eén plaats waar cryptografisch onvoorspelbare identifiers echter noodzakelijk zijn, is in sessie-ID’s of andere authenticatietokens, waar de ID zelf een verzoek authenticeert. Deze moeten worden gegenereerd door een cryptografische RNG.
Antwoord 2, autoriteit 53%
Hoewel het geen gegevensbeveiliging-risico is, is dit absoluut een business intelligence-beveiliging-risico, aangezien het beide gegevens blootlegt grootte en snelheid. Ik heb gezien dat bedrijven hierdoor geschaad worden en heb uitgebreid over dit antipatroon geschreven. Tenzij je alleen een experiment bouwt en geen bedrijf, raad ik je ten zeerste aan om je privé-ID’s buiten het publieke oog te houden. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-inplace-of-database-ids-on-urls-and-in-apis-17f15669fd2e
Antwoord 3, autoriteit 27%
Het hangt af van waar de ID’s voor staan.
Beschouw een site die om concurrentieredenen niet openbaar wil maken hoeveel leden ze hebben, maar door opeenvolgende ID’s toch in de URL te onthullen: http://some.domain.name/user?id=3933
Aan de andere kant, als ze in plaats daarvan de inlognaam van de gebruiker hebben gebruikt: http:// some.domain.name/user?id=sommigeze hebben niets bekendgemaakt dat de gebruiker nog niet wist.
Antwoord 4, autoriteit 21%
De algemene gedachte gaat als volgt: “Geef zo min mogelijk informatie over de werking van uw app aan iedereen.”
Het vrijgeven van de database-ID telt als het vrijgeven van bepaalde informatie.
De redenen hiervoor zijn dat hackers alle informatie over de werking van uw apps kunnen gebruiken om u aan te vallen, of dat een gebruiker de URL kan wijzigen om in een database te komen die hij/zij niet mag zien?
Antwoord 5, autoriteit 16%
We gebruiken GUID’s voor database-ID’s. Ze laten lekken is een stuk minder gevaarlijk.
Antwoord 6, autoriteit 4%
Als u integer-ID’s in uw database gebruikt, kunt u het voor gebruikers gemakkelijk maken om gegevens te zien die ze niet zouden moeten zien door qs-variabelen te wijzigen.
Bijvoorbeeld een gebruiker kan gemakkelijk de id-parameter in deze qs wijzigen en gegevens zien/wijzigen die ze niet zouden moeten http://someurl?id=1
Antwoord 7, autoriteit 4%
Als je database-ID’s naar je klant stuurt, ben je in beide gevallen gedwongenom de beveiliging te controleren. Als u de ID’s in uw websessie bewaart, kunt u kiezen of u dit wilt/moet doen, wat mogelijk minder verwerking betekent.
Je probeert constant dingen te delegeren aan je toegangscontrole 😉 Dit kanhet geval zijn in je applicatie, maar ik heb nog nooit zo’n consistent back-end systeem gezien in mijn hele carrière. De meeste van hen hebben beveiligingsmodellen die zijn ontworpen voor niet-webgebruik en aan sommige zijn postuum extra rollen toegevoegd, en sommige zijn buiten het kernbeveiligingsmodel vastgeschroefd (omdat de rol in een andere operationele context is toegevoegd, zeg maar voor het internet).
Dus we gebruiken synthetische lokale ID’s voor sessies omdat het zoveel mogelijk verbergt als we kunnen wegkomen.
Er is ook het probleem van niet-gehele sleutelvelden, wat het geval kan zijn voor opgesomde waarden en dergelijke. Je kunt proberen die gegevens op te schonen, maar de kans is groot dat je eindigt als kleine bobby drop-tabellen.
Antwoord 8
Vanuit het oogpunt van codeontwerp moet een database-ID worden beschouwd als een privé-implementatiedetail van de persistentietechnologie om een rij bij te houden. Indien mogelijk moet u uw toepassing ontwerpen zonder enige verwijzing naar deze ID. In plaats daarvan moet u nadenken over hoe entiteiten in het algemeen worden geïdentificeerd. Is een persoon geïdentificeerd met zijn sofinummer? Is een persoon geïdentificeerd met zijn e-mailadres? Als dat het geval is, mag uw accountmodel alleen een verwijzing naar die kenmerken bevatten. Als er geen echte manier is om een gebruiker met een dergelijk veld te identificeren, moet u een UUID genereren voordat u naar de database gaat.
DOEN DOEN HEEFT VEEL VOORDELEN ZOALS HET WELLEN MOETEN UW DOMEINMODELEN VAN PERSENTIE-TECHNOLOGIEËN TE DIFEREN. Dat zou betekenen dat u database-technologieën kunt vervangen zonder zich zorgen te maken over de primaire sleutelcompatibiliteit. Het lekken van uw primaire sleutel tot uw datamodel is niet noodzakelijk een beveiligingsprobleem als u de juiste autorisatiecode schrijft, maar het indicatief van minder dan optimaal codeontwerp.