OWASP eller Open Web Security Project er en nonprofit velgørende organisation med fokus på at forbedre sikkerheden i software og webapplikationer.
Organisationen offentliggør en liste over de mest populære websikkerhedssårbarheder baseret på data fra forskellige sikkerhedsorganisationer.
Websikkerhedssårbarheder prioriteres afhængigt af udnyttelsesmuligheder, detekterbarhed og indvirkning på software.
- Udnyttelse -
Hvad er der nødvendigt for at udnytte sikkerhedssårbarheden? Højeste udnyttelsesgrad, når angrebet kun behøver en webbrowser, og det laveste er avanceret programmering og værktøjer.
- Registrerbarhed -
Hvor let er det at opdage truslen? Højest er oplysningerne, der vises på URL, formular eller fejlmeddelelse, og laveste kildekode.
- Påvirkning eller skader -
Hvor meget skade vil der blive gjort, hvis sikkerhedssårbarheden udsættes for eller angribes? Højeste er komplet systemnedbrud og laveste er slet ingenting.
Hovedformålet med OWASP Top 10 er at uddanne udviklere, designere, ledere, arkitekter og organisationer om de vigtigste sikkerhedssårbarheder.
Top 10 sikkerhedssårbarheder i henhold til OWASP Top 10 er:
- SQL-injektion
- Cross Site Scripting
- Brudt godkendelse og sessionsstyring
- Usikre direkte objekthenvisninger
- Forfalskning på tværs af websteder
- Fejlkonfiguration af sikkerhed
- Usikker kryptografisk opbevaring
- Manglende begrænsning af URL-adgang
- Utilstrækkelig beskyttelse af transportlag
- Uvaliderede omdirigeringer og fremad
SQL-injektion
Beskrivelse
Injektion er en sikkerhedssårbarhed, der gør det muligt for en hacker at ændre SQL-sætninger til backend ved at manipulere de brugerleverede data.
Injektion sker, når brugerindgangen sendes til en tolk som en del af kommando eller forespørgsel og nar 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 eksponere back-end-databasen.
Implikation
- En hacker 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).
- Administrationshandlinger kan udføres på databasen
Sårbare genstande
- Indtastningsfelter
- URL'er, der interagerer med databasen.
Eksempler:
- SQL-injektion på login-siden
Log ind på en applikation uden gyldig legitimationsoplysninger.
Gyldigt brugernavn er tilgængeligt, og adgangskode er ikke tilgængeligt.
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
VÆLG * FRA brugere HVOR User_Name = sjones AND Password = 1 = 1 'eller pass123;
Anbefalinger
- Hvid liste over indtastningsfelterne
- Undgå at vise detaljerede fejlmeddelelser, der er nyttige for en hacker.
Cross Site Scripting
Beskrivelse
Cross Site Scripting er også kort kendt som XSS.
XSS-sårbarheder er målrettet mod scripts indlejret i en side, der udføres på klientsiden, dvs. brugerbrowser snarere end 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, udføres scriptet, og angriberen kan kapre sessionscookies, ødelægge websteder eller omdirigere brugeren til et uønsket og ondsindet websted.
XSS er et angreb, der gør det muligt for angriberen at udføre scripts på offerets browser.
Implikation:
- Ved hjælp af denne sikkerhedssårbarhed kan en angriber injicere scripts i applikationen, stjæle sessionscookies, ødelægge websteder og kan køre malware på offerets 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, vises et meddelelsesfelt, hvis webstedet er sårbart over for XSS.
Det mere alvorlige angreb kan udføres, hvis angriberen vil vise eller gemme session-cookie.
2. http://demo.testfire.net/search.aspx?txtSearch
Ovenstående script, når browseren køres, indlæser en usynlig ramme, der peger på http://google.com .
Angrebet kan gøres alvorligt ved at køre et ondsindet script i browseren.
Anbefalinger
- Hvide listeinputfelter
- Input Output-kodning
Brudt godkendelse og sessionsstyring
Beskrivelse
Webstederne opretter normalt en session-cookie og et session-id for hver gyldig session, og disse cookies indeholder følsomme data som brugernavn, adgangskode osv. Når sessionen afsluttes enten ved logout eller browser lukket pludseligt, skal disse cookies ugyldiggøres, dvs. for hver session der skulle være en ny cookie.
Hvis cookies ikke ugyldiggøres, findes de følsomme data i systemet. For eksempel sidder en bruger, der bruger en offentlig computer (Cyber Cafe), cookies fra det sårbare sted på systemet og udsættes for en angriber. En hacker bruger den samme offentlige computer efter nogen tid, de følsomme data er kompromitteret.
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 offeret gennemgår det samme sårbare sted, åbnes den foregående session for offeret. Angriberen kan gøre hvad han vil ved at stjæle profiloplysninger, kreditkortoplysninger osv.
En kontrol skal udføres for at finde styrken i godkendelsen og styringen af sessionen. Nøgler, sessionstokener, cookies skal implementeres korrekt uden at gå på kompromis med adgangskoder.
Sårbare genstande
- Sessions-id'er, der er eksponeret på URL, kan føre til angreb af sessionsfiksering.
- Sessions-id'er er de samme før og efter logout og login.
- Sessionstimeouts implementeres ikke korrekt.
- Ansøgning tildeler samme session-id for hver nye session.
- Autentificerede dele af applikationen er beskyttet ved hjælp af SSL, og adgangskoder gemmes i hash eller krypteret format.
- Sessionen kan genbruges af en lavt privilegeret bruger.
Implikation
- Ved hjælp af denne sårbarhed kan en angriber kapre en session, få uautoriseret adgang til systemet, som muliggør afsløring og ændring af uautoriseret information.
- Sessionerne kan være jack-jacked ved hjælp af stjålne cookies eller sessioner ved hjælp af XSS.
Eksempler
- Luftfartsreservationsapplikation understøtter URL-omskrivning og sætter session-id'er i URL'en:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Salg af billetter til Maldiverne)
En godkendt bruger af webstedet vil fortælle sine venner om salget og sender en e-mail på tværs. Vennerne modtager session-id'et og kan bruges til at foretage uautoriserede ændringer eller misbruge de gemte kreditkortoplysninger.
- En applikation er sårbar over for XSS, hvorved en hacker kan få adgang til session-id'et og kan bruges til at kapre sessionen.
- Applikations timeouts 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 et stykke tid senere, og sessionen godkendes.
Anbefalinger
- Alle godkendelses- og sessionstyringskrav skal defineres som beskrevet i OWASP Application Security Verification Standard.
- Udsæt aldrig legitimationsoplysninger i webadresser eller logfiler.
- Der bør også gøres en stor indsats for at undgå XSS-fejl, som kan bruges til at stjæle session-id'er.
Usikre direkte objekthenvisninger
Beskrivelse
Det sker, når en udvikler udsætter en henvisning til et internt implementeringsobjekt, såsom en fil, bibliotek 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 hjælp af denne sårbarhed kan en hacker få adgang til uautoriserede interne objekter, kan ændre data eller kompromittere applikationen.
Sårbare genstande
- I URL'en.
Eksempler:
Ændring af "userid" i følgende URL kan få en hacker til at se andre brugers oplysninger.
http://www.vulnerablesite.com/userid=123 Ændret til http://www.vulnerablesite.com/userid=124
En hacker kan se andre oplysninger ved at ændre bruger-id-værdien.
Anbefalinger:
- Implementere adgangskontrolkontrol.
- Undgå at udsætte objektreferencer i webadresser.
- Bekræft autorisation til alle referenceobjekter.
Forfalskning på tværs af websteder
Beskrivelse
Forfalskning på tværs af websteder er en forfalsket anmodning, der kom fra tværsiden.
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 på offerets browser til at sende en forfalsket HTTP-anmodning, inklusive offerets session-cookie 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 den er logget ind på det originale websted, dataene bliver stjålet fra hjemmesiden.
Implikation
- Brug af denne sårbarhed som en angriber kan ændre brugerprofiloplysninger, ændre status, oprette en ny bruger på administratorens vegne osv.
Sårbare genstande
- Brugerprofil side
- Brugerkontoformularer
- Forretningstransaktionsside
Eksempler
Offeret er logget ind på et banks websted ved hjælp af gyldige legitimationsoplysninger. Han modtager mail fra en angriber, der siger "Klik her for at donere $ 1 til at forårsage."
Når offeret klikker på det, oprettes 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 i en knap, der siger "Jeg støtter årsag."
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Da sessionen er godkendt, og anmodningen kommer via bankens websted, vil serveren overføre $ 1000 dollars til angriberen.
Henstilling
- Mandatbrugerens tilstedeværelse under udførelse af følsomme handlinger.
- Implementere mekanismer som CAPTCHA, re-godkendelse og unikke anmodningstokens.
Fejlkonfiguration af sikkerhed
Beskrivelse
Sikkerhedskonfiguration skal defineres og implementeres til 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 mangler i komplet systemkompromis. At holde softwaren opdateret er også god sikkerhed.
Implikation
- Ved hjælp af denne sårbarhed kan angriberen tælle de underliggende teknologi- og applikationsservers versionoplysninger, databaseoplysninger og få oplysninger om applikationen for at montere nogle få flere angreb.
Sårbare genstande
- URL
- Formularfelter
- Indtastningsfelter
Eksempler
- Administrationskonsollen til applikationsserveren installeres automatisk og fjernes ikke. Standardkonti ændres ikke. Angriberen kan logge ind med standardadgangskoder og kan få uautoriseret adgang.
- Directory Listing er ikke deaktiveret på din server. Angriberen opdager og kan simpelthen liste mapper for at finde enhver fil.
Anbefalinger
- En stærk applikationsarkitektur, der giver god adskillelse og sikkerhed mellem komponenterne.
- Skift standard brugernavne og adgangskoder.
- Deaktiver katalogoversigter og implementer adgangskontrolkontrol.
Usikker kryptografisk opbevaring
Beskrivelse
Usikker kryptografisk lagring er en almindelig sårbarhed, der findes, når de følsomme data ikke lagres sikkert.
Brugerlegitimationsoplysninger, profiloplysninger, sundhedsoplysninger, kreditkortoplysninger osv. Kommer under følsomme dataoplysninger på et websted.
Disse data gemmes 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 hacker stjæle, ændre sådanne svagt beskyttede data for at udføre identitetstyveri, kreditkortsvindel eller andre forbrydelser.
Sårbare genstande
- Applikationsdatabase.
Eksempler
I en af bankapplikationerne bruger adgangskodedatabasen usaltet hash * til at gemme alles adgangskoder. En SQL-injektionsfejl giver angriberen mulighed for at hente adgangskodefilen. Alle usaltede hashes kan tvinges på et brutalt niveau på ingen tid, mens de saltede adgangskoder ville tage tusinder af år.
(* Usaltede hash - Salt er en tilfældig data, der føjes til de originale data. Salt føjes til adgangskoden før hashing)
Anbefalinger
- Sørg for passende stærke standardalgoritmer. Opret ikke egne kryptografiske algoritmer. Brug kun godkendte offentlige algoritmer som AES, RSA offentlig nøglekryptografi og SHA-256 osv.
- Sørg for, at sikkerhedskopier uden for webstedet er krypteret, men nøglerne administreres og sikkerhedskopieres separat.
Manglende begrænsning af URL-adgang
Beskrivelse
Webapplikationer kontrollerer URL-rettigheder, inden de gengiver beskyttede links og knapper. Applikationer skal udføre lignende adgangskontrolchecks hver gang disse sider åbnes.
I de fleste applikationer præsenteres de privilegerede sider, placeringer og ressourcer ikke for de privilegerede brugere.
Ved et intelligent gæt kan en hacker få adgang til privilegiesider. En hacker kan få adgang til følsomme sider, påberåbe sig 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, påberåbe sig funktioner og se fortrolige oplysninger.
Sårbare genstande:
- URL'er
Eksempler
- Angriber bemærker URL'en angiver rollen som "/ bruger / getaccounts." Han ændrer sig som "/ admin / getaccounts".
- En hacker kan tilføje en rolle til URL'en.
http://www.vulnerablsite.com kan ændres som http://www.vulnerablesite.com/admin
Anbefalinger
- Implementere stærke adgangskontrolkontroller.
- Autentificerings- og autorisationspolitikker bør være rollebaserede.
- Begræns adgang til uønskede webadresser.
Utilstrækkelig beskyttelse af transportlag
Beskrivelse
Beskæftiger sig med informationsudveksling mellem brugeren (klienten) og serveren (applikationen). Applikationer transmitterer ofte følsomme oplysninger som godkendelsesoplysninger, kreditkortoplysninger og sessionstokens over et netværk.
Ved at bruge svage algoritmer eller bruge udløbne eller ugyldige certifikater eller ikke bruge SSL kan kommunikationen blive eksponeret for ikke-tillid til brugere, hvilket kan kompromittere en webapplikation og eller stjæle følsomme oplysninger.
Implikation
- Ved hjælp af denne websikkerhedssårbarhed kan en angriber snuse legitime brugeres legitimationsoplysninger og få adgang til applikationen.
- Kan stjæle kreditkortoplysninger.
Sårbare genstande
- Data sendt over netværket.
Anbefalinger
- Aktivér sikker HTTP og håndhæv kun legitimationsoverførsel via HTTPS.
- Sørg for, at dit certifikat er gyldigt og ikke udløbet.
Eksempler:
1. En applikation, der ikke bruger SSL, overvåger en angriber simpelthen netværkstrafik og observerer en godkendt offer session session cookie. En hacker kan stjæle den cookie og udføre Man-in-the-Middle angreb.
Uvaliderede omdirigeringer og fremad
Beskrivelse
Webapplikationen bruger få metoder til at omdirigere og videresende brugere til andre sider til et bestemt formål.
Hvis der ikke er nogen korrekt validering under omdirigering til andre sider, kan angribere gøre brug af dette og kan omdirigere ofre til phishing- eller malware-sider eller bruge videresend til at få adgang til uautoriserede sider.
Implikation
- En hacker kan sende en URL til brugeren, der indeholder en ægte URL tilføjet med kodet ondsindet URL. En bruger ved bare at se den ægte del af angriberen sendt 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
- Undgå blot at bruge omdirigeringer og fremad i applikationen. Hvis det bruges, skal du ikke involvere brugen af brugerparametre til beregning af destinationen.
- Hvis destinationsparametrene ikke kan undgås, skal du sikre dig, at den leverede værdi er gyldig og godkendt til brugeren.
Denne artikel er bidraget af Prasanthi Eati