Menu

SANS Top 20 sikkerhedssårbarheder i softwareapplikationer

  • Vigtigste
  • Andet
  • SANS Top 20 sikkerhedssårbarheder i softwareapplikationer

sans top 20 security vulnerabilities software applications

Prøv Vores Instrument Til At Fjerne Problemer

Lær og forstå SANS top 20 kritiske sikkerhedssårbarheder i softwareapplikationer med eksempler i denne vejledning:

Ordet UDEN er ikke bare et almindeligt ordbogord, men det står for SysAdmin , Revidere , Netværk og Sikkerhed .

I denne vejledning lærer vi om SANS top 20 sikkerhedssvagheder, vi kan finde i softwareprogrammer, og hvad vi kan gøre for at afbøde det.

SANS sikkerhedssårbarheder

Hvad du lærer:

SANs indvirkning på cybersikkerhedsfællesskabet

Ifølge UDEN , det UDEN Institut blev oprettet som en forsknings- og uddannelsesorganisation. Dens forskellige sikkerhedsprogrammer er meget omfattende og har en positiv effekt på over 165.000 sikkerhedsprofessionelle globalt.

Vi kan med rette sige, at med denne form for dækning, der kommer fra SANS og anden positiv gennemgang, får de dem til at være den mest betroede og langt den største organisation for InfoSec-træning og forskellige sikkerhedscertificeringer i verden.

Denne artikel vil fokusere på SANS top 20-fejl, der kan gøre din software sårbar over for angreb, og nogle af de sikkerhedskontroller, du kan implementere for at afbøde mod disse fejl. Selvom vi kan finde mere end 20, men vi vil diskutere de 20 største sårbarheder.

Liste over SANS Top 20 kritiske sårbarheder i software

  1. CWE-119 : Memory Buffer Error
  2. CWE-79 : Scripting på tværs af websteder
  3. CWE-20 : Ugyldig inputfejl
  4. CWE-200 : Eksponeringsfejl med følsom information
  5. CWE-125 : Læsefejl uden for grænserne
  6. CWE-89 : SQL-injektion
  7. CWE-416 : Fri hukommelsesfejl
  8. CWE-190 : Fejl ved overløb af heltal
  9. CWE-352 : Forfalskning på tværs af steder
  10. CWE-22 : Directory Traversal
  11. CWE-78 : OS-kommandoinjektion
  12. CWE-787 : Skrivefejl uden for grænserne
  13. CWE-287 : Forkert godkendelsesfejl
  14. CWE-476 : Dereferencing NULL Pointer
  15. CWE-732 : Forkert tilladelsestildeling
  16. CWE-434 : Ubegrænset filoverførsel
  17. CWE-611 : Eksponering af oplysninger gennem XML-enheder
  18. CWE-94 : Kodeinjektion
  19. CWE-798 : Hårdkodet adgangsnøgle
  20. CWE-400 : Ukontrolleret ressourceforbrug

Hvad betyder udtrykket CWE?

Det Almindelig svaghedstælling (CWE) er en community-accepteret liste over software- og hardwaresårbarheder med identifikationskode tildelt for hver svaghed. Målet er at identificere forskellige fejl i software og hardware for at kunne rette og afbøde alle disse fejl.

konvertere flere youtube-videoer til mp3

# 1) CWE-119: Fejl ved hukommelsesbuffer

Denne fejl introduceres normalt under SDLC's arkitektur og design, implementering, driftsfaser.

Dette bufferoverløb sker, når en ansøgningsproces forsøger at gemme flere data, end den kan gemme i hukommelsen. Da bufferne kun kan gemme et visst niveau af data, og når dette niveau nås og overskrides, flyder dataene til en anden hukommelsesplacering, som kan ødelægge de data, der allerede er indeholdt i denne buffer.

Denne hændelse sker undertiden ved et uheld gennem en eller anden programmeringsfejl, men eftervirkningen kan være katastrofal, da dette kan slette data, stjæle fortrolige oplysninger, og endda hele applikationen kan gå ned på grund af dette bufferoverløb.

Eksemplet nedenfor viser en buffer tildelt 8bytes lager. Men det overløb af 2 bytes på grund af flere data blev sendt til udførelse.

Fejl ved hukommelsesbuffer

(billede kilde )

# 2) CWE-79: Scripting på tværs af websteder

Cross-site Scripting (XSS) er et injektionsangreb, der normalt sker, når en ondsindet skuespiller eller en angriber injicerer ondsindet eller skadeligt script i en webapplikation, som kan udføres via webbrowserne. Når det ondsindede script finder vej ind i det kompromitterede system, kan det bruges til at udføre forskellige ondsindede aktiviteter.

Nogle af de ondsindede aktiviteter kan være i form af overførsel af private oplysninger som cookies, der har sessionsoplysningerne fra offerets computer til angriberens computer.

Forekomst på tværs af scripting:

  • Når ikke-validerede og ikke-tillid til data indsættes i en webapplikation via webformularanmodningen.
  • Når webapplikationen straks sender en webside, der indeholder disse ondsindede data.
  • Under processen med at generere en side kan softwaren ikke valideres i forhold til dataene, som indeholder det indhold, der kan udføres af en webbrowser, som HTML og JavaScript.
  • Offeret besøger ubevidst den side, der blev genereret gennem en webbrowser, der huser det ondsindede script, der blev injiceret ved brug af de ikke-tillid til data.
  • Det ondsindede script kommer fra en side, der blev sendt af angriberens webserver, og den kompromitterede systemwebbrowser fortsætter derefter med at behandle det ondsindede script.
  • Denne handling overtræder webbrowserens politik om samme oprindelse, som bestemmer, at scripts, der kommer fra et domæne, ikke skal have adgang til ressourcer eller udføre kode i et andet andet domæne undtagen sit eget domæne.

Forekomst af scripting på tværs af websteder

(billede kilde )

# 3) CWE-20: Ugyldig inputfejl

Applikationen modtager input, men validerer ikke input, uanset om det har alle nødvendige detaljer, der er nødvendige for at det kan accepteres i systemet til behandling.

Når der er indgangsrensning, kan dette bruges til at kontrollere potentielt farlige indgange for at sikre, at indgangene er sikre til at blive behandlet med kildekoden, eller når det er et input, der er nødvendigt for at kommunikere med andre komponenter.

Når sådanne input ikke er korrekt rensede eller validerede, vil dette bane vejen for en angriber til at sende et ondsindet input, som hovedapplikationen generøst vil behandle, og dette vil føre til ændringer i kontrolflowet, vilkårlig kontrol af en ressource eller vilkårlig kode udførelse.

Nedenstående billeder viser, at en god applikation ikke skal acceptere script eller kommando som input. Hvis sådanne input ikke renses ordentligt, behandler applikationen det, idet de mener, at det er en gyldig anmodning.

input

Ugyldig inputfejl

(billede kilde )

# 4) CWE-200: Fejl ved følsom informationseksponering

Dette sker, når applikationen bevidst og ubevidst afslører oplysninger, der er fortrolige og følsomme over for en hacker, der ikke har tilladelse til at få adgang til disse oplysninger.

Forskellige fejl fører til, at disse oplysninger udsættes for en angriber. Alvoren af ​​denne fejl varierer alt efter den sammenhæng, som applikationen fungerer i, typen af ​​følsomme oplysninger, der afsløres, og hvad skuespilleren kan få fra den udsatte information.

Nedenfor er nogle følsomme oplysninger, der kan blive eksponeret:

  • Personlige oplysninger som personlige beskeder, økonomiske data, sundhedsstatusregistreringer, geografisk placering eller kontaktoplysninger
  • Systemkonfigurationsdetaljer og miljø, for eksempel, operativsystemet og installerede pakker
  • Business Record og intellektuel ejendomsret
  • Netværkskonfigurationsoplysninger
  • Intern applikationstilstand
  • Metadata ligesom meddelelsesoverskrifterne

Nogle gange kan der være tekniske kløe som databaseforbindelsesfejl, kørselstidsfejl og netværksfejl på vores applikationer eller websteder.

Hvis sådanne fejl ikke håndteres korrekt under udviklingen, dvs. når applikationen viser fejlmeddelelsen, kan den vise information til offentligheden, som en angriber muligvis kan bruge til ondsindede formål som billedet nedenfor.

serverError

# 5) CWE-125: Læsefejl uden for grænserne

Dette sker normalt, når applikationen læser data forbi det normale niveau, enten til slutningen eller før starten af ​​bufferen. Dette giver uhindret adgang til en hacker til at læse følsomme oplysninger fra andre hukommelsesplaceringer, hvilket lige så godt kan føre til et system- eller applikationsnedbrud.

Et nedbrud vil helt sikkert ske, når koden læser data og mener, at der er en indikator på plads, der stopper læseoperationen som en NULL, der anvendes på en streng

I den følgende kode henter funktionen en værdi fra en matrixindeksplacering, som igen er inputparameteren til funktionen.

Læsefejl uden for grænserne

(billede kilde )

Fra koden ovenfor kan vi se, at funktionen verificerer, at det givne matrixindeks er mindre end matrixens maksimale længde, men ikke validerer til minimumsværdien.

Denne un-validering vil føre til accept af en negativ værdi som et input-array-indeks, der forårsager en læsning uden for grænserne, hvilket igen giver adgang til følsom hukommelse.

Der er behov for at kontrollere input-array-indekset, hvis det er inden for det maksimale og minimumsinterval, der kræves for arrayet.

Hvis du nu tjekker nedenstående eksempel, vil du se, at IF-sætningen skal ændres for at omfatte en minimumsvalideringsvalidering.

minimum validering af rækkevidde

# 6) CWE-89: SQL-injektion

SQL-injektion er en form for sikkerhedssårbarhed, hvor angriberen injicerer en Structured Query Language (SQL) -kode i Webform-inputfeltet for at få adgang til ressourcer eller ændre data, der ikke er autoriseret til at få adgang til.

Denne sårbarhed kan introduceres til applikationen i design-, implementerings- og driftsfasen.

Hvad denne SQL-forespørgsel gør, er at fremsætte en uautoriseret anmodning til databasen om nogle oplysninger. I en normal inputhandling bruges en webformular til brugergodkendelse. Når en bruger indtaster deres navn og adgangskode i tekstfelterne, indsættes disse værdier i en SELECT-forespørgsel.

Hvis inputværdierne er korrekte, får brugeren adgang til applikationen eller anmodningen, men hvis værdierne er forkerte, nægtes adgang.

Nogle webformularer i dag har ikke mekanismer til at blokere ondsindet input, en angriber kan bruge inputfelterne til at sende ondsindede anmodninger til databasen. Denne enkelt anmodning kan give dem adgang til hele databasen, der kan indeholde følsomme oplysninger.

SQLinjektion

# 7) CWE-416: Tidligere frigivet hukommelse

Dette problem skyldes henvisning af hukommelse, efter at det er frigivet, hvilket alvorligt kan føre til et programnedbrud. Når du bruger en tidligere frigivet hukommelse, kan dette have ugunstige konsekvenser, såsom korruption af gyldige data, vilkårlig kodeudførelse, der er afhængig af fejltimingen.

To almindelige årsager er:

  • Fejlforhold i softwaren og i nogle andre undtagelsestilfælde.
  • Ingen forklaring på, hvilken del af programmet der forårsagede ledig hukommelse.

I dette tilfælde tildeles hukommelsen til en anden markør umiddelbart efter at den er blevet frigivet. Den forrige markør til den frigjorte hukommelse bruges igen og peger nu på et eller andet sted omkring den nye allokering. Når data ændres, kan dette ødelægge den anvendte hukommelse og kunne få applikationen til at opføre sig på en udefineret måde.

# 8) CWE-190: Fejl ved overløb af heltal

Når en beregning behandles af en applikation, og der er en logisk antagelse om, at den resulterende værdi vil være større end den nøjagtige værdi, sker heltalsoverløb. Her stiger et heltal til en værdi, der ikke kan lagres et sted.

Når dette sker, vil værdien normalt ombrydes til at blive en meget lille eller negativ værdi. Hvis indpakningen forventes, er det fint, men der kan være sikkerhedskonsekvenser, hvis indpakningen er uventet. Når dette scenarie opstår, kan det betegnes som kritisk, da resultatet bruges til at styre looping, sikkerhedsbeslutning, bruges til at allokere hukommelse og mange flere.

Denne svaghed vil generelt føre til uregelmæssig adfærd og kan føre til nedbrud. Hvis værdien er vigtig for data end at flyde, kan der opstå en simpel datakorruption. Men hvis wrap-around fører til yderligere forhold som bufferoverløb, kan hukommelseskorruption forekomme.

Dette problem kan udløse bufferoverløb, som kan bruges til at udføre vilkårlig kode af en angriber. Denne heltalsoverløbsfejl introduceres normalt i systemet under Design og Implementation-stadierne i SDLC.

IntegerOverflow

# 9) CWE-352: Forfalskning på tværs af websteder

Dette er når en webapplikation ikke tilstrækkeligt verificerer HTTP-anmodningen, uanset om anmodningen faktisk kom fra den rigtige bruger eller ej. Webserverne er designet til at acceptere alle anmodninger og give et svar på dem.

Lad os antage, at en klient sender flere HTTP-anmodninger inden for en eller flere sessioner. Det er meget vanskeligt for en webserver at vide, om alle anmodningerne var autentiske eller ej, og det behandles normalt. En hacker kan have sin måde at tvinge en klient til at besøge en specielt udformet webside og nu være i stand til at udføre nogle anmodninger som pengeoverførsel, ændre deres e-mail-adresse og mange flere.

Umiddelbart har en hacker adgang, og de kan stjæle data og kan endda ødelægge data. De kan altid bevare deres adgang, og når de er færdige, kan de kompromittere revisionsloggen for at forhindre fremtidig retsmedicin, der kan udsætte deres udnyttelse.

Nedenstående billede viser en angriber, der tilskynder en bruger til at udføre handlinger, som de ikke har til hensigt at udføre.

CrossSite

# 10) CWE-22: Directory Traversal

Directory traversal eller file path traversal er en websikkerheds sårbarhed, der giver en hacker mulighed for at læse vilkårlige filer på den server, der i øjeblikket kører en applikation.

Disse filer kan være en applikationskode, legitimationsoplysninger til back-end-systemer og operativsystemfilerne. I et andet scenarie kan en angriber muligvis skrive til disse vilkårlige filer på serveren, hvilket kan give dem mulighed for at ændre applikationsdata eller adfærd, og dette vil give dem total kontrol over serveren.

Traversal

(billede kilde )

# 11) CWE-78: OS Command Injection

Det handler om ukorrekt sanering af specielle elementer, der kan føre til ændring af den tilsigtede OS-kommando, der sendes til en downstream-komponent. En angriber kan udføre disse ondsindede kommandoer på et måloperativsystem og kan få adgang til et miljø, som de ikke skulle læse eller ændre til.

Dette vil altid give en hacker mulighed for at udføre farlige kommandoer direkte i operativsystemet.

Når denne sårbarhed forekommer i et privilegeret program, giver det angriberen mulighed for at bruge kommandoer, der er tilladt i miljøet, eller at kalde andre kommandoer med privilegier, som angriberen ikke har, hvilket kan øge den skade, der kan opstå.

CommandInjection

# 12) CWE-787: Skrivfejl uden for grænserne

Dette sker, når applikationen skriver data efter slutningen eller inden starten af ​​den udpegede buffer.

Når dette sker, er slutresultatet normalt datakorruption, system- eller applikationsnedbrud. Hvad applikationen gør, er en slags pegearitmetik, der bruges til at henvise til en hukommelsesplacering uden for buffergrænserne.

# 13) CWE-287: Forkert godkendelsesfejl

Dette er, når en angriber hævder at have en gyldig identitet, men softwaren ikke bekræftede eller beviser, at kravet er korrekt.

En software validerer en brugers loginoplysninger forkert, og som et resultat kan en angriber få visse privilegier inden for applikationen eller afsløre følsomme oplysninger, der giver dem adgang til følsomme data og udfører vilkårlig kode.

programmer, der kan redigere pdf-filer

# 14) CWE-476: Dereferference En NULL-markør

Det at henvise til en nul pointer er, når applikationen henviser en markør, der skulle returnere et gyldigt resultat, i stedet returnerer NULL, og dette fører til et nedbrud. Dereferencing en nul pointer kan ske gennem mange fejl som race betingelser og nogle programmeringsfejl.

Processerne, der udføres ved hjælp af NULL-markøren, fører normalt til fiasko, og muligheden for at udføre processen er meget slank. Dette hjælper angribere med at udføre ondsindet kode.

NullPointer

(billede kilde )

# 15) CWE-732: Forkert tilladelsestildeling

Denne sårbarhed opstår, når et program tildeler tilladelser til en meget vigtig og kritisk ressource på en sådan måde, at en ressource, som en ondsindet bruger har adgang til, udsættes for.

Når du giver mange mennesker tilladelse til en ressource, kan dette føre til, at følsomme oplysninger eksponeres eller ændres af en angriber. Hvis der ikke er nogen kontrol på plads mod denne form for tilgang til tildeling af ressourcer, kan det føre til en meget katastrofal afslutning, hvis et programkonfiguration eller nogle følsomme data kommer i den forkerte hånd.

# 16) CWE-434: Ubegrænset filupload

Denne sårbarhed opstår, når applikationen ikke validerer filtyperne, før den uploader filer til applikationen. Denne sårbarhed er sproguafhængig, men forekommer normalt i applikationer skrevet på ASP- og PHP-sprog.

En farlig type fil er en fil, der automatisk kan behandles i applikationsmiljøet.

Det følgende program viser en upload af en PHP-fil. Filtypen blev ikke verificeret og valideret, før den blev uploadet i webroot-biblioteket. Som et resultat af denne svaghed kan en hacker uploade en vilkårlig PHP-fil og udføre den ved direkte adgang til den uploadede fil.

upload af en PHP-fil

vilkårlig PHP-fil

# 17) CWE-611: Eksponering af information gennem XML-enheder

Når et XML-dokument uploades til en applikation til behandling, og dette dokument indeholder XML-enheder med ensartet ressourceidentifikator, der løses til et andet dokument på en anden placering, der er forskellig fra den tilsigtede placering. Denne uregelmæssighed kan gøre ansøgningen om at vedhæfte forkerte dokumenter i dens output.

XML-dokumenterne indeholder undertiden en dokumenttypedefinition (DTD), som bruges til at definere XML-enheder og andre funktioner. Gennem DTD kan den ensartede ressourceidentifikator tjene som en form for substitutionsstreng. Hvad XML-parseren vil gøre er at få adgang til det, der er indeholdt i den ensartede ressourceidentifikator og indsætte dette indhold tilbage i XML-dokumentet til udførelse.

Infoeksponering

(billede kilde )

# 18) CWE-94: Kodeinjektion

Eksistensen af ​​kodesyntaks i brugerens data øger angriberens mulighed for at ændre den planlagte kontroladfærd og udføre vilkårlig kode. Denne sårbarhed kaldes “svagheder i injektionen”, og denne svaghed kan få en datakontrol til at blive brugerstyret.

Denne sårbarhed skildrer et scenario, hvor software tillader utroede data i koden og ikke udfører validering af specialtegn, som kan have negativ indflydelse på både kodesegmentets opførsel og syntaksen.

Kort sagt ville en angriber være i stand til at indsprøjte en slags vilkårlig kode og udføre dem i applikationen. Den følgende PHP-kode viser brugen af ​​eval () -funktionen i ikke-tillid til data. I koden nedenfor er en angriber i stand til at videregive parameteren 'param' vilkårlig kode til koden, som derefter udføres i softwaren.

Kodeindsprøjtning

Nedenstående eksempel forklarer opkaldet til phpinfo () fungere. Denne sårbarhed kan yderligere udnyttes i andre til at udføre vilkårlige OS-kommandoer på målsoftwaren gennem systemopkaldet ().

kald til phpinfo () -funktionen

# 19) CWE-798: Hårdkodet adgangsnøgle

Dette er, når adgangskoden og adgangsnøglen er hårdt kodet i applikationen direkte til indgående godkendelsesformål og udgående kommunikation til nogle eksterne komponenter og til kryptering af interne data. Hårdkodede loginoplysninger forårsager normalt sårbarhed, der baner vejen for, at en hacker kan omgå den godkendelse, der er konfigureret af softwareadministratoren.

Systemadministratoren vil altid have svært ved at opdage denne sårbarhed og rette den.

Der er to hovedstrømme til denne svaghed:

  • Indgående : Applikationen indeholder et godkendelsessystem, der validerer inputlegitimationsoplysningerne mod de hårdkodede detaljer.
  • Udgående : Applikationen opretter forbindelse til et andet system, og detaljer til forbindelse til det andet system er hårdkodet i systemet.

I den indgående strøm er der altid en standardadministratorkonto, der oprettes, og legitimationsoplysningerne for at få adgang til den bliver hårdkodet i applikationen og tilknyttet den standardadministratorkonto.

De hårdkodede detaljer er normalt den samme ting på tværs af enhver installation af applikationen, og dette kan ikke ændres eller deaktiveres af nogen. Selv systemadministratorer har ikke ret, bortset fra at de manuelt kan ændre applikationen. Hvis adgangskoden nogensinde afsløres for offentligheden, kan en angriber have adgang til hele applikationen og kan manipulere den til egen gevinst.

Da alle installationer af applikationen har den samme adgangskode, selv når de er installeret i separate organisationer, kan dette forårsage meget massive angreb på tværs af alle organisationens grænser, for eksempel, injicere en orm i applikationen, som spredes rundt.

Den udgående strøm gælder kun for front-end-systemer, der godkendes med en back-end-tjeneste. Back-end-tjenesten kan kræve en hard-code eller en fast adgangskode, som let kan findes. Hvad programmereren gør, er simpelthen at hårdkode disse back-end-legitimationsoplysninger i front-end-softwaren. Enhver bruger af denne applikation kan muligvis trække adgangskoden ud.

Enhver software på klientsiden, hvor adgangskoden og adgangsnøglen er hårdkodet ind i den, udgør normalt mere trussel end dem, der ikke er hårdkodede, fordi ekstraktion af en adgangskode fra en binær er normalt meget let at udføre.

# 20) CWE-400: Ukontrolleret ressourceforbrug

Denne sårbarhed sker, når applikationen ikke kontrollerer tildelingen korrekt og vedligeholdelse af en begrænset ressource, dette gør det muligt for en hacker at være i stand til at påvirke mængden af ​​forbrugte ressourcer, hvilket i sidste ende vil føre til udtømning af tilgængelige ressourcer.

En del af de begrænsede ressourcer inkluderer hukommelse, lagring af filsystem, databaseforbindelsespuljeposter og CPU.

Lad os antage, at en angriber kan udløse tildelingen af ​​disse begrænsede ressourcer, og antallet eller størrelsen af ​​ressourcerne ikke kontrolleres, så angriberen kan forårsage kaos gennem denial of service, der bruger alle tilgængelige ressourcer.

Når dette sker, ville det forhindre gyldige brugere i at få adgang til applikationen, hvilket altid vil have en negativ indvirkning på miljøet. For eksempel, når applikationshukommelsen gennemgår et udmattelsesangreb, kan dette sænke hele applikationen såvel som værtsoperativsystemet.

De tre forskellige tilfælde, der kan føre til ressourceudmattelse, er:

  • Mangel på gasregulering for antallet af tildelte ressourcer
  • At miste alle referencer til en ressource, før du når nedlukningsfasen
  • Manglende lukning / returnering af en ressource efter behandling

Spørgsmålet om ressourceudtømmelse skyldes normalt forkert implementering af følgende scenarier:

  • Fejlforhold og andre ekstraordinære omstændigheder.
  • Der er blandet reaktion over, hvilken del af programmet frigiver ressourcen.

Følgende eksempel hjælper med at demonstrere arten af ​​denne sårbarhed og beskrive metoder, der kan bruges til at mindske risikoen.

Følgende eksempel forklarer sårbarheden:

Ukontrolleret ressourceforbrug

hvordan man bruger sortering i java

(billede kilde )

Dette program sporer ikke, hvor mange forbindelser der er oprettet, og det begrænser ikke antallet af tilgængelige forbindelser. Forking er kun en af ​​de måder, som en angriber bruger for at få systemet til at løbe tør for CPU, processer eller hukommelse ved at oprette et stort antal forbindelser.

Hvad en hacker gør, er at forbruge alle tilgængelige forbindelser og forhindre andre i at få adgang til systemet eksternt.

Ofte stillede spørgsmål

Q # 1) Hvad står SANS for?

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

Q # 2) Anfør nogle eksempler på sårbarheder.

Svar: Eksemplerne er som følger:

  • Sårbarheder i software
  • Sårbarheder i firewall
  • Netværkssårbarheder
  • Sårbarheder i operativsystemet
  • Webserversårbarheder
  • Databasesårbarheder

Spørgsmål nr. 3) Hvad er forskellen mellem trusler og sårbarheder?

Svar: Trussel er muligheden for at udføre en ondsindet eller uønsket handling i et forsøg på at beskadige et computersystem eller en applikation gennem eksisterende sårbarheder i systemet. Eksempel: ransomware.

Sårbarheder er svagheder, der findes i et system, der kunne have tilladt uønsket eller uautoriseret adgang fra en angriber til at infiltrere skade på en organisation. Eksempel: Fejlkonfiguration af firewall.

Spørgsmål nr. 4) Hvad er de mest almindelige sårbarheder?

Svar: Disse er som følger:

  • SQL-injektion
  • Cross-site scripting
  • Fejlkonfiguration af sikkerhed
  • Følsom dataeksponering
  • Brudt godkendelse
  • Sessionsstyring

Konklusion

Denne SANS top 20-sårbarhedsliste er ikke en regel eller politik, men en guide til at hjælpe os med, hvordan vi undgår softwaresårbarheder. Uanset om vi er udvikler eller sikkerhedsekspert, overlades det nu til os at følge denne vejledning om, hvad der kan gøres for at undgå enhver fejl, der kan føre til sårbarheder i vores applikation, som kan skabe en bagdør for en skuespiller til at udføre en ondsindet handling.

Anbefalet læsning

^