Meny

SANS Topp 20 sikkerhetsproblemer i programvareapplikasjoner

  • Hoved
  • Annen
  • SANS Topp 20 sikkerhetsproblemer i programvareapplikasjoner

sans top 20 security vulnerabilities software applications

Prøv Instrumentet Vårt For Å Eliminere Problemer

Lær og forstå SANS topp 20 kritiske sikkerhetsproblemer i programvare med eksempler i denne veiledningen:

Ordet UTEN er ikke bare et vanlig ordbokord, heller det står for SysAdmin , Revidere , Nettverk , og Sikkerhet .

I denne opplæringen vil vi lære om SANS topp 20 sikkerhetssvakheter vi kan finne i programvare, og hva vi kan gjøre for å redusere det.

SANS sikkerhetsproblemer

Hva du vil lære:

SANs innvirkning på nettsikkerhetssamfunnet

I følge UTEN , den UTEN Institute ble etablert som en forsknings- og utdanningsorganisasjon. De forskjellige sikkerhetsprogrammene er veldig omfattende og har en positiv effekt på over 165 000 fagpersoner over hele verden.

Vi kan med rette si at med denne typen dekning fra SANS og annen positiv gjennomgang de får dem til å gjøre dem til de mest pålitelige og den klart største organisasjonen for InfoSec-opplæring og ulike sikkerhetssertifiseringer i verden.

hvordan blinke bios windows 10

Denne artikkelen vil fokusere på SANS topp 20 feil som kan gjøre programvaren din sårbar for angrep, og noen av sikkerhetskontrollene du kan implementere for å redusere disse feilene. Selv om vi kan finne mer enn 20, men vi vil diskutere de 20 største sårbarhetene.

Liste over SANS Topp 20 kritiske sikkerhetsproblemer i programvare

  1. CWE-119 : Memory Buffer Error
  2. CWE-79 : Skripting på tvers av nettsteder
  3. CWE-20 : Ugyldig inngangsfeil
  4. CWE-200 : Sensitiv informasjonseksponeringsfeil
  5. CWE-125 : Lesefeil utenfor grensene
  6. CWE-89 : SQL Injection
  7. CWE-416 : Gratis minnefeil
  8. CWE-190 : Feil ved overføring av heltall
  9. CWE-352 : Forfalskning på tvers av nettstedet
  10. CWE-22 : Directory Traversal
  11. CWE-78 : OS Command Injection
  12. CWE-787 : Skrivefeil utenfor grensene
  13. CWE-287 : Feil godkjenningsfeil
  14. CWE-476 : Dereferencing NULL Pointer
  15. CWE-732 : Feil tillatelsesoppgave
  16. CWE-434 : Ubegrenset filopplasting
  17. CWE-611 : Informasjonseksponering gjennom XML-enheter
  18. CWE-94 : Kodeinjeksjon
  19. CWE-798 : Hardkodet tilgangsnøkkel
  20. CWE-400 : Ukontrollert ressursforbruk

Hva betyr begrepet CWE?

De Vanlig svakhetsoppregning (CWE) er en fellesskaps akseptert liste over programvare- og maskinvaresårbarheter med identifikasjonskode tildelt for hver svakhet. Målet er å identifisere ulike feil i programvare og maskinvare for å kunne fikse og redusere alle disse feilene.

# 1) CWE-119: Memory Buffer Error

Denne feilen blir vanligvis introdusert under arkitektur og design, implementering, driftstrinn i SDLC.

Denne bufferoverløpet skjer når en søknadsprosess prøver å lagre mer data enn den kan holde i minnet. Siden bufferne bare kan lagre noe datanivå, og når dette nivået er nådd og overskredet, flyter dataene til et annet minneplass som kan ødelegge dataene som allerede er inneholdt i bufferen.

Denne hendelsen skjer noen ganger ved et uhell gjennom noen programmeringsfeil, men ettervirkningen kan være katastrofal, da dette kan slette data, stjele konfidensiell informasjon, og til og med hele applikasjonen kan krasje på grunn av dette bufferoverløpet.

Eksemplet nedenfor viser en buffer tildelt med 8 bytes lagring. Men den rant over av 2 byte på grunn av at flere data ble sendt for utføring.

Memory Buffer Error

(bilde kilde )

# 2) CWE-79: Skripting på tvers av nettsteder

Cross-site Scripting (XSS) er et injeksjonsangrep som vanligvis skjer når en ondsinnet skuespiller eller en angriper injiserer skadelig eller skadelig skript i et webapplikasjon som kan kjøres gjennom nettleserne. Når det ondsinnede skriptet finner veien inn i det kompromitterte systemet, kan det brukes til å utføre forskjellige ondsinnede aktiviteter.

Noen av de ondsinnede aktivitetene kan være i form av overføring av privat informasjon, som informasjonskapsler som har øktinformasjonen fra offerets datamaskin til angriperens datamaskin.

Forekomst av skript på tvers av nettsteder:

  • Når ikke-validerte og ikke-pålitelige data blir lagt inn i en webapplikasjon gjennom forespørsel om webskjema.
  • Når webapplikasjonen umiddelbart sender ut en webside som inneholder disse ondsinnede dataene.
  • Under prosessen med å generere en side, mislykkes programvaren å validere mot dataene, som inneholder innholdet som kan kjøres av en nettleser, som HTML og JavaScript.
  • Offeret besøker uvitende siden som ble generert gjennom en nettleser, som huser det ondsinnede skriptet som ble injisert ved bruk av upålitelige data.
  • Det ondsinnede skriptet kommer fra en side som ble sendt av angriperens webserver, og den kompromitterte systemnettleseren fortsetter med å behandle det ondsinnede skriptet.
  • Denne handlingen bryter med nettleserens policy om samme opprinnelse, som bestemmer at skript som kommer fra ett domene, ikke skal ha tilgang til ressurser eller utføre kode på et annet domene unntatt sitt eget domene.

Forekomst av skript på tvers av nettsteder

(bilde kilde )

# 3) CWE-20: Ugyldig inngangsfeil

Søknaden mottar innspill, men klarer ikke å validere inngangen, om den har alle nødvendige detaljer som er nødvendige for at den kan aksepteres i systemet for behandling.

Når det er inngangssanitering, kan dette brukes til å sjekke potensielt farlige innganger for å sikre at inngangene er trygge å bli behandlet med kildekoden, eller når det er en inngang som er nødvendig for å kommunisere med andre komponenter.

Når slike innganger ikke er sanitert eller validert på riktig måte, vil dette bane vei for en angriper å sende en ondsinnet inngang som hovedprogrammet vil behandle sjenerøst, og dette vil føre til endringer i kontrollflyten, vilkårlig kontroll av en ressurs eller vilkårlig kode henrettelse.

Bildene nedenfor viser at et godt program ikke skal godta skript eller kommando som input. Hvis slike innganger ikke blir renset ordentlig, vil applikasjonen behandle den og tro at det er en gyldig forespørsel.

inngang

Ugyldig inngangsfeil

(bilde kilde )

# 4) CWE-200: Feil på følsom informasjon

Dette skjer når applikasjonen bevisst og uvitende avslører informasjon som er konfidensiell og sensitiv for en angriper som ikke har autorisasjon til å få tilgang til denne informasjonen.

Ulike feil fører til at denne informasjonen blir utsatt for en angriper. Alvorlighetsgraden av denne feilen varierer avhengig av konteksten applikasjonen fungerer i, hvilken type sensitiv informasjon som blir avslørt, og hva aktøren kan få fra den eksponerte informasjonen.

Nedenfor er noen sensitive opplysninger som kan bli utsatt:

  • Personlig informasjon som personlige meldinger, økonomiske data, helsestatusposter, geografisk beliggenhet eller kontaktinformasjon
  • Systemkonfigurasjonsdetaljer og miljø, for eksempel, operativsystemet og installerte pakker
  • Business Record og immateriell eiendom
  • Nettverkskonfigurasjonsdetaljer
  • Intern applikasjonstilstand
  • Metadata som meldingsoverskriftene

Noen ganger kan det være tekniske kløe som databaseforbindelsesfeil, kjøretidsfeil og nettverksfeil på våre applikasjoner eller nettsteder.

Hvis slike feil ikke håndteres ordentlig under utviklingen, dvs. når applikasjonen viser feilmeldingen, kan den vise informasjon for publikum som en angriper kan bruke til ondsinnede formål, som bildet nedenfor.

serverfeil

# 5) CWE-125: Lesefeil utenfor grensene

Dette skjer vanligvis når applikasjonen leser data forbi det normale nivået, enten til slutten eller før begynnelsen av bufferen. Dette gir ubehagelig tilgang til en angriper for å lese sensitiv informasjon fra andre minneplasser, noe som også kan føre til et system- eller applikasjonskrasj.

Et krasj vil absolutt skje når koden leser data og tror det er en indikator på plass som stopper leseoperasjonen som en NULL som brukes på en streng

I den følgende koden henter funksjonen en verdi fra en matriseindeksplassering, som igjen er inngangsparameteren til funksjonen.

Lesefeil utenfor grensene

(bilde kilde )

Fra koden ovenfor kan vi se at funksjonen verifiserer at den gitte matriseindeksen er mindre enn den maksimale lengden på matrisen, men ikke klarer å validere for minimumsverdien.

Denne un-validering vil føre til aksept av en negativ verdi som en input array-indeks, forårsaker en utenfor-grensene lese, som igjen gir tilgang til sensitivt minne.

Det er et behov for å verifisere indeksen for inngangsmatrise hvis den er innenfor det maksimale og minste området som kreves for matrisen.

Hvis du nå sjekker eksemplet nedenfor, vil du se at IF-setningen må endres for å inkludere en minimumsvalidering.

minimumsvalidering

# 6) CWE-89: SQL Injection

SQL-injeksjon er en form for sikkerhetssårbarhet der angriperen injiserer en Structured Query Language (SQL) -kode i Webform-inndatafeltet for å få tilgang til ressurser eller endre data som ikke er autorisert for tilgang.

Denne sårbarheten kan introduseres i applikasjonen i løpet av design-, implementerings- og driftsfasen.

Hva denne SQL-spørringen gjør, er å komme med en uautorisert forespørsel til databasen om litt informasjon. I en normal inngangsoperasjon brukes et webskjema for brukerautentisering. Når en bruker skriver inn navnet og passordet i tekstboksene, settes disse verdiene inn i et SELECT-spørsmål.

Hvis inngangsverdiene er riktige, får brukeren tilgang til applikasjonen eller forespørselen, men hvis verdiene er feil, vil tilgang nektes.

Enkelte nettskjemaer i dag har ikke mekanismer på plass for å blokkere ondsinnet input. En angriper kan bruke inndataboksene til å sende ondsinnede forespørsler til databasen. Denne enkle forespørselen kan gi dem tilgang til hele databasen som kan inneholde sensitiv informasjon.

SQLinjeksjon

# 7) CWE-416: Tidligere frigjort minne

Dette problemet skyldes henvisning av minne etter at det er utgitt, noe som alvorlig kan føre til et programkrasj. Når du bruker et tidligere frigjort minne, kan dette få uheldige konsekvenser, som å ødelegge gyldige data, utføre vilkårlig kode som er avhengig av feiltimingen.

To vanlige årsaker er:

  • Feilforhold i programvaren og i noen andre unntakstilfeller.
  • Ingen forklaring på hvilken del av programmet som forårsaket ledig minne.

I dette tilfellet tildeles minnet til en annen peker umiddelbart etter at den er frigjort. Den forrige pekeren til det frigjorte minnet brukes igjen og peker nå på et sted rundt den nye tildelingen. Når dataene endres, kan dette ødelegge det brukte minnet og føre til at applikasjonen oppfører seg på en udefinert måte.

# 8) CWE-190: Feil på overløp av heltall

Når en beregning behandles av en applikasjon og det er en logisk antagelse om at den resulterende verdien vil være større enn den eksakte verdien, skjer heltalloverløp. Her øker et heltall til en verdi som ikke kan lagres på et sted.

Når dette skjer, vil verdien vanligvis vikle seg til å bli en veldig liten eller negativ verdi. Hvis innpakningen forventes, er det greit, men det kan få sikkerhetsmessige konsekvenser hvis innpakningen er uventet. Når dette scenariet oppstår, kan det betegnes som kritisk ettersom resultatet blir brukt til å administrere looping, sikkerhetsbeslutning, brukt til å tildele minne og mange flere.

Denne svakheten vil generelt føre til uberegnelig oppførsel og kan føre til krasj. Hvis verdien er viktig for data enn å flyte, kan det oppstå en enkel datakorrupsjon. Men hvis viklingen rundt fører til ytterligere forhold som bufferoverløp, kan minnekorrupsjon skje.

Dette problemet kan utløse bufferoverløp, som kan brukes til å utføre vilkårlig kode av en angriper. Denne heltalloverflytfeilen blir vanligvis introdusert i systemet i løpet av design- og implementeringsstadiene til SDLC.

IntegerOverflow

# 9) CWE-352: Forfalskning på tvers av nettsteder

Dette er når et webapplikasjon ikke tilstrekkelig verifiserer HTTP-forespørselen, enten forespørselen faktisk kom fra riktig bruker eller ikke. Webserverne er designet for å godta alle forespørsler og gi svar på dem.

La oss anta at en klient sender flere HTTP-forespørsler innen en eller flere økter. Det er veldig vanskelig for en webserver å vite om alle forespørslene var autentiske eller ikke, og de behandles vanligvis. En angriper kan ha sin måte å tvinge en klient til å besøke en spesiallaget webside og nå være i stand til å utføre noen forespørsler som pengeoverføring, endre e-postadressen og mange flere.

Umiddelbart har en angriper tilgang, og de vil kunne stjele data og kan til og med ødelegge data. De kan alltid opprettholde tilgangen, og når de er ferdige, kan de kompromittere revisjonsloggen for å forhindre fremtidig kriminalteknikk som kan avsløre utnyttelsen av dem.

Bildet nedenfor viser en angriper som får en bruker til å utføre handlinger de ikke har til hensikt å utføre.

CrossSite

# 10) CWE-22: Directory Traversal

Directory traversal eller file path traversal er et sikkerhetsproblem i websikkerheten som gjør det mulig for en angriper å lese vilkårlige filer på serveren som for øyeblikket kjører et program.

Disse filene kan være en applikasjonskode, legitimasjon for back-end-systemer og operativsystemfilene. I et annet scenario kan en angriper være i stand til å skrive til disse vilkårlige filene på serveren som kan tillate dem å endre applikasjonsdata eller oppførsel, og dette vil gi dem total kontroll over serveren.

Gjennomgang

(bilde kilde )

# 11) CWE-78: OS Command Injection

Det handler om feil sanering av spesielle elementer som kan føre til endring av den tiltenkte OS-kommandoen som sendes til en nedstrøms komponent. En angriper kan utføre disse ondsinnede kommandoene på et måloperativsystem og kan få tilgang til et miljø de ikke skulle lese eller endre.

Dette vil alltid tillate en angriper å utføre farlige kommandoer direkte i operativsystemet.

prøve spørsmål og svar om avslutningsintervju

Når dette sikkerhetsproblemet oppstår i et privilegert program, tillater det angriperen å bruke kommandoer som er tillatt i miljøet, eller ringe til andre kommandoer med privilegier som angriperen ikke har, noe som kan øke mengden skade som kan oppstå.

CommandInjection

# 12) CWE-787: Skrivfeil utenfor grensene

Dette skjer når applikasjonen skriver data etter slutten, eller før begynnelsen av den angitte bufferen.

Når dette skjer, er sluttresultatet vanligvis datakorrupsjon, system- eller applikasjonskrasj. Det applikasjonen gjør er en slags pekeraritmetikk som brukes til å referere til et minneplass utenfor buffergrensene.

# 13) CWE-287: Feil godkjenningsfeil

Dette er når en angriper hevder å ha en gyldig identitet, men programvaren klarte ikke å bekrefte eller bevise at kravet er riktig.

En programvare validerer brukerens påloggingsinformasjon feil, og som et resultat kan en angriper få visse rettigheter i applikasjonen eller avsløre sensitiv informasjon som gjør at de kan få tilgang til sensitive data og utføre vilkårlig kode.

# 14) CWE-476: Dereferencing En NULL-peker

Å referere en nullpeker er når applikasjonen henviser en peker som skulle returnere et gyldig resultat, i stedet returnerer NULL, og dette fører til et krasj. Å avvise en nullpeker kan skje gjennom mange feil som løpsforhold og noen programmeringsfeil.

Prosessene som utføres ved hjelp av NULL-pekeren fører vanligvis til feil, og muligheten for å utføre prosessen er veldig liten. Dette hjelper angripere med å utføre ondsinnet kode.

NullPointer

(bilde kilde )

# 15) CWE-732: Feil tildeling av tillatelse

Dette sikkerhetsproblemet skjer når et program tilordner tillatelser til en veldig viktig og kritisk ressurs på en slik måte at den utsettes for ressursen som en ondsinnet bruker har tilgang til.

Når du gir mange mennesker tillatelse til en ressurs, kan dette føre til at sensitiv informasjon blir eksponert eller endret av en angriper. Hvis det ikke er noen sjekk på plass mot denne typen tilnærming til tillatelsestildeling til ressurser, kan det føre til en veldig katastrofal slutt hvis et programkonfigurasjon eller noen sensitive data kommer i feil hånd.

# 16) CWE-434: Ubegrenset filopplasting

Dette sikkerhetsproblemet oppstår når applikasjonen ikke validerer filtypene før den lastes opp filer til applikasjonen. Dette sikkerhetsproblemet er språkuavhengig, men forekommer vanligvis i applikasjoner skrevet på ASP- og PHP-språk.

En farlig filtype er en fil som kan behandles automatisk i applikasjonsmiljøet.

Det følgende programmet viser en opplasting av en PHP-fil. Filtypen ble ikke bekreftet og validert før den ble lastet opp i webroot-katalogen. Som et resultat av denne svakheten, kan en angriper laste opp en vilkårlig PHP-fil og utføre den ved direkte tilgang til den opplastede filen.

opplasting av en PHP-fil

vilkårlig PHP-fil

# 17) CWE-611: Eksponering av informasjon gjennom XML-enheter

Når et XML-dokument lastes opp i en applikasjon for behandling, og dette dokumentet inneholder XML-enheter med ensartet ressursidentifikator som løser seg til et annet dokument på et annet sted enn den tiltenkte plasseringen. Denne avviket kan gjøre at søknaden om å legge ved feil dokumenter i utdataene.

XML-dokumentene inneholder noen ganger en Document Type Definition (DTD), som brukes til å definere XML-enheter og andre funksjoner. Gjennom DTD kan den ensartede ressursidentifikatoren tjene som en form for substitusjonsstreng. Det XML-parseren vil gjøre er å få tilgang til det som finnes i den ensartede ressursidentifikatoren og legge inn innholdet tilbake i XML-dokumentet for utføring.

Infoeksponering

(bilde kilde )

# 18) CWE-94: Kodeinjeksjon

Eksistensen av kodesyntaks i brukerens data øker angriperens mulighet til å endre den planlagte kontrollatferden og utføre vilkårlig kode. Denne sårbarheten blir referert til som 'svakheter i injeksjonen', og denne svakheten kan gjøre at datakontroll blir brukerstyrt.

Dette sikkerhetsproblemet viser et scenario der programvare tillater upålitelige data i koden og ikke utfører validering av spesialtegn som kan påvirke både oppførselen til kodesegmentet og syntaksen negativt.

Kort sagt, en angriper vil være i stand til å injisere en slags vilkårlig kode og utføre dem i applikasjonen. Følgende PHP-kode viser bruken av eval () -funksjonen i upålitelige data. I koden nedenfor er en angriper i stand til å gi 'param' -parameteren vilkårlig kode inn i koden som deretter vil bli utført i programvaren.

Kodeinjeksjon

Eksemplet nedenfor forklarer samtalen til phpinfo () funksjon. Dette sårbarheten kan videre utnyttes i andre for å utføre vilkårlige OS-kommandoer på målprogramvaren gjennom system () samtalen.

ring til phpinfo () -funksjonen

# 19) CWE-798: Hardkodet tilgangsnøkkel

Dette er når passordet og tilgangsnøkkelen er hardkodet i applikasjonen direkte for inngående autentiseringsformål og utgående kommunikasjon til noen eksterne komponenter og for kryptering av interne data. Hardkodede påloggingsdetaljer forårsaker vanligvis sårbarhet som legger til rette for at en angriper kan omgå autentiseringen som er konfigurert av programvareadministratoren.

Systemadministratoren vil alltid synes det er veldig vanskelig å oppdage dette sikkerhetsproblemet og fikse det.

Det er to hovedstrømmer til denne svakheten:

  • Inngående : Søknaden inneholder et autentiseringssystem som validerer inngangslegitimasjonen mot de hardkodede detaljene.
  • Utgående : Programmet kobles til et annet system, og detaljer for tilkobling til det andre systemet er hardkodet i systemet.

I den inngående strømmen er det alltid en standardadministratorkonto som opprettes, og legitimasjonen for å få tilgang til den blir hardkodet i applikasjonen og assosiert med den aktuelle administratorkontoen.

De hardkodede detaljene er vanligvis det samme på tvers av alle installasjoner av applikasjonen, og dette kan ikke endres eller deaktiveres av noen. Selv systemadministratorene har ikke rett, bortsett fra at de kan endre applikasjonen manuelt. Hvis passordet noen gang blir offentliggjort, kan en angriper ha tilgang til hele applikasjonen og kan manipulere det for egen gevinst.

Siden alle installasjoner av applikasjonen har det samme passordet, selv når det er installert i separate organisasjoner, kan dette forårsake svært massive angrep over alle grenser av organisasjonen, for eksempel, injisere en orm i applikasjonen som vil spre seg rundt.

Den utgående strømmen gjelder bare for front-end-systemer som autentiseres med en back-end-tjeneste. Back-end-tjenesten kan kreve en hard-kode eller et fast passord som lett kan oppdages. Hva programmereren gjør, er ganske enkelt å hardkode disse back-end-legitimasjonene til front-end-programvaren. Enhver bruker av dette programmet kan være i stand til å trekke ut passordet.

Enhver programvare på klientsiden der passordet og tilgangsnøkkelen er hardkodet inn i den, utgjør vanligvis mer trussel enn de som ikke er hardkodede, fordi utvinning av et passord fra en binær er vanligvis veldig enkelt å oppnå.

# 20) CWE-400: Ukontrollert ressursforbruk

Dette sårbarheten skjer når applikasjonen ikke kontrollerer tildelingen riktig og vedlikehold av en begrenset ressurs, dette gjør at en angriper kan påvirke mengden ressurser som forbrukes, noe som til slutt vil føre til utmattelse av tilgjengelige ressurser.

En del av de begrensede ressursene inkluderer minne, filsystemlagring, oppføring i databasetilkobling og CPU.

La oss anta at en angriper kan utløse tildelingen av disse begrensede ressursene og antallet eller størrelsen på ressursene ikke kontrolleres, da kan angriperen forårsake kaos gjennom tjenestenekt som bruker alle tilgjengelige ressurser.

Når dette skjer, vil det forhindre gyldige brukere å få tilgang til applikasjonen, noe som alltid vil ha en negativ innvirkning på miljøet. For eksempel, når applikasjonsminnet går gjennom et utmattelsesangrep, kan dette redusere hele applikasjonen så vel som vertsoperativsystemet.

De tre forskjellige tilfellene som kan føre til ressursutmattelse er:

  • Mangel på struping for antall tildelte ressurser
  • Å miste alle referanser til en ressurs før du når nedleggelsesfasen
  • Manglende lukking / retur av ressurs etter behandling

Spørsmålet om ressursutmattelse er vanligvis et resultat av feil implementering av følgende scenarier:

  • Feilforhold og andre eksepsjonelle omstendigheter.
  • Det er blandet reaksjon over hvilken del av programmet som frigjør ressursen.

Følgende eksempel hjelper til med å demonstrere arten av dette sikkerhetsproblemet og beskrive metoder som kan brukes til å redusere risikoen.

Følgende eksempel forklarer sårbarheten:

Ukontrollert ressursforbruk

informatica administrator intervju spørsmål og svar

(bilde kilde )

Dette programmet sporer ikke hvor mange tilkoblinger som er opprettet, og det begrenser ikke antall tilgjengelige tilkoblinger. Forking er bare en av måtene som en angriper bruker for å få systemet til å gå tom for CPU, prosesser eller minne ved å opprette et stort antall tilkoblinger.

Hva en angriper gjør, er å konsumere alle tilgjengelige tilkoblinger, og forhindre at andre får tilgang til systemet eksternt.

ofte stilte spørsmål

Q # 1) Hva står SANS for?

Svar: SANS står for SysAdmin, Audit, Network og Security.

Q # 2) Bruk noen eksempler på sårbarheter.

Svar: Eksemplene er som følger:

  • Sårbarheter i programvare
  • Brannmurssårbarheter
  • Sårbarheter i nettverket
  • Sikkerhetsproblemer i operativsystemet
  • Sårbarheter ved webserver
  • Sikkerhetsproblemer i databaser

Q # 3) Hva er forskjellen mellom trusler og sårbarheter?

Svar: Trussel er muligheten for å utføre en ondsinnet eller uønsket handling i et forsøk på å skade et datasystem eller applikasjon gjennom eksisterende sårbarheter i systemet. Eksempel: løsepenger.

Sårbarheter er svakheter som finnes i et system som kunne ha tillatt uønsket eller uautorisert tilgang fra en angriper å infiltrere skade på en organisasjon. Eksempel: Feilkonfigurasjon av brannmur.

Sp # 4) Hva er de vanligste sårbarhetene?

Svar: Dette er som følger:

  • SQL Injection
  • Tverrstedsskripting
  • Feilkonfigurasjon av sikkerhet
  • Sensitiv dataeksponering
  • Brutt autentisering
  • Øktledelse

Konklusjon

Denne SANS topp 20-sårbarhetslisten er ikke en regel eller policy, men en guide for å hjelpe oss med hvordan vi kan unngå programvaresårbarheter. Enten vi er utvikler eller sikkerhetsekspert, er det nå overlatt til oss å følge denne veiledningen om hva som kan gjøres for å unngå feil som kan føre til sårbarheter i applikasjonen vår som kan skape en bakdør for en skuespiller å utføre en ondsinnet handling.

Anbefalt lesing

^