10 mest almindelige websikkerhedssårbarheder

OWASP eller Open Web Security Project er en non-profit velgørende organisation, der fokuserer på at forbedre sikkerheden af ​​software og webapplikationer.

Organisationen udgiver en liste over de største sårbarheder i websikkerhed baseret på data fra forskellige sikkerhedsorganisationer.

Websikkerhedssårbarhederne prioriteres afhængigt af udnyttelse, sporbarhed og indvirkning på software.

• Udnyttelighed –Hvad skal der til for at udnytte sikkerhedssårbarheden? Højeste udnyttelsesevne, når angrebet kun kræver en webbrowser, og det laveste er avanceret programmering og værktøjer.
• Detekterbarhed – Hvor let er det at opdage truslen? Højest er den information, der vises på URL, formular eller fejlmeddelelse, og lavest er kildekoden.
• Påvirkning eller skade –Hvor stor skade vil der ske, hvis sikkerhedssårbarheden afsløres eller angribes? Det højeste er fuldstændigt systemnedbrud og det laveste er slet ingenting.

Hovedformålet med OWASP Top 10 er at uddanne udviklerne, designere, ledere, arkitekter og organisationer om de vigtigste sikkerhedssårbarheder.

Top 10 sikkerhedssårbarheder ifølge OWASP Top 10 er:

SQL Injection

Description

Injection er en sikkerhedssårbarhed, der gør det muligt for en hacker at ændre backend SQL udsagn ved at manipulere de brugerleverede data.

Injektion opstår, når brugerinput sendes til en tolk som en del af kommando eller forespørgsel og narre tolken til at udføre utilsigtede kommandoer og giver adgang til uautoriserede data.

SQL-kommandoen, som, når den udføres af webapplikation, også kan afsløre back-end-databasen.

Implikation

• En angriber kan injicere ondsindet indhold i de sårbare felter.
• Følsomme data som brugernavne, adgangskoder osv. kan læses fra databasen.
• Databasedata kan ændres (Indsæt/Opdater/Slet).
• Administration Operationer kan udføres på databasen

Sårbare genstande

• Indtastningsfelter
• URL'er, der interagerer med databasen.

eksempler:

• SQL-indsprøjtning på login-siden

Log ind på en applikation uden at have gyldige legitimationsoplysninger.

Gyldigt brugernavn er tilgængeligt, og adgangskoden er ikke tilgængelig.

Test URL: http://demo.testfire.net/default.aspx

Brugernavn: sjones

Adgangskode: 1=1′ eller pass123

SQL-forespørgsel oprettet og sendt til tolk som nedenfor

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ eller pass123;

Anbefalinger

1. Hvid liste over inputfelterne
2. Undgå at vise detaljerede fejlmeddelelser, der er nyttige for en hacker.

Crossing-scripting

Description

Cross Site Scripting er også kort kendt som XSS.

XSS-sårbarheder retter sig mod scripts, der er indlejret i en side, som udføres på klientsiden, dvs. brugerbrowseren i stedet for på serversiden. Disse fejl kan opstå, når applikationen tager upålidelige data og sender dem til webbrowseren uden korrekt validering.

Angribere kan bruge XSS til at udføre ondsindede scripts på brugerne i dette tilfælde offerbrowsere. Da browseren ikke kan vide, om scriptet er troværdigt eller ej, vil scriptet blive eksekveret, og angriberen kan kapre sessionscookies, ødelægge websteder eller omdirigere brugeren til et uønsket og ondsindet websted.

XSS er et angreb, som gør det muligt for angriberen at udføre scripts på offerets browser.

Implikation:

• Ved at gøre brug af denne sikkerhedssårbarhed kan en angriber injicere scripts i applikationen, stjæle sessionscookies, ødelægge websteder og køre malware på ofrets maskiner.

Sårbare genstande

• Indtastningsfelter
• URL'er

Eksempler

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

Ovenstående script, når det køres i en browser, vil der blive vist en beskedboks, hvis webstedet er sårbart over for XSS.

Det mere alvorlige angreb kan udføres, hvis angriberen ønsker at vise eller gemme sessionscookie.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com bredde = 500 højde 500>

Ovenstående script, når det køres, vil browseren indlæse en usynlig ramme, der peger på http://google.com.

Angrebet kan gøres alvorligt ved at køre et ondsindet script på browseren.

Anbefalinger

1. Indtastningsfelter for hvidliste
2. Input Output-kodning

Broken Authentication og Session Management

Description

Hjemmesiderne opretter normalt en sessionscookie og sessions-id for hver gyldig session, og disse cookies indeholder følsomme data som brugernavn, adgangskode osv. Når sessionen afsluttes enten ved at logge ud eller lukke browseren brat, bør disse cookies være ugyldige, dvs. for hver session. der skulle være en ny cookie.

Hvis cookies ikke er ugyldige, vil de følsomme data eksistere i systemet. For eksempel sidder en bruger, der bruger en offentlig computer (Cyber ​​Cafe), cookies fra det sårbare websted på systemet og udsættes for en angriber. En angriber bruger den samme offentlige computer efter nogen tid, de følsomme data kompromitteres.

På samme måde lukker en bruger, der bruger en offentlig computer, i stedet for at logge af, browseren brat. En angriber bruger det samme system, når han gennemser det samme sårbare websted, åbnes den tidligere session for offeret. Angriberen kan gøre, hvad han vil, ved at stjæle profiloplysninger, kreditkortoplysninger osv.

Der bør foretages en kontrol for at finde styrken af ​​godkendelsen og sessionsstyringen. Nøgler, sessionstokens, cookies bør implementeres korrekt uden at kompromittere adgangskoder.

Sårbare genstande

• Sessions-id'er afsløret på URL kan føre til sessionsfikseringsangreb.
• Sessions-id'er er de samme før og efter log ud og login.
• Sessionstimeout er ikke implementeret korrekt.
• Applikationen tildeler samme sessions-id for hver ny session.
• Godkendte dele af applikationen er beskyttet ved hjælp af SSL, og adgangskoder gemmes i hashed eller krypteret format.
• Sessionen kan genbruges af en lavprivilegeret bruger.

Implikation

• Ved at gøre brug af denne sårbarhed kan en hacker kapre en session, få uautoriseret adgang til systemet, hvilket tillader offentliggørelse og ændring af uautoriseret information.
• Sessionerne kan være high jacked ved hjælp af stjålne cookies eller sessioner ved hjælp af XSS.

Eksempler

1. Flyselskabsreservationsapplikation understøtter URL-omskrivning, indsættelse af sessions-id'er i URL'en:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Salg af billetter til Maldiverne)En godkendt bruger af siden ønsker at fortælle sine venner om salget og sender en e-mail på tværs. Vennerne modtager sessions-id'et og kan bruges til at foretage uautoriserede ændringer eller misbruge de gemte kreditkortoplysninger.
2. Et program er sårbart over for XSS, hvorved en angriber kan få adgang til sessions-id'et og kan bruges til at kapre sessionen.
3. Timeout for applikationer er ikke indstillet korrekt. Brugeren bruger en offentlig computer og lukker browseren i stedet for at logge af og går væk. Angriberen bruger den samme browser nogen tid senere, og sessionen bliver godkendt.

Anbefalinger

1. Alle krav til godkendelse og sessionsstyring skal defineres i henhold til OWASP Application Security Verification Standard.
2. Udsæt aldrig legitimationsoplysninger i URL'er eller logfiler.
3. Der bør også gøres en stor indsats for at undgå XSS-fejl, som kan bruges til at stjæle sessions-id'er.

Usikre direkte objektreferencer

Description

Det opstår, når en udvikler afslører en reference til et internt implementeringsobjekt, såsom en fil, mappe eller databasenøgle som i URL eller som en FORM-parameter. Angriberen kan bruge disse oplysninger til at få adgang til andre objekter og kan oprette et fremtidigt angreb for at få adgang til de uautoriserede data.

Implikation

• Ved at bruge denne sårbarhed kan en angriber få adgang til uautoriserede interne objekter, kan ændre data eller kompromittere applikationen.

Sårbare genstande

• I URL'en.

eksempler:

Ændring af "bruger-id" i følgende URL kan få en angriber til at se andre brugers oplysninger.

http://www.vulnerablesite.com/userid=123 Ændret til http://www.vulnerablesite.com/userid=124

En angriber kan se andres oplysninger ved at ændre bruger-id-værdien.

Anbefalinger:

1. Implementere adgangskontrol.
2. Undgå at udsætte objektreferencer i URL'er.
3. Bekræft autorisation til alle referenceobjekter.

Forfalskning på tværs af anmodninger om websted

Description

Cross Site Request Forgery er en forfalsket anmodning, der kom fra cross site.

CSRF-angreb er et angreb, der opstår, når et ondsindet websted, e-mail eller program får en brugers browser til at udføre en uønsket handling på et betroet websted, som brugeren i øjeblikket er godkendt til.

Et CSRF-angreb tvinger et logget offers browser til at sende en forfalsket HTTP-anmodning, inklusive offerets sessionscookie og enhver anden automatisk inkluderet godkendelsesinformation, til en sårbar webapplikation.

Et link vil blive sendt af angriberen til offeret, når brugeren klikker på URL'en, når han er logget ind på det originale websted, vil dataene blive stjålet fra webstedet.

Implikation

• Brug af denne sårbarhed som angriber kan ændre brugerprofiloplysninger, ændre status, oprette en ny bruger på admins vegne osv.

Sårbare genstande

• Brugerprofilside
• Brugerkontoformularer
• Forretningstransaktionsside

Eksempler

Offeret er logget ind på et bankwebsted ved hjælp af gyldige legitimationsoplysninger. Han modtager mail fra en angriber, der siger "Klik venligst her for at donere $1 til at forårsage."

Når offeret klikker på det, vil der blive oprettet en gyldig anmodning om at donere $1 til en bestemt konto.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

Angriberen fanger denne anmodning og opretter nedenstående anmodning og indlejrer en knap, der siger "I Support Cause."

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Da sessionen er autentificeret, og anmodningen kommer via bankens hjemmeside, vil serveren overføre $1000 dollars til angriberen.

Anbefaling

1. Give brugerens tilstedeværelse, mens de udfører følsomme handlinger.
2. Implementer mekanismer som CAPTCHA, gengodkendelse og unikke anmodningstokens.

Fejlkonfiguration af sikkerhed

Description

Sikkerhedskonfiguration skal defineres og implementeres for applikationen, rammerne, applikationsserveren, webserveren, databaseserveren og platformen. Hvis disse er korrekt konfigureret, kan en hacker have uautoriseret adgang til følsomme data eller funktionalitet.

Nogle gange resulterer sådanne fejl i fuldstændig systemkompromis. At holde softwaren opdateret er også god sikkerhed.

Implikation

• Ved at gøre brug af denne sårbarhed kan angriberen opregne den underliggende teknologi og applikationsserverversionsoplysninger, databaseoplysninger og få information om applikationen for at udføre få flere angreb.

Sårbare genstande

• URL
• Form Fields
• Indtastningsfelter

Eksempler

1. Applikationsserverens administrationskonsol installeres automatisk og fjernes ikke. Standardkonti ændres ikke. Angriberen kan logge ind med standardadgangskoder og kan få uautoriseret adgang.
2. Directory Listing er ikke deaktiveret på din server. Angriberen opdager og kan simpelthen liste mapper for at finde enhver fil.

Anbefalinger

1. En stærk applikationsarkitektur, der giver god adskillelse og sikkerhed mellem komponenterne.
2. Skift standard brugernavne og adgangskoder.
3. Deaktiver katalogfortegnelser og implementer adgangskontrol.

Usikker kryptografisk opbevaring

Description

Usikker kryptografisk lagring er en almindelig sårbarhed, som eksisterer, når de følsomme data ikke opbevares sikkert.

Brugerens legitimationsoplysninger, profiloplysninger, helbredsoplysninger, kreditkortoplysninger osv. falder ind under følsomme dataoplysninger på et websted.

Disse data vil blive gemt i applikationsdatabasen. Når disse data gemmes forkert ved ikke at bruge kryptering eller hashing*, vil de være sårbare over for angriberne.

(*Hashing er transformation af strengtegnene til kortere strenge med fast længde eller en nøgle. For at dekryptere strengen skal den algoritme, der bruges til at danne nøglen, være tilgængelig)

Implikation

• Ved at bruge denne sårbarhed kan en angriber stjæle, ændre sådanne svagt beskyttede data for at udføre identitetstyveri, kreditkortsvindel eller andre forbrydelser.

Sårbare genstande

• Ansøgningsdatabase.

Eksempler

I en af ​​bankapplikationerne bruger adgangskodedatabasen usaltede hash* til at gemme alles adgangskoder. En SQL-injektionsfejl gør det muligt for angriberen at hente adgangskodefilen. Alle usaltede hash kan blive brute forceret på ingen tid, mens de saltede adgangskoder ville tage tusinder af år.

(*Usaltede hashes – Salt er en tilfældig data tilføjet til de originale data. Salt tilføjes til adgangskoden før hash)

Anbefalinger

1. Sørg for passende stærke standardalgoritmer. Opret ikke egne kryptografiske algoritmer. Brug kun godkendte offentlige algoritmer såsom AES, RSA public key kryptografi og SHA-256 osv.
2. Sørg for, at eksterne sikkerhedskopier er krypteret, men at nøglerne administreres og sikkerhedskopieres separat.

Kunne ikke begrænse URL-adgang

Description

Webapplikationer kontrollerer URL-adgangsrettigheder, før de gengiver beskyttede links og knapper. Applikationer skal udføre lignende adgangskontrol, hver gang disse sider åbnes.

I de fleste af applikationerne præsenteres de privilegerede sider, placeringer og ressourcer ikke for de privilegerede brugere.

Ved et intelligent gæt kan en angriber få adgang til privilegiesider. En hacker kan få adgang til følsomme sider, aktivere funktioner og se fortrolige oplysninger.

Implikation

• Brug af denne sårbarhedsangriber kan få adgang til de uautoriserede URL'er uden at logge ind på applikationen og udnytte sårbarheden. En hacker kan få adgang til følsomme sider, aktivere funktioner og se fortrolige oplysninger.

Sårbare objekter:

• URL'er

Eksempler

1. Angriberen bemærker, at URL'en angiver rollen som "/user/getaccounts." Han ændrer som "/admin/getaccounts".
2. En angriber kan tilføje en rolle til URL'en.

http://www.vulnerablsite.com kan ændres som http://www.vulnerablesite.com/admin

Anbefalinger

1. Implementer stærk adgangskontrol.
2. Autentificerings- og autorisationspolitikker bør være rollebaserede.
3. Begræns adgangen til uønskede URL'er.

Utilstrækkelig beskyttelse af transportlag

Description

Omhandler informationsudveksling mellem brugeren (klienten) og serveren (applikationen). Applikationer transmitterer ofte følsomme oplysninger som autentificeringsdetaljer, kreditkortoplysninger og sessionstokens over et netværk.

Ved at bruge svage algoritmer eller ved at bruge udløbne eller ugyldige certifikater eller ikke bruge SSL kan kommunikationen blive eksponeret for upålidelige brugere, hvilket kan kompromittere en webapplikation og eller stjæle følsomme oplysninger.

Implikation

• Ved at gøre brug af denne websikkerhedssårbarhed kan en angriber opsnuse legitime brugers legitimationsoplysninger og få adgang til applikationen.
• Kan stjæle kreditkortoplysninger.

Sårbare genstande

• Data sendt over netværket.

Anbefalinger

1. Aktiver sikker HTTP og håndhæv kun legitimationsoplysninger over HTTPS.
2. Sørg for, at dit certifikat er gyldigt og ikke er udløbet.

eksempler:

1. Et program, der ikke bruger SSL, vil en angriber blot overvåge netværkstrafikken og observere en autentificeret offersessionscookie. En angriber kan stjæle den cookie og udføre Man-in-the-Middle-angreb.

Uvaliderede omdirigeringer og videresendelser

Description

Webapplikationen bruger få metoder til at omdirigere og videresende brugere til andre sider til et bestemt formål.

Hvis der ikke er nogen ordentlig validering, mens de omdirigerer til andre sider, kan angribere gøre brug af dette og kan omdirigere ofre til phishing- eller malware-websteder eller bruge forwards til at få adgang til uautoriserede sider.

Implikation

• En angriber kan sende en URL til brugeren, der indeholder en ægte URL tilføjet en kodet ondsindet URL. En bruger ved blot at se den ægte del af den angribers sendte URL kan gennemse den og kan blive et offer.

Eksempler

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Ændret til

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Anbefalinger

1. Du skal blot undgå at bruge omdirigeringer og videresendelser i applikationen. Hvis det bruges, skal du ikke involvere brugen af ​​brugerparametre til at beregne destinationen.
2. Hvis destinationsparametrene ikke kan undgås, skal du sikre dig, at den angivne værdi er gyldig og godkendt til brugeren.