OWASP eller Open Web Security Project er en ideell veldedighetsorganisasjon som fokuserer på å forbedre sikkerheten til programvare og webapplikasjoner.
Organisasjonen publiserer en liste over de største sikkerhetsproblemene på nettet, basert på dataene fra ulike sikkerhetsorganisasjoner.
Nettsikkerhetssårbarhetene prioriteres avhengig av utnyttbarhet, detekterbarhet og innvirkning på programvare.
- Utnyttbarhet -
Hva er nødvendig for å utnytte sikkerhetsproblemet? Høyest utnyttbarhet når angrepet bare trenger nettleser og det laveste er avansert programmering og verktøy.
- Påvisbarhet -
Hvor enkelt er det å oppdage trusselen? Høyest er informasjonen som vises på URL, skjema eller feilmelding, og den laveste er kildekoden.
- Påvirkning eller skade -
Hvor mye skade vil bli gjort hvis sikkerhetsproblemet blir utsatt eller angrepet? Høyeste er fullstendig systemkrasj og laveste er ingenting.
Hovedmålet med OWASP Top 10 er å utdanne utviklere, designere, ledere, arkitekter og organisasjoner om de viktigste sikkerhetsproblemene.
Topp 10 sikkerhetsproblemer i henhold til OWASP Topp 10 er:
- SQL Injection
- Cross Site Scripting
- Broken Authentication and Session Management
- Usikre referanser til direkte objekter
- Forfalskning på tvers av nettstedet
- Feilkonfigurasjon av sikkerhet
- Usikker kryptografisk lagring
- Manglende begrensning av URL-tilgang
- Utilstrekkelig beskyttelse av transportlaget
- Uvaliderte viderekoblinger og spoler
SQL Injection
Beskrivelse
Injeksjon er et sikkerhetsproblem som gjør det mulig for en angriper å endre SQL-setninger for backend ved å manipulere brukernes data.
Injeksjon skjer når brukerinngangen sendes til en tolk som en del av kommandoen eller spørringen og lurer tolken til å utføre utilsiktede kommandoer og gir tilgang til uautoriserte data.
SQL-kommandoen som når den kjøres av et webapplikasjon, også kan avsløre back-end-databasen.
Implikasjon
- En angriper kan injisere skadelig innhold i de sårbare feltene.
- Sensitive data som brukernavn, passord osv. Kan leses fra databasen.
- Databasedata kan endres (Sett inn / oppdater / slett).
- Administrasjonsoperasjoner kan utføres på databasen
Sårbare gjenstander
- Inndatafelt
- URL-er som samhandler med databasen.
Eksempler:
- SQL-injeksjon på påloggingssiden
Logge på et program uten å ha gyldig legitimasjon.
Gyldig brukernavn er tilgjengelig, og passord er ikke tilgjengelig.
Test-URL: http://demo.testfire.net/default.aspx
Brukernavn: sjones
Passord: 1 = 1 'eller pass123
SQL-spørring opprettet og sendt til tolk som nedenfor
VELG * FRA brukere WHERE User_Name = sjones AND Password = 1 = 1 'or pass123;
Anbefalinger
- Hvit som viser inntastingsfeltene
- Unngå å vise detaljerte feilmeldinger som er nyttige for en angriper.
Cross Site Scripting
Beskrivelse
Cross Site Scripting er også kort kjent som XSS.
XSS-sårbarheter er målrettet mot skripter som er innebygd i en side som utføres på klientsiden, dvs. brukerens nettleser i stedet for på serversiden. Disse feilene kan oppstå når applikasjonen tar upålitelige data og sender dem til nettleseren uten riktig validering.
Angripere kan bruke XSS til å utføre ondsinnede skript på brukerne i dette tilfellet offer-nettlesere. Siden nettleseren ikke kan vite om skriptet er pålitelig eller ikke, vil skriptet kjøres, og angriperen kan kapre økt-informasjonskapsler, ødelegge nettsteder eller omdirigere brukeren til uønskede og ondsinnede nettsteder.
XSS er et angrep som gjør det mulig for angriperen å utføre skriptene i offerets nettleser.
Implikasjon:
- Ved å bruke dette sikkerhetsproblemet kan en angriper injisere skript i applikasjonen, stjele økt-informasjonskapsler, ødelegge nettsteder og kjøre skadelig programvare på offerets maskiner.
Sårbare gjenstander
- Inndatafelt
- URLer
Eksempler
1. http://www.vulnerablesite.com/home?" < script > alert(" xss") script >
Ovenstående skript når det kjøres i en nettleser, vises en meldingsboks hvis nettstedet er sårbart for XSS.
Det mer alvorlige angrepet kan gjøres hvis angriperen vil vise eller lagre økt-informasjonskapsel.
2. http://demo.testfire.net/search.aspx?txtSearch
Ovenstående skript når det kjøres, vil nettleseren laste en usynlig ramme som peker til http://google.com .
Angrepet kan gjøres alvorlig ved å kjøre et ondsinnet skript i nettleseren.
Anbefalinger
- Hvite oppføringsfelt
- Inngang Utgangskoding
Broken Authentication and Session Management
Beskrivelse
Nettstedene oppretter vanligvis en økt-informasjonskapsel og økt-ID for hver gyldig økt, og disse informasjonskapslene inneholder sensitive data som brukernavn, passord, etc. Når økten avsluttes enten ved avlogging eller nettleser lukket brått, bør disse informasjonskapslene ugyldiggjøres, dvs. for hver økt. det skulle komme en ny informasjonskapsel.
Hvis informasjonskapslene ikke ugyldiggjøres, vil sensitive data eksistere i systemet. For eksempel sitter en bruker som bruker en offentlig datamaskin (Cyber Cafe), informasjonskapslene til det sårbare nettstedet på systemet og utsettes for en angriper. En angriper bruker den samme offentlige datamaskinen etter en tid, de sensitive dataene er kompromittert.
På samme måte lukker en bruker bruker en offentlig datamaskin, i stedet for å logge av, nettleseren brått. En angriper bruker det samme systemet. Når du surfer på det samme sårbare nettstedet, vil den forrige økten til offeret bli åpnet. Angriperen kan gjøre hva han vil gjøre ved å stjele profilinformasjon, kredittkortinformasjon, etc.
Det bør gjøres en sjekk for å finne styrken til autentisering og øktadministrasjon. Nøkler, sesjonstokener, informasjonskapsler bør implementeres ordentlig uten å gå på bekostning av passord.
Sårbare gjenstander
- Sessions-ID-er eksponert på URL kan føre til angrep med øktfiksering.
- Sesjons-ID er like før og etter avlogging og pålogging.
- Sessionstimeouts er ikke implementert riktig.
- Søknaden tildeler samme økt-ID for hver nye økt.
- Autentiserte deler av applikasjonen er beskyttet ved hjelp av SSL og passord lagres i hash eller kryptert format.
- Økten kan brukes på nytt av en bruker med lite privilegium.
Implikasjon
- Ved å benytte seg av dette sårbarheten, kan en angriper kapre en økt, få uautorisert tilgang til systemet som tillater avsløring og endring av uautorisert informasjon.
- Øktene kan være høye ved å bruke stjålne informasjonskapsler eller økter ved hjelp av XSS.
Eksempler
- Søknaden om flyreservasjon støtter URL-omskriving, og legger økt-ID-er inn i URL-en:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Salg av billetter til Maldivene)
En godkjent bruker av nettstedet vil fortelle vennene sine om salget og sender en e-post. Vennene mottar økt-ID og kan brukes til å gjøre uautoriserte modifikasjoner eller misbruke de lagrede kredittkortopplysningene.
- Et program er sårbart for XSS, der en angriper kan få tilgang til økt-ID-en og kan brukes til å kapre økten.
- Søknads tidsavbrudd er ikke satt riktig. Brukeren bruker en offentlig datamaskin og lukker nettleseren i stedet for å logge av og går bort. Angriperen bruker samme nettleser en stund senere, og økten er autentisert.
Anbefalinger
- Alle autentiserings- og øktadministrasjonskrav bør defineres i henhold til OWASP Application Security Verification Standard.
- Utsett aldri legitimasjon i URL-er eller logger.
- Det bør også gjøres en sterk innsats for å unngå XSS-feil som kan brukes til å stjele økt-ID-er.
Usikre referanser til direkte objekter
Beskrivelse
Det oppstår når en utvikler avslører en referanse til et internt implementeringsobjekt, for eksempel en fil, katalog eller databasenøkkel som i URL eller som en FORM-parameter. Angriperen kan bruke denne informasjonen til å få tilgang til andre objekter og kan opprette et fremtidig angrep for å få tilgang til uautoriserte data.
Implikasjon
- Ved å bruke dette sikkerhetsproblemet kan en angriper få tilgang til uautoriserte interne objekter, endre data eller kompromittere applikasjonen.
Sårbare gjenstander
- I URL-en.
Eksempler:
Endring av "userid" i følgende URL kan få en angriper til å se informasjon om andre brukere.
http://www.vulnerablesite.com/userid=123 Endret til http://www.vulnerablesite.com/userid=124
En angriper kan se informasjon fra andre ved å endre bruker-ID-verdien.
Anbefalinger:
- Implementere kontroller for tilgangskontroll.
- Unngå å eksponere objektreferanser i URL-er.
- Bekreft autorisasjon til alle referanseobjekter.
Forfalskning på tvers av nettstedet
Beskrivelse
Cross Site Request Forgery er en forfalsket forespørsel som kom fra cross site.
CSRF-angrep er et angrep som oppstår når et ondsinnet nettsted, e-post eller program får brukerens nettleser til å utføre en uønsket handling på et klarert nettsted som brukeren for øyeblikket er autentisert for.
Et CSRF-angrep tvinger et pålogget offers nettleser til å sende en forfalsket HTTP-forespørsel, inkludert offerets økt-informasjonskapsel og annen automatisk inkludert autentiseringsinformasjon, til et sårbart webapplikasjon.
En lenke vil bli sendt av angriperen til offeret når brukeren klikker på URL-en når den er logget inn på det opprinnelige nettstedet, dataene blir stjålet fra nettstedet.
Implikasjon
- Å bruke dette sikkerhetsproblemet som angriper kan endre informasjon om brukerprofil, endre status, opprette en ny bruker på administratorens vegne, etc.
Sårbare gjenstander
- Brukerprofilside
- Brukerkonto skjemaer
- Virksomhetstransaksjonsside
Eksempler
Offeret er logget inn på et banks nettsted med gyldig legitimasjon. Han mottar e-post fra en angriper som sier "Vennligst klikk her for å donere $ 1 for å forårsake."
Når offeret klikker på det, opprettes en gyldig forespørsel om å donere $ 1 til en bestemt konto.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Angriperen fanger denne forespørselen og oppretter under forespørselen og legger inn en knapp som sier "Jeg støtter årsaken."
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Siden økten er autentisert og forespørselen kommer via banknettstedet, vil serveren overføre $ 1000 dollar til angriperen.
Anbefaling
- Mandatbrukerens tilstedeværelse mens de utfører sensitive handlinger.
- Implementere mekanismer som CAPTCHA, Re-Authentication og Unique Request Tokens.
Feilkonfigurasjon av sikkerhet
Beskrivelse
Sikkerhetskonfigurasjon må defineres og distribueres for applikasjon, rammer, applikasjonsserver, webserver, databaseserver og plattform. Hvis disse er riktig konfigurert, kan en angriper ha uautorisert tilgang til sensitive data eller funksjonalitet.
Noen ganger resulterer slike feil i fullstendig systemkompromiss. Å holde programvaren oppdatert er også god sikkerhet.
Implikasjon
- Ved å benytte seg av dette sikkerhetsproblemet kan angriperen telle den underliggende informasjonen om teknologi og applikasjonsserverversjon, databaseinformasjon og få informasjon om applikasjonen for å montere noen flere angrep.
Sårbare gjenstander
- URL
- Skjemafelt
- Inndatafelt
Eksempler
- Applikasjonsserverens administrasjonskonsoll installeres automatisk og fjernes ikke. Standardkontoer endres ikke. Angriperen kan logge på med standardpassord og kan få uautorisert tilgang.
- Katalogoppføring er ikke deaktivert på serveren din. Angriper oppdager og kan ganske enkelt liste opp kataloger for å finne hvilken som helst fil.
Anbefalinger
- En sterk applikasjonsarkitektur som gir god skille og sikkerhet mellom komponentene.
- Endre standard brukernavn og passord.
- Deaktiver katalogoppføringer og implementer kontroller for tilgangskontroll.
Usikker kryptografisk lagring
Beskrivelse
Usikker kryptografisk lagring er et vanlig sikkerhetsproblem som eksisterer når sensitive data ikke lagres sikkert.
Brukerlegitimasjonen, profilinformasjon, helseopplysninger, kredittkortinformasjon osv. Kommer under sensitiv datainformasjon på et nettsted.
Disse dataene lagres i applikasjonsdatabasen. Når disse dataene lagres feil ved ikke å bruke kryptering eller hashing *, vil de være sårbare for angriperne.
(* Hashing er transformasjon av strengtegnene til kortere strenger med fast lengde eller en nøkkel. For å dekryptere strengen, bør algoritmen som brukes til å danne nøkkelen være tilgjengelig)
Implikasjon
- Ved å bruke dette sikkerhetsproblemet kan en angriper stjele, modifisere slike svakt beskyttede data for å utføre identitetstyveri, kredittkortsvindel eller andre forbrytelser.
Sårbare gjenstander
- Søknadsdatabase.
Eksempler
I en av banksøknadene bruker passorddatabase usaltet hashes * for å lagre alles passord. En SQL-injeksjonsfeil gjør det mulig for angriperen å hente passordfilen. Alle de usaltede hasjene kan tvinges brute på kort tid, mens de saltede passordene vil ta tusenvis av år.
(* Usaltede hasjer - Salt er tilfeldige data som er lagt til de opprinnelige dataene. Salt legges til passordet før hashing)
Anbefalinger
- Sikre passende sterke standardalgoritmer. Ikke lag egne kryptografiske algoritmer. Bruk bare godkjente offentlige algoritmer som AES, RSA offentlig nøkkelkryptografi og SHA-256, etc.
- Sørg for at sikkerhetskopiering utenfor stedet er kryptert, men nøklene administreres og sikkerhetskopieres separat.
Manglende begrensning av URL-tilgang
Beskrivelse
Nettapplikasjoner sjekker URL-tilgangsrettigheter før de gjengir beskyttede lenker og knapper. Applikasjoner må utføre lignende tilgangskontrollkontroller hver gang disse sidene er tilgjengelige.
I de fleste applikasjoner blir ikke de privilegerte sidene, stedene og ressursene presentert for de privilegerte brukerne.
Ved en intelligent gjetning kan en angriper få tilgang til privilegiesider. En angriper kan få tilgang til sensitive sider, påkalle funksjoner og se konfidensiell informasjon.
Implikasjon
- Å bruke denne sårbarhetsangriperen kan få tilgang til de uautoriserte URL-ene, uten å logge på applikasjonen og utnytte sårbarheten. En angriper kan få tilgang til sensitive sider, påkalle funksjoner og se konfidensiell informasjon.
Sårbare gjenstander:
- URLer
Eksempler
- Angriper legger merke til at URL-en indikerer rollen som "/ bruker / get-kontoer." Han endrer seg som "/ admin / getaccounts".
- En angriper kan legge til en rolle i URL-en.
http://www.vulnerablsite.com kan endres som http://www.vulnerablesite.com/admin
Anbefalinger
- Implementere sterke tilgangskontrollsjekker.
- Retningslinjer for godkjenning og autorisasjon bør være rollebasert.
- Begrens tilgangen til uønskede nettadresser.
Utilstrekkelig beskyttelse av transportlaget
Beskrivelse
Behandler informasjonsutveksling mellom bruker (klient) og server (applikasjon). Applikasjoner overfører ofte sensitiv informasjon som autentiseringsdetaljer, kredittkortinformasjon og økttegn over et nettverk.
Ved å bruke svake algoritmer eller bruke utløpte eller ugyldige sertifikater eller ikke bruke SSL, kan kommunikasjonen bli eksponert for upålitelige brukere, noe som kan kompromittere et webapplikasjon og eller stjele sensitiv informasjon.
Implikasjon
- Ved å benytte seg av dette sikkerhetsproblemet på nettet, kan en angriper snuse legitime brukerlegitimasjonsopplysninger og få tilgang til applikasjonen.
- Kan stjele kredittkortinformasjon.
Sårbare gjenstander
- Data sendt over nettverket.
Anbefalinger
- Aktiver sikker HTTP og håndhev legitimasjonsoverføring bare over HTTPS.
- Forsikre deg om at sertifikatet ditt er gyldig og ikke utløpt.
Eksempler:
1. Et program som ikke bruker SSL, en angriper vil bare overvåke nettverkstrafikk og observerer en autentisert cookie for offerøkt. En angriper kan stjele informasjonskapselen og utføre Man-in-the-Middle-angrep.
Uvaliderte viderekoblinger og spoler
Beskrivelse
Nettapplikasjonen bruker få metoder for å omdirigere og videresende brukere til andre sider for et tiltenkt formål.
Hvis det ikke er riktig validering mens de viderekobler til andre sider, kan angripere benytte seg av dette og kan omdirigere ofre til nettfiskings- eller malware-sider, eller bruke videresendinger for å få tilgang til uautoriserte sider.
Implikasjon
- En angriper kan sende en URL til brukeren som inneholder en ekte URL som er lagt til med kodet ondsinnet URL. En bruker ved å bare se den ekte delen av angriperens sendte URL, kan bla gjennom den og kan bli et offer.
Eksempler
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Modifisert til
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Anbefalinger
- Unngå å bruke viderekoblinger og videresendinger i applikasjonen. Hvis det brukes, må du ikke involvere bruk av parametere i beregningen av destinasjonen.
- Hvis destinasjonsparametrene ikke kan unngås, må du sørge for at den oppgitte verdien er gyldig og godkjent for brukeren.
Denne artikkelen er bidratt av Prasanthi Eati