10 vanligste sikkerhetssårbarheter for nett

OWASP eller Open Web Security Project er en ideell veldedig organisasjon som fokuserer på å forbedre sikkerheten til programvare og webapplikasjoner.

Organisasjonen publiserer en liste over de viktigste sikkerhetssårbarhetene på nett basert på data fra ulike sikkerhetsorganisasjoner.

Svakhetene i nettsikkerheten prioriteres avhengig av utnyttelsesevne, oppdagerbarhet og innvirkning på programvare.

• Utnyttbarhet –Hva trengs for å utnytte sikkerhetssårbarheten? Høyest utnyttelsesevne når angrepet kun trenger nettleser og lavest er avansert programmering og verktøy.
• Detekterbarhet – Hvor lett er det å oppdage trusselen? Høyest er informasjonen som vises på URL, skjema eller feilmelding, og lavest er kildekoden.
• Påvirkning eller skade –Hvor mye skade vil bli gjort hvis sikkerhetssårbarheten avsløres eller angripes? Høyeste er fullstendig systemkrasj og laveste er ingenting i det hele tatt.

Hovedmålet med OWASP Topp 10 er å utdanne utviklerne, designere, ledere, arkitekter og organisasjoner om de viktigste sikkerhetssårbarhetene.

Topp 10 sikkerhetssårbarheter i henhold til OWASP Topp 10 er:

SQL Injection

Tekniske beskrivelser

Injection er et sikkerhetssårbarhet som lar en angriper endre backend SQL uttalelser ved å manipulere dataene som er levert av brukeren.

Injeksjon skjer når brukerinndata sendes til en tolk som en del av kommando eller spørring og lurer tolken til å utføre utilsiktede kommandoer og gir tilgang til uautoriserte data.

SQL-kommandoen som når den utføres av webapplikasjonen 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).
• Administrasjon Operasjoner kan utføres på databasen

Sårbare objekter

• Inndatafelt
• URL-er som samhandler med databasen.

Eksempler:

• SQL-injeksjon på påloggingssiden

Logge på en applikasjon 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

SELECT * FROM Users WHERE User_Name = sjones OG Passord = 1=1′ eller pass123;

Anbefalinger

1. Hvit liste over inndatafeltene
2. Unngå å vise detaljerte feilmeldinger som er nyttige for en angriper.

Skripter på tvers av nettsteder

Tekniske beskrivelser

Cross Site Scripting er også kort kjent som XSS.

XSS-sårbarheter retter seg mot skript innebygd i en side som kjøres på klientsiden, dvs. brukernettleseren 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 offernettlesere. Siden nettleseren ikke kan vite om skriptet er pålitelig eller ikke, vil skriptet kjøres, og angriperen kan kapre øktinformasjonskapsler, ødelegge nettsteder eller omdirigere brukeren til et uønsket og ondsinnet nettsted.

XSS er et angrep som lar angriperen kjøre skriptene på offerets nettleser.

implikasjon:

• Ved å bruke denne sikkerhetssårbarheten kan en angriper injisere skript i applikasjonen, stjele øktinformasjonskapsler, ødelegge nettsteder og kjøre skadevare på offerets maskiner.

Sårbare objekter

• Inndatafelt
• Nettadresser

Eksempler

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

Skriptet ovenfor når det kjøres i en nettleser, vil en meldingsboks vises hvis nettstedet er sårbart for XSS.

Det mer alvorlige angrepet kan gjøres hvis angriperen ønsker å vise eller lagre øktinformasjonskapsel.

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

Skriptet ovenfor når det kjøres, vil nettleseren laste inn en usynlig ramme som peker til http://google.com.

Angrepet kan gjøres alvorlig ved å kjøre et ondsinnet skript på nettleseren.

Anbefalinger

1. Inndatafelt for hvitliste
2. Input Output-koding

Ødelagt autentisering og øktadministrasjon

Tekniske beskrivelser

Nettstedene lager vanligvis en økt-informasjonskapsel og økt-ID for hver gyldig økt, og disse informasjonskapslene inneholder sensitive data som brukernavn, passord osv. Når økten avsluttes enten ved utlogging eller brått lukket nettleser, bør disse informasjonskapslene ugyldiggjøres for hver økt. det skal være en ny informasjonskapsel.

Hvis informasjonskapslene ikke blir ugyldige, vil de sensitive dataene eksistere i systemet. For eksempel, en bruker som bruker en offentlig datamaskin (Cyber ​​Cafe), informasjonskapslene til det sårbare nettstedet sitter på systemet og blir utsatt for en angriper. En angriper bruker den samme offentlige datamaskinen etter en stund, og sensitive data kompromitteres.

På samme måte, en bruker som bruker en offentlig datamaskin, i stedet for å logge av, lukker han nettleseren brått. En angriper bruker det samme systemet, når du surfer på det samme sårbare nettstedet, åpnes den forrige økten til offeret. Angriperen kan gjøre hva han vil fra å stjele profilinformasjon, kredittkortinformasjon osv.

En sjekk bør gjøres for å finne styrken til autentiseringen og øktadministrasjonen. Nøkler, økttokens, informasjonskapsler skal implementeres riktig uten at det går på bekostning av passord.

Sårbare objekter

• Økt-ID-er eksponert på URL kan føre til øktfikseringsangrep.
• Økt-ID-er samme før og etter utlogging og pålogging.
• Tidsavbrudd for økter er ikke riktig implementert.
• Applikasjonen tildeler samme økt-ID for hver nye økt.
• Autentiserte deler av applikasjonen er beskyttet med SSL og passord lagres i hashet eller kryptert format.
• Økten kan gjenbrukes av en lavprivilegert bruker.

Implikasjon

• Ved å bruke denne 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 hjelp av stjålne informasjonskapsler eller økter med XSS.

Eksempler

1. Flyselskapsreservasjonsapplikasjon støtter URL-omskriving, og legger inn økt-ID-er i URL-en:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Salg av billetter til Maldivene)En autentisert bruker av nettstedet ønsker å fortelle vennene sine om salget og sender en e-post. Vennene mottar økt-IDen og kan brukes til å gjøre uautoriserte endringer eller misbruke de lagrede kredittkortdetaljene.
2. En applikasjon er sårbar for XSS, der en angriper kan få tilgang til økt-IDen og kan brukes til å kapre økten.
3. Tidsavbrudd for applikasjoner er ikke riktig angitt. Brukeren bruker en offentlig datamaskin og lukker nettleseren i stedet for å logge av og går. Angriperen bruker samme nettleser en tid senere, og økten blir autentisert.

Anbefalinger

1. Alle krav til autentisering og øktadministrasjon bør defineres i henhold til OWASP Application Security Verification Standard.
2. Utsett aldri legitimasjon i URL-er eller logger.
3. Sterk innsats bør også gjøres for å unngå XSS-feil som kan brukes til å stjele økt-ID-er.

Usikre direkte objektreferanser

Tekniske beskrivelser

Det oppstår når en utvikler eksponerer 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 objekter

• I URL-en.

Eksempler:

Å endre "bruker-ID" i følgende URL kan få en angriper til å se andre brukers informasjon.

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

En angriper kan se andres informasjon ved å endre bruker-ID-verdi.

Anbefalinger:

1. Gjennomføre kontroll av tilgangskontroll.
2. Unngå å eksponere objektreferanser i URL-er.
3. Bekreft autorisasjon til alle referanseobjekter.

Forfalskning på tvers av nettstedet

Tekniske beskrivelser

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 en brukers nettleser til å utføre en uønsket handling på et pålitelig nettsted som brukeren for øyeblikket er autentisert for.

Et CSRF-angrep tvinger nettleseren til et pålogget offer til å sende en forfalsket HTTP-forespørsel, inkludert offerets øktinformasjonskapsel og annen automatisk inkludert autentiseringsinformasjon, til en sårbar nettapplikasjon.

En lenke vil bli sendt av angriperen til offeret når brukeren klikker på URL-en når han er logget inn på den opprinnelige nettsiden, dataene vil bli stjålet fra nettsiden.

Implikasjon

• Ved å bruke denne sårbarheten som en angriper kan du endre brukerprofilinformasjon, endre status, opprette en ny bruker på administratorvegne osv.

Sårbare objekter

• Brukerprofilside
• Brukerkontoskjemaer
• Forretningstransaksjonsside

Eksempler

Offeret er logget inn på en banknettside med gyldig legitimasjon. Han mottar e-post fra en angriper som sier "Vennligst klikk her for å donere $1 til å forårsake."

Når offeret klikker på den, opprettes en gyldig forespørsel om å donere $1 til en bestemt konto.

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

Angriperen fanger opp denne forespørselen og oppretter forespørselen nedenfor og legger inn en knapp som sier "I Support Cause."

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

Siden økten er autentisert og forespørselen kommer via bankens nettsted, vil serveren overføre $1000 dollar til angriperen.

Anbefaling

1. Mandat brukerens tilstedeværelse mens de utfører sensitive handlinger.
2. Implementer mekanismer som CAPTCHA, re-autentisering og unike forespørselstokener.

Feilkonfigurasjon av sikkerhet

Tekniske beskrivelser

Sikkerhetskonfigurasjon må defineres og distribueres for applikasjonen, rammeverk, 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 å bruke dette sikkerhetsproblemet kan angriperen telle opp den underliggende teknologien og applikasjonsserverversjonsinformasjonen, databaseinformasjon og få informasjon om applikasjonen for å montere noen flere angrep.

Sårbare gjenstander

• URL
• Form Fields
• Inndatafelt

Eksempler

1. Applikasjonstjenerens administrasjonskonsoll installeres automatisk og fjernes ikke. Standardkontoer endres ikke. Angriperen kan logge på med standardpassord og kan få uautorisert tilgang.
2. Katalogoppføring er ikke deaktivert på serveren din. Angriperen oppdager og kan ganske enkelt liste kataloger for å finne hvilken som helst fil.

Anbefalinger

1. En sterk applikasjonsarkitektur som gir god separasjon og sikkerhet mellom komponentene.
2. Endre standard brukernavn og passord.
3. Deaktiver katalogoppføringer og implementer kontroll av tilgangskontroll.

Usikker kryptografisk lagring

Tekniske beskrivelser

Usikker kryptografisk lagring er en vanlig sårbarhet som eksisterer når sensitive data ikke lagres sikkert.

Brukerlegitimasjonen, profilinformasjonen, helseopplysningene, kredittkortinformasjonen osv. kommer inn under sensitiv datainformasjon på et nettsted.

Disse dataene vil bli lagret 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 denne sårbarheten kan en angriper stjele, endre slike svakt beskyttede data for å utføre identitetstyveri, kredittkortsvindel eller andre forbrytelser.

Sårbare gjenstander

• Søknadsdatabase.

Eksempler

I en av bankapplikasjonene bruker passorddatabasen usaltede hash* for å lagre alles passord. En SQL-injeksjonsfeil gjør at angriperen kan hente passordfilen. Alle usaltede hashen kan bli brutalt tvunget på kort tid, mens de saltede passordene ville ta tusenvis av år.

(*Usaltet hashes – Salt er tilfeldige data som legges til de originale dataene. Salt legges til passordet før hashing)

Anbefalinger

1. Sørg for passende sterke standardalgoritmer. Ikke lag egne kryptografiske algoritmer. Bruk kun godkjente offentlige algoritmer som AES, RSA offentlig nøkkelkryptering og SHA-256, etc.
2. Sørg for at sikkerhetskopier utenfor stedet er kryptert, men at nøklene administreres og sikkerhetskopieres separat.

Kunne ikke begrense URL-tilgang

Tekniske beskrivelser

Nettapplikasjoner sjekker URL-tilgangsrettigheter før de gjengir beskyttede lenker og knapper. Apper må utføre lignende tilgangskontroller hver gang disse sidene åpnes.

I de fleste applikasjonene blir ikke de privilegerte sidene, plasseringene og ressursene presentert for de privilegerte brukerne.

Ved en intelligent gjetning kan en angriper få tilgang til rettighetssider. En angriper kan få tilgang til sensitive sider, aktivere funksjoner og se konfidensiell informasjon.

Implikasjon

• Bruk av denne sårbarhetsangriperen kan få tilgang til de uautoriserte URL-ene uten å logge på programmet og utnytte sårbarheten. En angriper kan få tilgang til sensitive sider, aktivere funksjoner og se konfidensiell informasjon.

Sårbare objekter:

• Nettadresser

Eksempler

1. Angriperen legger merke til at URL-en indikerer rollen som "/user/getaccounts." Han endres som "/admin/getaccounts".
2. En angriper kan legge til rolle til URL-en.

http://www.vulnerablsite.com kan endres som http://www.vulnerablesite.com/admin

Anbefalinger

1. Implementer sterke adgangskontroller.
2. Retningslinjer for autentisering og autorisasjon bør være rollebasert.
3. Begrens tilgang til uønskede nettadresser.

Utilstrekkelig beskyttelse av transportlag

Tekniske beskrivelser

Omhandler informasjonsutveksling mellom bruker (klient) og server (applikasjon). Apper overfører ofte sensitiv informasjon som autentiseringsdetaljer, kredittkortinformasjon og økttokens 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, som kan kompromittere en nettapplikasjon og eller stjele sensitiv informasjon.

Implikasjon

• Ved å benytte seg av dette sikkerhetsproblemet på nett, kan en angriper snuse legitim brukers legitimasjon og få tilgang til applikasjonen.
• Kan stjele kredittkortinformasjon.

Sårbare gjenstander

• Data sendt over nettverket.

Anbefalinger

1. Aktiver sikker HTTP og fremtving overføring av legitimasjon kun over HTTPS.
2. Sørg for at sertifikatet ditt er gyldig og ikke utløpt.

Eksempler:

1. En applikasjon som ikke bruker SSL, vil en angriper ganske enkelt overvåke nettverkstrafikk og observere en autentisert offersession-cookie. En angriper kan stjele den informasjonskapselen og utføre Man-in-the-Middle-angrep.

Uvaliderte omdirigeringer og videresendinger

Tekniske beskrivelser

Nettapplikasjonen bruker få metoder for å omdirigere og videresende brukere til andre sider for et tiltenkt formål.

Hvis det ikke er riktig validering mens du omdirigerer til andre sider, kan angripere benytte seg av dette og kan omdirigere ofre til phishing- 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 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

1. Bare unngå å bruke omdirigeringer og videresendinger i applikasjonen. Hvis det brukes, må du ikke involvere bruk av brukerparametere for å beregne destinasjonen.
2. Hvis destinasjonsparametrene ikke kan unngås, sørg for at den oppgitte verdien er gyldig og autorisert for brukeren.