Når det kommer til websites foregår adgangskontrol typisk to gange; én gang når grænsefladen skal vises og der skal tages stilling til om der skal vises et link til en sikker side. Én gang når den sikre side skal vises.
En typisk fejl er at glemme sidstnævnte, at sitet beror rent på adgangskontrol i præsentationslaget og dermed kan ondsindede personer skaffe sig direkte adgang til sikre sider.
Manglende adgangskontrol på funktionsniveau er når vi som udviklere slet og ret har glemt at indføre den kode der skal kontrollere at aktuelle bruger nu også må se det indhold de er på vej til at se.
Angrebseksempel
- En hacker bemærker at adressen også indeholder brugerens rolle.
- Hackeren modificerer adressen og agerer dermed under en anden rolle.
- Resultatet er at hackeren ser data han ikke burde have adgang til at se.
Undgå angreb
- Begræns adgangen til godkendte brugere.
- Giv kun adgang til bestemte brugere eller roller
- Fjern alt adgang til filtyper der ikke bør være offentlige såsom konfigurationsfiler m.v.
- Start med at fjerne al adgang, og brug en positivliste de steder der skal åbnes op.
I ASPNET MVC tilbyder infrastrukturen nogle simple mekanismer til adgangskontrol. Fx. kan der nægtes adgang til anonyme brugere ved at tilføje en attribut til action-metoder:
[Authorize]
public ActionResult Hemmelig()
{
return View();
}
Når jeg tænker tilbage på de løsninger jeg har lavet igennem årene er der en del gange hvor løsningers sikkerhed har beroet på “… det sker nok ikke …”. Eksempelvis løsninger hvor en offentlig adresse kun må kaldes i bestemte situationer og sikkerheden har bestået i security by obscurity1. Men med de frameworks og værktøjer der er til rådighed i dag er det ikke så svært at gøre sikkerheden ægte.
Automatiserede løsninger til at afprøve sikkerheden kan kun afsløre helt basale problemer og det anbefales at man kontrollerer sikkerheden på et website med en slavisk manuel test og gennemgang for at afgøre om målet er nået.
1Security by obscurity er ok – så længe det ikke står alene. Eksempelvis er det ud over at vi sikrer vores webserver, er det også god praksis at kamuflere hvilken software den kører.