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.

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:

/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.

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.«

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize