Sikkerhet - ScrumTeam2/MinVakt GitHub Wiki

Vi har forholdt oss til sikkerhetsanbefalingene til OWASP, mer nøyaktig deres topp 10-liste over sikkerhetsrisikoer.

A1 - Injection

Vårt system kjører spørringer opp mot en MySQL-tjener, og vi kan da være eksponert for A1.

  • Det er kun DBManager-klassene i backend-koden vår som har direkte tilgang til databasen
  • Vi har sørget for at alle spørringer mot databasen blir kjørt gjennom prepared statements (PreparedStatement), der all inndata er pakket inn i parametre. Ved dette sikrer vi oss mot alt av forutsigbare SQL-injeksjoner. Vårt system kjører ingen andre typer kommandoer som kan eksponeres for slike injeksjoner.

A2 - Broken Authentication and Session Management

Vårt system inkluderer brukerinnlogging og sesjoner, og vi kan da være eksponert for A2.

  • Våre passord oppfyller kravet definert i visjonsdokumentet (Dette blir validert både client-side og server-side)
  • Passordene blir hashet sammen med en salt, og kun hash og salt lagres i database
  • Vi bruker Java EEs innebygde sesjonshåndtering, dvs. det lages en JSESSIONID-cookie som ikke kan aksesseres fra JavaScript (HttpOnly)
  • Sesjoner har utløpstid, både client-side (sessionStorage) og server-side
  • Når en bruker logges ut, slettes sesjonstokenen

A3 - Cross-Site Scripting (XSS)

Vårt system tar inn inndata fra brukere, og vi kan da være eksponert for A3.

  • Servleten er stilt inn til å legge til HTTP-headere som instruerer nettlesere til å filtrere XSS-forsøk (OWASP-headere)
  • Alle strenger som sendes til REST-endpointene blir filtrert for HTML

A4 - Insecure Direct Object References

Vårt system har REST-endpointer som inneholder reelle navn/nøkler, og vi kan da være eksponert for A4.

  • Alle REST-endpoints sjekker om klienten har tilstrekkelig autorisasjon for å få tilgang til ressursen. En bruker vil derfor ikke kunne manipulere URL for å få tilgang til ressursen ment for andre
  • Hvis en bruker skal aksessere noe som har direkte tilkobling til en selv, bestemmes dette av sesjonen, og ikke inndata. Et eksempel er REST-kallet for å få egne vakter: Det er /shift, og ikke /shift/{minId}

A5 - Security Misconfiguration

Så og si alle system er eksponert for A5, og vårt system er ikke mer enn andre.

  • Vi har prøvd å bruke oppdaterte versjoner av alle våre Maven-avhengigheter
  • I produksjonsmiljø ville man ha skrudd av utviklingsfunksjoner som f.eks. stacktrace i nettleser

A6 - Sensitive Data Exposure

__Vårt system lagrer ikke noen sensitiv informasjon. For passord, se A2

  • I produksjonsmiljø ville systemet kjørt med SSL over HTTPS

A7 - Missing Function Level Access Control

Se A4 punkt nr. 2

A8 - Cross-Site Request Forgery (CSRF)

__Vi har ikke implementert noen form for CSRF-token, da dette kan være omfattende

A9 - Using Components with Known Vulnerabilities

  • Vi har prøvd å bruke oppdaterte versjoner av alle våre Maven-avhengigheter

A10 - Unvalidated Redirects and Forwards

Vårt system har ikke redirect/forward som kan bestemmes direkte av inndata, og er derfor sikret for disse typer angrep.