OWASP har lavet 10 design principper når det kommer til hvordan man skal kode ens app til at være en sikker app for alle. Jeg kommer til at gennemgå dem her i dette blog indlæg. Hvor jeg har brugt OWASP samt en artikel fra Patchstack.com som source. Artiklen fra Patchstack er skrevet ud fra hvad OWASP har skrevet.
Asset Clarification
Før man kan begynde og lave ens sikkerheds strategier, er det nødvendigt at man finder ud af hvilken type data som ens app skal håndtere. OWASP vil gerne have programmørene til at oprette sikkerheds protokollerne rigtigt i forhold til den type data, som skal håndteres. En applikation som har med det finansielle at gøre skal f.eks. have en strengere sikkerheds protokol, end en simpel blog eller web forum.
Understanding attackers
Programmøre skal designe sikkerheds protokoller der er til for at undgå misbrug fra forskellige fronter, disse kan inkludere (fra mest til mindst farlig):
- Sure medarbejdere og udviklere
- Drive-by angreb som ligger virus eller trojanske heste ind i systemet
- Motiverede hackere
- Kriminale organisationer
- Script kiddies (en som bruger eksisterende scripts og kode til at hacke sig ind på et system, kan ikke skrive hacks selv)
Den farligste type af angreb kan komme fra utilfredse medarbejdere eller udviklere, grundet de har langt større adgang til systemet, og derfor kan forvolde større skade på dette.
Core pillars of information security
OWASP anbefaler at alle sikkerheds protokoller bliver lavet ud fra nøgle stenene indenfor informations sikkerhed. Disse er:
- Confidentiality (fortrolighed) – Lad kun brugere tilgå den data som de skal bruge
- Integrity (integritet) – Sikre at data ikke bliver ændret af uautoriserede brugere
- Availability (tilgængelighed) – Sikre at systemer og data er tilgængelig for autoriserede brugere når de har brug for det
Security architecture
OWASP anbefaler at alle applikationer har nogle sikkerheds protokoller designet til at håndtere alle former for risici, detter kan være typiske brugs risici (data sletning) til ekstreme angreb (brute-force, injection).
De anbefaler at udviklere ser på hver feature af applikationen de er ved at designe og spørger sig selv følgende spørgsmål:
- Er processen omkring denne feature så sikker som muligt? Er det en fejlet process?
- Hvis jeg var ond, hvordan ville jeg så misbruge denne feature?
- Er denne feature nødvendig at have til som standard? Hvis den er, er nogle limiters eller indstillinger der kunne hjælpe med at reducere risikoen fra denne feature?
Ved at “tænke ondt” kan en udvikler identificere måder cyberkriminelle og andre individer kan angribe ens applikation. OWASP anbefaler at udviklere bruger STRIDE/DREAD til at modelere trussels risikoer.
Security principles
1. Minimize attack surface area
Hver gang der bliver tilføjet en ny feature til en app, stiger risikoen for sikkerheds svagheder. Dette princip minimere størrelsen på et angreb, ved at begrænse hvilke funktioner en bruger kan tilgå, som reducere de potentielle svagheder.
F.eks. kan man kode en search bar feature ind i ens applikation, men hvis man ikke koder den rigtigt, er denne feature en potentiel adgang til SQL injection angreb. En udvikler kunne limitere denne funktion, så det kun var muligt for registrerede brugere at bruge.
2. Establish secure defaults
Dette princip omhandler at ens applikation skal være sikker som standard. En bruger skal tage initiativ til at få flere privilegier eller fjerne sikkerhedsforanstaltninger (hvis der gives lov til dette). At have en sikker standard betyder at der skal være stærke regler for hvordan en bruger registrere sig, hvor ofte der skal skiftes passwords, samt hvor komplekse disse skal være, osv.
Der skal være et højt niveau af sikkerhed fra starten, men der kan gives lov til at brugere kan fjerne disse.
3. The Principle of Least Privilege
Principle of Least Privilege (POLP), eller princippet om mindste privilegium, betyder at en bruger skal have det mindste sæt privilegier for at lave et given stykke arbejde.
POLP kan bruge overalt i en applikation, inklusiv bruger rettigheder og adgang til resourcer. Et eksempel kan være: En bruger er logget ind i en blog app som “forfatter”, så burde denne bruger ikke have adgang til at tilføje eller fjerne andre brugere. Denne burde kun have rettigheder til at lægge artikler op.
4. The principle of Defence in depth
Dette princip omhandler at flere sikkerhedsforanstaltninger der sikre risikoer på forskellige måder, er den bedste måde at sikre en applikation.
Så i stedet for at have en sikkerhedsforanstaltning for login, vil der være flere lag af validering, revisionsværktøjer og logningsværktøjer. Så i stedet for at lade en bruger logge ind, kun med brugernavn og password, så vil man også kunne bruge et IP-tjek, et Captcha system, logning af deres login forsøg, brute-force detektering, osv.
5. Fail securely
En applikation kan fejle på mange måder. Måske database forbindelsen fejlede, eller inputtet fra brugeren var forkert.
Men dette princip siger at en applikation skal fejle på en sikker måde. Fejl skal ikke give brugeren flere privilegier, og der skal ikke vises sensitiv information til brugeren, som queries fra databasen, eller logs.
6. Don’t trust services
Mange applikationer bruger tredje-parts services for at tilføje mere funktionalitet eller få mere data fra brugerne. Dette princip omhandler at man aldrig skal stole på disse services fra et sikkerheds perspektiv.
Dette betyder at applikationen altid skal sikre validiteten af data som tredje-parts servicen sender, og ikke give disse services flere rettigheder i applikationen end nødvendigt.
7. Separation of duties
Adskillelse af pligter kan bruges til at undgå individer fra at bedrageri. F.eks. skal en bruger af en eCommerce hjemmeside ikke forfremmes til en administrator, da de derfor vil have mulighed for at ændre ordre samt give sig selv flere produkter.
Det modsatte er også gældende – een administrator skal ikke have muligheder for at gøre ting som en køber kan, som at bestille ting fra front-end af applikationen.
8. Avoid security by obscurity
Dette princip omhandler uklar sikkerhed aldrig skal være en del af ens app. Hvis ens app skal gemme administrations URL for at den kan forblive sikker, så er en slet ikke sikker. Der skal være nok foranstaltninger til at holde en app sikker, uden at gemme kerne funktionalitet eller source code.
9. Keep security simple
Udviklere burde undgå brugen af meget sofistikeret arkitektur når der udvikles sikkerhedsforanstaltninger til applikationen. Hvis der er komplekse mekanismer til stede, kan det øge risikoen for fejl.
10. Fix security issues correctly
Hvis der er fundet en sikkerheds problematik i en app, skal udviklere finde roden til problemet.
Derefter skal de reparere og teste dette igennem. Hvis applikationen bruger design mønstre, er det stor sandsynlighed for at denne fejl er tilstede i flere systemer. Udviklerne skal sikre sig at alle systemerne som er ramte er identificeret.
Dette er et kort skriv om security by design, og Nolek har bedt mig om at skrive en one-page, som de kan bruge i deres egent udviklings team. Så dette er også noget jeg vil prøve at designe i nærmeste fremtid.