OWASP Top 10: sikkerhetshull på nettet

01Hva er OWASP og Top 10-listen?

OWASP (Open Worldwide Application Security Project) er et åpent fellesskap som lager gratis ressurser, verktøy og veiledninger om programvaresikkerhet. Det mest kjente arbeidet er Top 10-listen, som oppdateres med noen års mellomrom.

Listen er ikke en standard eller et sertifikat, men et dokument for økt bevissthet. Den er utarbeidet ved å kombinere åpne data fra den virkelige verden og ekspertvurderinger, og sier til utviklere: «se først på disse». I denne artikkelen tar vi utgangspunkt i kategoriene i den allment aksepterte 2021-versjonen.

Listen endrer seg over tid; i nye versjoner bytter kategorier plass eller slås sammen. Sjekk alltid den nyeste versjonen på den offisielle kilden owasp.org.

021–2. Tilgangskontroll og kryptering

De to første plassene på listen handler om hvem dataene vises til og hvordan de beskyttes. Begge hører til de hullene som oftest forekommer og som gir de alvorligste konsekvensene, fordi de rammer kundedata direkte.

Brutt tilgangskontroll

En feil i tilgangskontroll betyr at en bruker kan nå data eller handlinger vedkommende ikke har rett til. Klassisk eksempel: en kunde endrer verdien siparis/1052 i adressefeltet til 1053 og får se en annen persons bestilling.

Tiltaket er enkelt, men krever disiplin: ved hver forespørsel, på serversiden, må spørsmålet «kan denne brukeren se denne posten?» stilles på nytt. Standardoppførselen bør være å avvise; tilgang åpnes bare der den er uttrykkelig tillatt.

Kryptografiske feil

Sensitive data som overføres eller lagres uten kryptering hører hjemme her. Passord lagret som klartekst eller med svake metoder, manglende bruk av HTTPS og utdaterte krypteringsalgoritmer er de vanligste eksemplene.

For passord bør du bruke trege hashmetoder laget for formålet, som bcrypt eller Argon2, all trafikk bør gå over HTTPS, og krypteringsnøkler bør lagres i et sikkert miljø, ikke i selve koden.

033. Injeksjon: SQL-injeksjon og XSS

Når data fra brukeren kjøres som en del av en kommando, er det et injeksjonshull. De mest kjente typene er SQL-injeksjon og XSS. I 2021-listen behandles XSS også under denne kategorien.

Hva er SQL-injeksjon?

SQL-injeksjon er at en databasespørring endres av spesialtegn skrevet inn i et skjema eller et adressefelt. Angriperen kan stjele eller slette data, eller logge inn uten tillatelse. Løsningen er å bygge spørringen med forberedte spørringer (prepared statements), ikke ved å sette sammen tekst.

// FEIL: brukerinndata legges rett inn i spørringen
$sql = "SELECT * FROM uyeler WHERE eposta = '" . $_POST['eposta'] . "'";

// RIKTIG: forberedt spørring
$stmt = $pdo->prepare('SELECT * FROM uyeler WHERE eposta = ?');
$stmt->execute([$_POST['eposta']]);
$uye = $stmt->fetch();

Hva er XSS?

XSS (Cross-Site Scripting) er at JavaScript skrevet av en angriper plasseres på siden. Et skript skrevet inn i et kommentarfelt kan kjøres i nettleseren til alle som åpner siden. Grunnleggende tiltak er å bruke escaping tilpasset konteksten når du skriver ut data, og å legge til en Content Security Policy-header (CSP).

echo htmlspecialchars($yorum, ENT_QUOTES, 'UTF-8');

044–5. Usikker design og konfigurasjon

Disse to kategoriene handler mer om beslutninger enn om selve koden: hvordan systemet er lagt opp, og hvordan serveren er satt opp. Den gode nyheten er at begge i stor grad kan forebygges med rutiner og sjekklister.

Usikker design

Denne kategorien beskriver designfeil mer enn kodefeil. For eksempel å stole bare på et gjettbart sikkerhetsspørsmål ved tilbakestilling av passord, eller at en kampanjekode kan prøves ubegrenset. Selv om koden er skrevet feilfritt, tettes ikke et designhull.

Tiltaket er å tenke på sikkerhet i begynnelsen av utviklingen, ikke på slutten: trusselmodellering, misbrukstilfeller og begrensning av antall forsøk (rate limiting) bør diskuteres i designfasen.

Feil i sikkerhetskonfigurasjon

Standardpassord som ikke er endret, serverdetaljer i feilmeldinger, unødvendige tjenester som står åpne eller åpen kataloglisting hører hjemme her. Dette er ofte de hullene som er enklest å utnytte.

Tiltak: lag en skriftlig herdingsliste for server og applikasjon, slå av feildetaljer i produksjonsmiljøet, legg til sikkerhetshoder (som HSTS, CSP og X-Content-Type-Options) og kontroller konfigurasjonen jevnlig.

056–7. Komponenter og autentisering

Risikoene på sjette og sjuende plass handler om delene applikasjonen henter utenfra og måten brukerens identitet bekreftes på. Begge krever jevnlig vedlikehold; det holder ikke å sette opp og la det stå.

Utdaterte komponenter med kjente hull

En moderne applikasjon bruker dusinvis, ja hundrevis av eksterne biblioteker. Når det finnes et hull i ett av dem, kommer applikasjonen din i fare selv om du ikke har gjort en eneste feil.

Tiltak: hold en liste over komponentene som brukes, følg med på sikkerhetsmeldinger og oppdater jevnlig. Revisjonskommandoene i pakkehåndtererne gjør jobben enklere. Å fjerne ubrukte avhengigheter er også et av de billigste sikkerhetstiltakene.

npm audit
composer audit

Feil i autentisering

Å tillate svake passord, å være åpen for ubegrensede påloggingsforsøk, å lagre sesjons-ID-er usikkert eller å ikke avslutte sesjonen ved utlogging hører til denne kategorien.

Tiltak: begrens antall forsøk, tilby tofaktorautentisering, sjekk mot lister over lekkede passord og sett sesjonsinformasjonskapsler med egenskapene HttpOnly, Secure og SameSite.

068–10. Integritet, logging og SSRF

Integritet i programvare og data

Hvis oppdateringer, utvidelser eller den automatiske utrullingskjeden kjøres uten verifisering, åpner det døren for angriperen. Signerte pakker, pålitelige kilder og kontroll av forsyningskjeden er grunnlaget for tiltaket.

Mangelfull logging og overvåking

Hvis et angrep ikke oppdages, vokser skaden. Mislykkede pålogginger, tilgangsfeil og kritiske handlinger bør logges, og det bør lages varsler ved uvanlige situasjoner. Sensitive data som passord må ikke skrives til loggene.

SSRF

SSRF (Server-Side Request Forgery) er at serveren tvinges til å sende en forespørsel til en adresse som kommer fra brukeren. På denne måten kan angriperen nå tjenester i det interne nettverket. Det grunnleggende tiltaket er å bruke en tillatelsesliste for adressene det er lov å kontakte.

07Sjekkliste for sikker koding

De fleste hull kan forebygges med noen få grunnleggende vaner. Du kan bruke listen under i kodegjennomganger og kontroller før lansering. Hvordan testprosesser henger sammen med sikkerhet har vi tatt for oss i artikkelen Hva er programvaretesting.

1. Stol aldri på inndata: valider all inndata på serversiden.
2. Bruk forberedte spørringer: ikke bygg SQL ved å sette sammen tekst.
3. Escape utdata: etter HTML-, URL- og JavaScript-kontekst.
4. Sjekk tilgang ved hver forespørsel: det holder ikke å skjule noe i grensesnittet.
5. Hold hemmeligheter utenfor koden: nøkler hører hjemme i miljøvariabler eller et hvelv.
6. Hold avhengigheter oppdatert: kjør revisjonskommandoen jevnlig.
7. Logg og overvåk: legg merke til mistenkelige hendelser.

08Hva sikre språk og verktøy bidrar med

Noen typer hull kan også reduseres gjennom valg av språk og verktøy. For eksempel hindrer språk med minnesikkerhet i stor grad minneoverflyt, som er vanlig i C og C++; dette har vi tatt for oss i artikkelen Hva er Rust. WebAssembly, som kjører i en sikker sandkasse i nettleseren, bygger på en lignende isolasjonslogikk.

Likevel løser ikke noe språk av seg selv feil i tilgangskontroll eller design. Mesteparten av sikkerheten i nettapplikasjoner avhenger av teamets vaner og prosesser.

Hos Aurora Yazılım brukes disse grunnprinsippene som en del av utviklingsprosessen i prosjekter for bransjeprogramvare, bedriftsnettsider og nettbutikkplattformer.