Marcus's 4. Semester Portfolio

Noter til OWASP top-10

Posted on

Dette er en samling af noter som er skrevet ud fra OWASP’s top-10 over de mest hyppige sikkerhedsfejl i webudvikling. Denne samling er skrevet ud fra deres top-10 lavet i 2021, så der kan være sket nogle ændringer i de 2 år der er gået fra den udkom til nu.

OWASP bruger en forkortelse, CWE, som betyder Common Weakness Enumerations, til at beskrive de forskellige former for fejl og angreb.

Broken Access Control

Denne fejl er flyttet op fra en 5. Plads i forhold til den survey som blev lavet tidligere. Ud af alle applikationer som blev testet, blev 94% testet for Broken Access Control, hvor der ud af denne mængde blev fundet at dette var muligt i 3,81%. 

Af bemærkelsesværdige CWE’s inkludere Broken Access Control følgende:

CWE-200: Exposure of Sensitive Information to an Unauthorised Actor

CWE-201: Insertion of Sensitive Information Into Sent Data

CWE-352: Cross-Site Request Forgery

Access Control er noget man implementerer og håndhæver for at brugere ikke kan gøre noget som de normalt ikke vil have adgang til. Fejl på dette fører typisk til uautoriseret information bliver lækket, modificering eller destruktion af alt data, eller man udfører funktioner som ligger uden for brugerens rettigheder. Svagheder som bliver associeret med BAC inkludere:

  • Krænkelse af princippet af færrest privilegier (principle of least privilege), eller forbud som standard (deny by default), hvor adgang kun skal gives til de rette personer eller roller, men som er tilladt af alle.
  • Skippe adgangskontrol ved at modificere URL, internt applikations stadie, eller HTML siden, eller ved at bruge et værktøj til at modificere API forespørgsler.
  • At give lov til at se eller redigere en anden bruger, ved at give brugerens unikke id. (insecure direct object references)
  • Have adgang til en API med manglende adgangskontrol for POST, PUT og DELETE.
  • Øgning af ens privilegier. Adgang som en almindelig bruger når man ikke er logget ind, eller som admin når man er logget ind.
  • Metadata manipulation, som kan være når man genspiller eller manipulere med et JWT-adgangskontrol token, eller en cookie, eller manipulere med et skjult field til at give højere privilegier, eller misbruge JWT ugyldiggørelse.
  • Forkert konfiguration af CORS, som giver adgang til API fra uautoriserede/upålidelige kilder.
  • Forced browsing til autoriserede sider som en uautoriseret bruger, eller til privilegerede sider som en normal bruger.

Hvordan kan man undgå BAC? Adgangskontrol er kun effektiv i et miljø hvor det kører på troværdig server-side kode, eller hvis det er en server-less API, hvor en angriber ikke kan modificere adgangskontrol tjekket eller metadata.

  • Medmindre det er offentlige ressourcer, skal deny by default være standarden.
  • Implementer adgangskontrol mekanismer en gang og genbruge dem igennem hele ens applikation, dette inkluderer minimering af brugen af CORS.
  • Adgangskontrolmodeller skal håndhæve ejerskab i stedet for at acceptere at brugeren kan oprette, læse, opdatere eller slette alt.
  • Logging adgangskontrol fejl, og give admins besked ved flere forkerte indtastninger i streg.
  • Limiter API og controller adgang for at minimere skaden fra automatiserede angrebs værktøjer.
  • Stateful sessions id skal invalideres på serveren efter logout. Stateless JWT tokens skal have kort levetid så vinduet for angreb er så lille som muligt. For JWT tokens med længere levetid, er det anbefalet at bruge OAuth standarder til at fjerne adgang.

Udviklere og QA-ansatte skal gerne inkludere funktionelle adgangskontrol unit og integrations tests.

Cryptographic Failures

Dette er flyttet op fra en tredjeplads til en andenplads, og var tidligere kendt som Sensitive Data Exposure, hvilket var mere et bredt symptom end en hovedårsag, med fokus på fejl som er relateret til kryptografi, eller manglen derpå, hvilket ofte leder til visning af sensitivt data. CWE’s som ofte relatere til dette emne kan der nævnes:

  • CWE-259: Use of Hard-coded Password
  • CWE-327: Broken or Risky Crypto Algorithm
  • CWE-331: Insufficient Entropy

Det første man skal beslutte, er hvor meget beskyttelse som data der er undervejs, eller data som ligger, stille skal have. F.eks. Skal passwords, kreditkortnumre, sundhedsjournaler, personlig information, samt forretningshemmeligheder skal have ekstra beskyttelse, primært hvis denne data falder under dvs. Privatlivs love, som kan være GDPR, eller PCI DSS (PCI Data Security Standard, som er en financiel data beskyttelses regulering). For alt data kan følgende gælde:

  • Er der data der bliver sendt i klar tekst? Dette har betydning for nogle protokoller som HTTP, SMTP, FTP som også bruger TLS opgraderinger som STARTTLS. Ekstern internet trafik er farligt. Sikre alt internt trafik, mellem web servere eller back-end systemer.
  • Er der nogle gamle eller svage kryptografiske algoritmer eller protokoller brugt i enten standard eller gammel kode?
  • Er der standard krypto nøgler i brug, svage krypto nøgler genereret eller genbrugt, eller er der ordentlig nøgle management eller rotation manglende? Er krypto nøgler opdateret i source kode repositories?
  • Er kryptering ikke tvunget, dvs. Er der nogle HTTP header sikkerhedsregler, eller headers som mangler?
  • Er det modtagende server certifikat og trustkæden blevet ordentligt valideret?
  • Er initialiserings vektorer ignoreret, genbrugt eller ikke genereret nok sikkert for brug? Er der en ikke sikker måde at operere i brug, det kan være ECB? Er kryptering brugt, når authenticated kryptering vil være bedre?
  • Bliver passwords brugt som kryptografiske nøgler hvis der mangler en password base key derivation funktion?
  • Bliver randomness brugt til kryptografiske formål, der ikke var designet til at imødekomme de kryptografiske krav? Selv hvis den korrekte funktion er brugt, skal den først seedes af udvikleren, eller hvis ikke, har udvikleren overskrevet den stærke seeding funktionalitet som er indbygget i funktionen, med et seed som mangler nok entropy/uforudsigelighed?
  • Bliver der brugt forældede hashing funktioner som MD5 eller SHA1, eller bliver der brugt ikke-kryptografiske hashing funktioner når kryptografiske hashing funktioner skal bruges?
  • Bliver der brugt forældede padding metoder som PKCS-nummer 1 v1.5?
  • Er kryptografiske fejlbeskeder, eller side-channel information udnyttelig, f.eks. I form af padding oracle angreb?

Man skal som minimum gøre følgende:

  • Klassificer data der bliver processeret, gemt og sendt fra en app. Identificer hvilket data som følsomt i forhold til privatlivs love, reguleringer eller forretningsbehov.
  • Lad være med at gemme følsomt data som ikke skal bruges. Slet det så snart det er muligt eller brug PCI DSS kompatibel tokens eller truncation. Data som ikke bliver gemt kan ikke stjæles! 
  • Krypter følsomt data i databasen.
  • Dobbelt tjek at alle algoritmer, protokoller og nøgler er up-to-date og stærke; brug ordentlig nøgle håndtering.
  • Krypter alt data der er undervejs med sikre protokoller som TLS med FS (forward secrecy) ciphers, cipher prioritering af serveren, samt sikre parametre. Tving kryptering ved brug af direktiver som HSTS (HTTP Strict Transport Security).
  • Fjern caching for svar der indeholder følsomme data.
  • Brug påkrævet sikkerhedskontroller i forhold til data klassifikationen.
  • Lad være med at bruge gamle protokoller som FTP og SMTP til transport af følsomt data.
  • Gem passwords med brug af stærk adaptive og saltede hashing funktioner med en arbejds faktor (delay faktor), som Argon2, scrypt, bcrypt eller PBKDF2.
  • Initiation vektorer (IV) skal vælges med omhu. Til mange forhold, betyder dette at der skal bruges CSPRNG (Cryptographically Secure Pseudo Random Number Generator). Hvis der bruges en nonce, skal IV’en ikke bruge en CSPRNG. Men i alle tilfælde skal IV’en ikke genbruges to gange for en fast nøgle.
  • Altid brug autentificeret kryptering i stedet for kun kryptering.
  • Nøgler skal genereres kryptografisk tilfældigt og gemmes i hukommelse som et bytearray. Hvis der bruges et password, skal det konverteres til en nøgle via en password base key derivation funktion.
  • Dobbelttjek at kryptografisk tilfældighed bliver brugt hvor det er nødvendigt, som det ikke er blevet seeded i en forudsigelig måde eller med lav entropy. De fleste moderne API’er skal ikke bruge udvikleren til at seede CSPRNG for at få sikkerhed.
  • Lad være med at bruge forældede kryptografiske funktioner og padding schemes, som MD5, SHA1, PKCS-nummer 1 v1.5.
  • Uafhængigt verificerer effektiviteten af konfigurationen og indstillingerne.

Injection

Injection angreb går to pladser ned til en tredjeplads fra førstepladsen i 2017. 94% af applikationerne til test blev testet mod en eller anden form for injection, hvor det blev fundet muligt at lave 274.000 gange. CWE’er som er inkluderet i injection er:

CWE-79: Cross-Site Scripting

CWE-89: SQL Injection

CWE-73: External Control of File Name or Path

OWASP valgte at inkludere XSS angreb sammen med Injektion i denne top-10, i 2017 var de hver for sig.

En applikation er sårbar mod injection angreb når:

  • Bruger indtastet data ikke bliver valideret, filtreret eller saniteret af applikationen.
  • Dynamiske forespørgsler eller ikke-parametriserede kald uden context-aware escaping bliver brugt direkte i oversætteren.
  • Fjendtligt data som bliver brugt inden i object-relational mapping (ORM) søgeparametre til at udtrække flere sårbare arkiveringer.
  • Fjendtligt data der bliver direkte brugt eller tilføjet. SQL’en eller kommandoen indeholder struktur og skadeligt data i dynamiske forespørgsler, kommandoer, eller stored procedures.

Nogle af de mest hyppige injections er SQL, NoSQL, OS command, ORM, LDAP, og Expression Language (EL) eller Object Graph Navigation Library (OGNL) injection. Konceptet er det samme mellem alle oversætterne. Source Code review er den bedste måde at finde ud af om ens applikation er sårbar over for injection. Automatiseret testning af alle parametre, headers, URL, cookies, JSON, SOAP og XML-data inputs bliver stærkt anbefalet. Organisationer kan inkludere statisk (SAST), dynamisk (DAST), og interaktiv (IAST) application security testning værktøjer i ens CI/CD-pipeline til at identificere introducerede injection fejl inden deployment.

Man kan undgå injektion ved at holde data væk fra kommandoer og forespørgsler:

  • Den anbefalede mulighed er at bruge en sikker API, som undgår at bruge oversætteren helt, giver et parameterized interface, eller migrere til Object Relational Mapping Tools (ORMs). 

Selv når det er parametriseret, stored procedurer kan stadig introducere SQL injection hvis PL/SQL eller T-SQL sammensætter forespørgsler og data eller eksekver fjendtligt data med EXECUTE IMMEDIATE eller exec().

  • Brug positive server-side input validering. Dette er ikke en komplet beskyttelse, da mange applikationer bruger specielle karakterer, som tekst områder eller API’er for mobile applikationer.
  • For resterende dynamiske forespørgsler, ‘escape’ specielle karakterer ved at bruge den specifikke ‘escape’ syntax for ens oversætter.

SQL-strukturer som tabel navne, kolonnenavne osv. kan ikke blive ‘escaped’, og derfor er bruger-indtastet struktur navne farlige. Dette er en fejl som ofte er i rapport-skrivnings software.

  • Brug LIMIT og andre SQL-kontroller i forespørgsler til at undgå masse afsløring af arkiveringer hvis der sker SQL injection.


Insecure Design

Dette er en ny kategori for OWASP i deres 2021 opgørelse, og denne fokuserer på design og arkitektur fejl, for at få udviklere til at bruge mere tid på trussels modellering, sikre design mønstre og referencearkitekturer. Som et fællesskab skal vi arbejde mod at bevæge os videre fra “shift-left” i kodningsrummet til pre-code aktiviteter som er kritiske for principperne for Secure by Design. Af CWE’s som ligger under dette emne er:

CWE-209: Generation of Error Message Containing Sensitive Information

CWE-256: Unprotected Storage of Credentials

CWE-501: Trust Boundary Violation

CWE-522: Insufficiently Protected Credentials

Insecure design er en bred kategori som indeholder forskellige svagheder, som giver udtryk for “manglende eller ineffektiv kontrol design”. Insecure design inkluderer ikke alle de andre top 10 kategorier.
Der er en forskel mellem usikker design og usikker implementation. OWASP differentiere mellem design fejl og implementeringsfejl af en grund, der er forskellige hovedårsager og løsninger. Et sikkert design kan stadig have fejl i implementeringen, som kan være årsag til svagheder der kan udnyttes. Et usikkert design kan ikke reddes af en perfekt implementering per definition, de sikkerhedskontroller der skal bruges, er ikke blevet lavet til at beskytte mod specifikke angreb. En af faktorerne der bidrager til usikker design, er manglen på risikovurdering af software eller systemet som bliver udviklet, og man fejler derfor i vurderingen af hvilket niveau af sikkerheds design der er nødvendigt.

Indsaml og vurdere virksomhedens krav til en applikation, som indeholder beskyttelses krav indenfor fortrolighed, integritet, tilgængelighed og autencitet for alt data, og den forventede forretnings logik. Man skal tage i mente hvor udsat ens applikation vil være, samt hvis man skal segregere ens brugergrupper (sammen med access control). Kompilere de tekniske krav, inklusiv funktionelle og ikke funktionelle sikkerhedskrav. Planlæg at forhandle om budgettet over alt design, bygning, testning og operation, inklusiv sikkerheds aktivitet.

Sikker design er en kultur og en metode der konstant evaluerer trusler og sikrer at ens kode er robust designet og testet for at forhindre kendte angrebsmetoder. Trusselmodellering bør være integreret i videre udviklings sessioner (eller lignende aktiviteter); se efter ændringer i data flows- og adgangskontrol eller andre sikkerhedskontroller. I userstoryudviklingen fastlæg det korrekte flow og fejlstadier, sikre dig at de er vel forstået og alle parter har godkendt dem. Analysere antagelser og betingelser for hvad der er forventet samt fejl flows, sikre at de stadig er rigtige og ønskeligt. Bestem hvordan antagelserne skal valideres, og håndhæv betingelserne som er nødvendige for rigtig opførsel. Sikre at resultaterne er dokumenteret i user stories. Lær af fejl og tilbyd positive incitamenter til at fremskynde forbedringer. Sikker design er hverken en add-on eller et værktøj, man kan tilføje til software.

Sikker software kræver en sikker udviklings livscyklus, en form for sikker design mønster, en “paved road” metode, et sikkert komponentbibliotek, værktøjer og trussel modellering. Tag kontakt til en sikkerhedsspecialist i begyndelsen af softwareprojektet og hele vejen igennem, samt ved vedligeholdelse af software. Man kan evt. bruge OWASP’s Software Assurance Maturity Model (SAMM) til at strukturere ens sikker softwareudviklings indsats.

Hvordan kan man undgå:

  • Opret og brug en sikker udviklings livscyklus med AppSec professionelle, der kan hjælpe med at evaluere og designe sikkerheds- og privatlivsrelaterede kontroller.
  • Opret og brug et bibliotek af sikre design mønstre eller “paved road” klar til brug komponenter.
  • Brug trussels modellering for kritisk godkendelse, adgangskontrol, forretnings logik og nøgle flows.
  • Integrere sikkerhed sprog og kontroller i user stories
  • Integrere plausibilitets tjeks i hvert trin af applikationen (fra frontend til backend).
  • Skriv unit og integrations tests til at validere at alle kritiske flows er resistente overfor trusselsmodellen. Kompiler use-cases og misuse-cases for hvert trin i applikationen.
  • Adskil trin lag på system og netværks lag når det kommer til kravene omkring hvor udsat de er, samt hvilken beskyttelse de skal bruge.
  • Adskil brugergrupper robust by design igennem alle trin.
  • Limiter ressourceforbruget af brugere og services.

Security Misconfiguration

Rykker en plads op siden 2017, 90% af alle applikationer, der blev testet, blev testet for en form for miskonfiguration, med over 208.000 forekomster af en CWE i denne kategori. Med flere skift til høj konfigurerbar software, er det ikke overraskende at se denne kategori stige i ranken. Af bemærkelsesværdige CWE’s kan der nævnes:

CWE-16: Configuration

CWE-611: Improper Restriction of XML External Entity Reference

Ens applikation kan være sårbar hvis:

  • Manglende nødvendige sikkerheds hærdning over enhver del af applikations stacken, eller forkert konfigurerede adgange på cloud services.
  • Overflødige features som er aktiveret eller installeret (overflødige porte, services, sider, brugere eller privilegier).
  • Default brugere og passwords som stadig er aktive og uændret.
  • Fejl håndtering løfter sløret for stack traces eller andre ekstremt informative fejl beskeder til brugere.
  • For opgraderede systemer, de seneste sikkerhedsfunktioner er deaktiveret eller ikke konfigureret sikkert.
  • Sikkerhedsindstillingerne i applikationsserverne, applikationsframeworks (Struts, Sprint, ASP.NET), biblioteker, databaser osv., er ikke sat til at sikre værdier.
  • Serveren sender ikke sikkerheds headers eller directives, eller de er ikke sat til at sikre værdier.
  • Software er out of date eller sårbar (Evt. læs næste kapitel).

Sikker installations processor skal implementeres, inklusiv:

  • En gentagelig hærdningsproces gør det hurtigt og nemt at indsætte et andet miljø, der er passende lukket ned. Udviklings, QA og produktionsmiljøer bør alle være konfigureret identisk, med forskellige legitimationsoplysninger til brug i hvert miljø. Denne proces bør være automatiseret for at minimere indsatsen, der er nødvendig for at opsætte et nyt miljø.
  • En minimal platform uden nogle overflødige funktioner, komponenter, dokumentation og samples. Fjern eller lad være med at installere features og frameworks som ikke bliver brugt.
  • En opgave at gennemgå og opdatere konfigurationerne passende til alle sikkerheds notater, opdateringer og patches som en del af patch management processen (Se evt. næste kapitel). Gennemgå cloud storage tilladelser.
  • En segmenteret applikations arkitektur giver effektiv og sikker separation mellem komponenter eller bruger gruppe, med segmentation, containerization eller cloud sikkerheds grupper (ACL’s).
  • At sende sikkerheds direktiver til klienter, dvs. security headers.
  • En automatiseret proces til at effektivisere konfigurationen og indstillingerne i alle miljøer.

Vulnerable and Outdated Components

Dette var nummer 2 fra den survey som er blevet lavet fra OWASP’s community, men der var også nok data til at den ville nå på den officielle top-10-liste. Sårbare komponenter er svært for OWASP at teste og finde risiko ved, og det er den eneste kategori som ikke har nogen CVE’er inkluderet i dens CWE’er. De bemærkelsesværdige CWE’er som er inkluderet i denne kategori er:

CWE-937 og CWE-1035 – Using Components with Known Vulnerabilities

CWE-1104 – Use of Unmaintained Third-Party Components

Man er sandsynligvis sårbar hvis:

  • Hvis man ikke kender versionerne af alle komponenter i brug (både client-side og server-side). Dette inkluderer komponenter man bruger direkte, men også som nested dependencies.
  • Hvis software er sårbar, usupporteret eller out of data. Dette inkluderer OS, web/application server, database management system (DBMS), applikationer, API’er og alle komponenter, runtime miljøer og biblioteker.
  • Hvis man ikke scanner for sårbarheder regulært eller abonnere på sikkerhedsinformationer relateret til de komponenter man bruger.
  • Hvis man ikke fikser eller opgraderer en underliggende platform, frameworks og dependencies på en risiko eller tidsmæssig måde. Dette sker typisk i miljøer, der patcher på en månedlig eller kvartalsmæssig basis, hvilket gør at organisationer er åbne for sårbarheder i dage eller måneder.
  • Hvis softwareudviklere ikke tester kompatibiliteten af opdaterede, opgraderede eller patchede biblioteker
  • Hvis man ikke sikre komponenternes konfiguration (Se delen om Security misconfiguration).

Der burde være en patch management process for at forhindre:

  • Fjerne ubrugte dependencies, unyttige funktioner, komponenter, filer og dokumentation.
  • Kontinuerligt lager versionerne af både client-side og server-side komponenter (frameworks, biblioteker osv.) og deres dependencies ved brug af værktøjer som versionering, OWASP Dependency Check, retire.js, osv. Kontinuerligt monitorere sources som Common Vulnerability and Exposures (CVE) og National Vulnerability Database (NVD) for sårbarheder i komponenter. Brug software analyse værktøjer for at automatisere processen. Abonner på e-mail alarmer for sikkerheds svagheder der relaterer til de komponenter man bruger.
  • Kun få komponenter fra officielle kilder over sikre forbindelser. Fortræk signed packages for at reducere chancen for inklusionen af modificerede, skadelige komponenter (se afsnittet om Software and Data Integrity Failures).
  • Monitorere for biblioteker og komponenter der ikke bliver maintained eller som ikke laver sikkerhedspatches for gamle versioner. Hvis patching ikke er muligt, overvej at udgive en virtuel patch for at monitorere, finde eller beskytte mod de fundne fejl.

Enhver organisation bør sikre sig at der er en plan for monitorering, sortering, og installere opdateringer eller ændre konfigurationen for applikationens livstid eller portfolio.

Identification and Authentication Failures

Denne sårbarhed er tidligere kendt som Broken Authentication, og har sidst lagt på 2. Pladsen, men nu på en 7. Plads, og inkludere nu CWE’er som relaterer til identifikation fejl. Af CWE’er som er inkluderet i dette emne er:

CWE-297: Improper Validation of Certificate with Host Mismatch,

CWE-287: Improper Authentication,

CWE-384: Session Fixation.

Denne sårbarhed omhandler brugerens identitet, authentication og session management, som er kritisk for at beskytte mod authentication relaterede angreb. Der er måske authentication svagheder hvis applikationen:

  • Tillader automatiserede angreb som credential stuffing, hvor en angriber har en liste af valide brugernavne og kodeord.
  • Tillader brute force eller andre automatiserede angreb.
  • Tillader standard, svage, eller ofte brugte kodeord, som Password1 eller “admin/admin”.
  • Bruger svage eller ineffektive legitimationsoplysnings genopretning og glemt-password-processer, som “videns-baserede svar”, hvilket ikke kan laves sikkert.
  • Bruger plain text, krypteret, eller svagt hashet password databaser (se evt. Cryptographic Failures).
  • Har manglende eller ineffektive multi-factor authentication.
  • Viser session identifikation i URL.
  • Genbruger session identifikation efter succesfuldt login.
  • Invalidere ikke session Id’et korrekt. User sessions- eller authentication tokens (primært single sign-on (SSO) tokens) er ikke invalideret rigtigt efter logout eller efter en periode med inaktivitet.

Det er muligt at forebygge mod dette ved at:

  • Hvor det er muligt, implementer multi-factor authentication for at forebygge automatiseret credential stuffing, brute force, og stolen credential reuse angreb.
  • Ship eller deploy ikke en app med default credentials, især for admin brugere.
  • Implementer svage password checks, som at teste nye eller ændrede passwords mod top 10.000 listen over værste passwords.
  • Juster password længde, kompleksitet og password skift til NIST (National Institute of Standards and Technology) 800-63b guide linjer i sektion 5.1.1 for “Memorized Secrets or other modern, evidence-based password policies”.
  • Sikre registrering, legitimationsoplysnings genopretning, og API stiger er hærdet mod account enumeration angreb ved at bruge den samme besked for alle hændelser.
  • Limiter eller øgende forsinke fejlede login forsøg, men vær sikker på ikke at lave et denial of service scenarie. Log alle fejl, og advar administratorer hvis credential stuffing, brute force eller andre angreb er påvist.
  • Brug server-side, sikre, built-in session manager der genererer et nyt tilfældigt session id med høj entropi efter login. Session id skal ikke vises i URL, være sikkert gemt og invalideret efter logout, stille eller absolutte timeouts.

Software and Data Integrity Failures

Dette er en ny kategori for 2021, som fokuserer på at lave antagelser som relaterer til softwareopdateringer, kritisk data, og CI/CD-pipelines uden at verificere integritet. En af de højest vægtede indvirkninger fra CVE/CVSS (Common Vulnerability and Exposure/Common Vulnerability Scoring System) data. Af CWE’er som er inkluderet her er:

CWE-829: Inclusion of Functionality from Untrusted Control Sphere,

CWE-494: Download of Code Without Integrity Check,

CWE-502: Deserialization of Untrusted Data.

Software og data integritets fejl relaterer til kode og infrastruktur som ikke beskytter mod integritetskrænkelser. Et eksempel her kan være hvis en applikation stoler på plugins, biblioteker, eller moduler fra utroværdige kilder, repositorier, og content delivery networks. En usikker CI/CD-pipeline kan introducere potentialet for uautoriseret adgang, farlig kode, eller system kompromisser. Til sidst inkluderer mange applikationer nu en auto-update funktionalitet, hvor opdateringer bliver downloadet uden nok integritets verifikation og bliver installeret til en tidligere troværdig applikation. Angribere kan potentielt uploade deres egne opdateringer til at blive distribueret og køre på alle installationer. Et andet eksempel er hvor objekter eller data er kodet eller serialiseret ind i en struktur som en angriber kan se og modificer, er sårbar overfor insecure deserialization.

Man kan undgå dette ved:

  • Bruge digitale signaturer eller lignende mekanismer for at verificere at software eller data er fra de forventede kilder og ikke er blevet ændret.
  • Sikre at biblioteker og dependencies, som npm eller Maven, bruger betroede repositorier. Hvis du har en high risk profil, overvej at hoste et internt godkendt repositorie.
  • Sikre at der er et software supply chain security værktøj, som OWASP Dependency Check eller OWASP CycloneDX, som bruges til at verificere at komponenter ikke har kendte sårbarheder.
  • Sikre at der er en review proces for kode og konfigurationsændringer for at minimere chancen for at farlig kode eller konfiguration ikke bliver introduceret til din software pipeline.
  • Sikre at din CI/CD-pipeline har ordentlig segregation, konfiguration og adgangskontroller for at sikre integriteten af koden, som flyder igennem bygge og deploy processen.
  • Sikre at usignerede og ukrypterede serialiseret data ikke er sendt til utroværdige klienter uden nogen form for integritets check eller digitale signaturer for at finde manipuleret data, eller replay af det serialiserede data.

Security Logging and Monitoring Failures

Denne sårbarhed er kommet fra Community Survey’en, hvor den fik en 3. Plads, hvilket er et lettere løft fra listen fra 2017 hvor den fik en 10. Plads. Logging og monitorering kan være svært at teste, og dette inkluderer ofte interviews eller at der bliver spurgt rundt om et angreb blev detekteret i løbet af en pentest. Der er ikke meget CVE/CVSS-data for denne kategori, men at detektere og reaktion til brud på sikkerheden er kritisk. Denne kategori udvider CWE-778 Insufficient Logging til at inkludere:

CWE-117 Improper Output Neutralization for Logs,

CWE-223 Omission of Security-relevant Information,

CWE-532 Insertion of Sensitive Information into Log File.

Denne kategori kan hjælpe med at finde, eskalere og reagere til aktive brud. Uden logging og monitorering kan brud ikke blive detekteret. For lidt logging, detektering, monitorering og aktiv reaktion finde sted når:

  • Reviderbare events, som login, fejlede login og transaktioner med høj værdi, er ikke loggede.
  • Advarsler og fejl genererer ingen, ikke nok eller uklare log beskeder.
  • Logs omkring applikationer og API’er er ikke monitoreret for mistænksom aktivitet.
  • Logs er kun lageret lokalt.
  • Fornuftige advarsels grænseværdier og svar eskalerings processer er ikke til stede eller effektive.
  • Pentesting og scanning af Dynamisk applikation sikkerheds testning (DAST) værktøjer, som f.eks. OWASP ZAP ikke aktiverer advarsler.
  • Applikationen kan ikke detektere, eskalere eller advare for aktive angreb i real-time eller nær real-time.

Man er sårbar i forhold til informations lækage ved at have logging of advarsels events visbare til brugere eller angribere (evt. Se afsnit 1, Broken Access Control).

Man kan undgå dette ved at implementere noget eller alt af følgende, kommer an på risikoen for applikationen:

  • Sikre at alt login, adgangskontrol og server-side input valideringsfejl kan logges med nok bruger kontext til at identificere mistænksomme eller onde brugere og de bliver lagret i lang nok tid til at lave forsinkede efterforskningsanalyser.
  • Sikre at logs er genereret i et format som log management software kan let håndtere.
  • Sikre at log data er kodet korrekt for at undgå injections eller angreb på logging eller monitoreringssystemerne.
  • Sikre at høj-værditransaktionerne har et revisionsspor med integritetskontroller for at undgå ændringer eller sletning, som append-only database tabeller eller lign.
  • DevSecOps teams bør etablere effektiv monitorering og advarsler så at mistænksomme aktiviteter bliver opdaget og der bliver reageret hurtigt.
  • Etablere eller adoptere en hændelses- og genopretningsplan, som NIST 800-61r2 eller senere version.

Der er kommercielle og open-source app beskyttelses frameworks som OWASP ModSecurity Core Rule Set, og open-source log korrelation software, som ElasticSearch, Logstash, Kibana (ELK) stack, som har custom dashboards og advarsler.

Server Side Request Forgery

Denne kategori er blevet tilføjet fra community survey’en hvor den fik en førsteplads. Data viser en relativt lav forekomst rate, med over middel testing dækning og over middel Exploit og Impact potentiale ratio. Som en ny kategori er der enkelte eller en lille gruppe af CWE’er for opmærksomhed, i håbet om at der kommer mere fokus på denne kategori, så den kan komme ind under en større kategori i fremtiden.

SSRF-svagheder kommer når en webapplikation henter fjern ressourcer uden at validere bruger indtastede URL. Dette giver en angriber lov til at tvinge applikationen til at sende requests til en uventet destination, selv når den er beskyttet af en firewall, VPN eller en anden type af netværks adgangskontrolliste (ACL).

En moderne webapplikation giver slutbrugerne praktiske funktioner, hvor fetching af en URL bliver et almindeligt scenarie. Dette betyder at forekomster af SSRF stiger. Alvorligheden af SSRF bliver højere i takt med at cloud services bliver mere almindelig, og kompleksiteten af app arkitektur bliver større.

Man kan undgå SSRF ved at implementere nogle eller alle af følgende dybde forsvars kontroller:

Netværks laget

  • Segmenter fjern ressource adgangs funktionalitet i separate netværk for at reducere indvirkningen af SSRF.
  • Tving “Deny by Default” firewall politiker eller netværks adgangskontrol regler for at blokere alt undtagen det essentielle intranet trafik.
    • Etabler ejerskab og en lifecycle for firewall regler baseret på applikationen.
    • Log alle accepterede og blokerede netværks flows i firewall’en (se evt. forrige kapitel over Security Logging and Monitoring Failures).

Applikationslaget

  • Saniter og valider alt bruger indtastede data
  • Tving URL skema, port og destinationer med en positiv tilladelsesliste
  • Send ikke rå svar til klienter
  • Fjern HTTP redirections
  • Vær opmærksom på URL-overensstemmelse for at undgå angreb som DNS rebinding og “Time of check, time of use” (TOCTOU) race conditions.

Man skal ikke mitigere SSRF med brugen af en deny liste eller regex. Angribere kan have en payload-lister, værktøjer og evner til at forbigå en deny liste.

Andre ting som man kan tilføje:

  • Man skal ikke deploy andre sikkerheds relevante services på fronten (dvs. OpenID osv.). Kontroller trafikken på disse systemer (Localhost osv.).
  • For frontends med dedikerede og overskuelige brugergrupper, brug netværks kryptering (VPN) på uafhængige systemer for at imødegå høje beskyttelseskrav.