Her er den største api-sårbarhed: Ingen tjek af objekt-id'er

3. oktober 2019 kl. 12:023
Her er den største api-sårbarhed: Ingen tjek af objekt-id'er
Illustration: Microsoft.
Eller: Lad være med at efterlade api'et i pivåben tilstand.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Sårbarheder i et api, hvor et objekt-id'er kan manipuleres, er det største af de problemer, som organisationen Open Web Application Security Project (OWASP) har fundet i en ny rapport om sårbarheder i snitflader. Det skriver mediet Adtmag.

Problemet kan opstå således, ifølge rapporten:

En e-handelsplatform for onlinebutikker viser en oversigtsside med diagrammer over indtægter for de hostede butikker. Ved at kigge nærmere på browser-kommunikationen, kan en angriber identificere api-endepunkter, der bruges som datakilde for disse diagrammer og som kunne se sådan ud:

  1. /shops/{shopName}/revenue_data.json

Med et andet api-endepunkt kan angriberen få listen over de hostede butiker. Med et simpelt script til at manipulere navne på listen, der erstatter {shopName} i URL'en, får angriberen adgang til salgsdata fra tusinder af e-handelsforretninger.

Artiklen fortsætter efter annoncen

Det kalder rapporten for 'broken object level-autorisation,' og det er altså nummer ét på listen i rapporten fra OWASP:

»Angribere kan udnytte endepunkter, der er sårbare over for brud på objektniveau-tilladelse, ved at manipulere id'et på et objekt, der indgår i en request. Det kan føre til uautoriseret adgang til følsomme data. Dette problem er ekstremt almindeligt i api-baserede applikationer, fordi serverkomponenten normalt ikke sporer fuldstændigt klientens tilstand og i stedet er mere afhængig af parametre som objekt-id'er, der sendes fra klienten for at bestemme, hvilke objekter der skal tilgås.«

Bliv medlem af Version2's udviklernetværk

Version2s nye netværk for udviklere er for IT-professionelle, som vil styrke egne kompetencer, sparre med nogle af branchens dygtigste folk og deltage i netværksmøder med relevante speakers.

Netværket mødes fysisk 5 gange årligt, til en spændende dag med indlæg fra én keynote, samt 1-2 sponsorer, hvor alle indlæg tager afsæt i specifikke og aktuelle emner/cases.

Derudover vil deltagerne i netværket kunne mødes online, på vores Meetup gruppe, hvor der er skabt rum til vidensdeling, debatter samt deling præsentationer fra de fysiske netværkmøder.

Næste møde 30. oktober: Azure infrastruktur for udviklere

Læs mere her.

OWASP foreslår en række foranstaltninger, som et udviklingsteam kan tage for at sikre, at dette ikke sker med deres app:

  • Implementer en egentlig autorisationsmekanisme, der er afhængig af brugerpolitikker og hierarki.

  • Undgå at bruge et id, der er sendt fra klienten, men brug i stedet et, der er gemt i sessionobjektet, der stammer fra en databasepost med postens id.

  • Brug en autoriseringsmekanisme til at kontrollere, om en bruger har ret til at udføre den ønskede handling på posten i hver funktion, der bruger inddata fra klienten til at få adgang til en post i databasen.

  • Brug tilfældige og uforudsigelige værdier som id-numre til poster.

  • Skriv tests, der tjekker autorisationsmekanismen. Lad være med at skabe sårbare ændringer, der bryder testene.

3 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
3
4. oktober 2019 kl. 08:45

Hvad er det nye her?

Intet. Men ligesom SQL injection er der grusomt mange læk pga. disse fejltyper, så det er kun godt at blive mindet om det.

2
3. oktober 2019 kl. 14:21

Hvad er det nye her?

Navnet og placeringen.

I 2017 hed det Broken Access Control og i 2013 hed det Missing Function Level Access Control. Det nye er at det nu er nr. 1 på OWASP Top 10, hvor det tidligere var hhv. 5. og 7. plads.

1
3. oktober 2019 kl. 14:15

Hvad er det nye her? Det lyder som logik for burhøns, specielt i lyset af erfaringerne med SQL-injections! "Never trust user input!" osv.