10 vanligaste sårbarheter i webbsäkerhet

OWASP eller Open Web Security Project är en ideell välgörenhetsorganisation fokuserad på att förbättra säkerheten för programvara och webbapplikationer.

Organisationen publicerar en lista över de främsta webbsäkerhetssårbarheterna baserad på data från olika säkerhetsorganisationer.

Webbsäkerhetssårbarheterna prioriteras beroende på exploateringsbarhet, detekterbarhet och påverkan på programvara.

• Exploateringsbarhet –Vad krävs för att utnyttja säkerhetssårbarheten? Högsta exploateringsbarhet när attacken endast behöver webbläsare och lägst är avancerad programmering och verktyg.
• Detekterbarhet – Hur lätt är det att upptäcka hotet? Högst är informationen som visas på URL, formulär eller felmeddelande och lägst är källkoden.
• Påverkan eller skada –Hur mycket skada görs om säkerhetssårbarheten avslöjas eller attackeras? Högst är fullständig systemkrasch och lägst är ingenting alls.

Huvudsyftet med OWASP Top 10 är att utbilda utvecklarna, designers, chefer, arkitekter och organisationer om de viktigaste säkerhetsbristerna.

Topp 10 säkerhetssårbarheter enligt OWASP Topp 10 är:

SQL Injection

BESKRIVNING

Injektion är en säkerhetsrisk som gör att en angripare kan ändra backend SQL uttalanden genom att manipulera de data som användaren tillhandahåller.

Injektion sker när användarinmatningen skickas till en tolk som en del av kommando eller fråga och lurar tolken att utföra oavsiktliga kommandon och ger tillgång till obehörig data.

SQL-kommandot som när det körs av webbapplikation också kan exponera back-end-databasen.

Inblandning

• En angripare kan injicera skadligt innehåll i de sårbara fälten.
• Känsliga data som användarnamn, lösenord, etc. kan läsas från databasen.
• Databasdata kan ändras (Infoga/Uppdatera/Ta bort).
• Administration Operationer kan köras på databasen

Sårbara föremål

• Inmatningsfält
• URL:er som interagerar med databasen.

Exempel:

• SQL-injektion på inloggningssidan

Logga in i en applikation utan att ha giltiga referenser.

Giltigt användarnamn är tillgängligt och lösenord är inte tillgängligt.

Testadress: http://demo.testfire.net/default.aspx

Användarnamn: sjones

Lösenord: 1=1′ eller pass123

SQL-fråga skapad och skickad till tolk enligt nedan

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

Rekommendationer

1. Vit listning av inmatningsfälten
2. Undvik att visa detaljerade felmeddelanden som är användbara för en angripare.

Cross Site Scripting

BESKRIVNING

Cross Site Scripting kallas också kort för XSS.

XSS-sårbarheter riktar sig mot skript inbäddade på en sida som exekveras på klientsidan, dvs användarens webbläsare istället för på serversidan. Dessa brister kan uppstå när applikationen tar otillförlitlig data och skickar den till webbläsaren utan korrekt validering.

Angripare kan använda XSS för att köra skadliga skript på användarna i det här fallet offerwebbläsare. Eftersom webbläsaren inte kan veta om skriptet är pålitligt eller inte, kommer skriptet att köras och angriparen kan kapa sessionscookies, förstöra webbplatser eller omdirigera användaren till en oönskad och skadlig webbplats.

XSS är en attack som gör att angriparen kan köra skripten på offrets webbläsare.

Inblandning:

• Genom att använda sig av denna säkerhetssårbarhet kan en angripare injicera skript i applikationen, stjäla sessionscookies, förstöra webbplatser och kan köra skadlig programvara på offrets maskiner.

Sårbara föremål

• Inmatningsfält
• Webbadresser

Exempel

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

Ovanstående skript när det körs i en webbläsare, kommer en meddelanderuta att visas om webbplatsen är sårbar för XSS.

Den allvarligare attacken kan göras om angriparen vill visa eller lagra sessionscookie.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com bredd = 500 höjd 500>

Ovanstående skript när det körs kommer webbläsaren att ladda en osynlig ram som pekar på http://google.com.

Attacken kan göras allvarlig genom att köra ett skadligt skript i webbläsaren.

Rekommendationer

1. Inmatningsfält för vitlista
2. Input Output-kodning

Trasig autentisering och sessionshantering

BESKRIVNING

Webbplatserna skapar vanligtvis en sessionscookie och sessions-ID för varje giltig session, och dessa cookies innehåller känslig information som användarnamn, lösenord etc. När sessionen avslutas antingen genom att logga ut eller att webbläsaren stängs abrupt, bör dessa cookies ogiltigförklaras, dvs. för varje session det borde finnas en ny kaka.

Om cookies inte ogiltigförklaras kommer den känsliga informationen att finnas i systemet. Till exempel, en användare som använder en offentlig dator (Cyber ​​Cafe), cookies från den sårbara webbplatsen sitter på systemet och exponeras för en angripare. En angripare använder samma offentliga dator efter en tid, den känsliga informationen äventyras.

På samma sätt stänger en användare som använder en offentlig dator istället för att logga ut webbläsaren abrupt. En angripare använder samma system, när den surfar på samma sårbara webbplats öppnas offrets föregående session. Angriparen kan göra vad han vill från att stjäla profilinformation, kreditkortsinformation etc.

En kontroll bör göras för att hitta styrkan i autentiseringen och sessionshanteringen. Nycklar, sessionstokens, cookies bör implementeras korrekt utan att kompromissa med lösenord.

Sårbara föremål

• Sessions-ID:n som exponeras på URL kan leda till sessionsfixeringsattack.
• Sessions-ID är samma före och efter utloggning och inloggning.
• Session Timeouts implementeras inte korrekt.
• Applikationen tilldelar samma sessions-ID för varje ny session.
• Autentiserade delar av applikationen skyddas med SSL och lösenord lagras i hashat eller krypterat format.
• Sessionen kan återanvändas av en lågprivilegierad användare.

Inblandning

• Genom att använda sig av denna sårbarhet kan en angripare kapa en session, få obehörig åtkomst till systemet som tillåter avslöjande och modifiering av obehörig information.
• Sessionerna kan vara höga med hjälp av stulna cookies eller sessioner med XSS.

Exempel

1. Flygbolagsreservationsapplikation stöder omskrivning av URL, genom att lägga in sessions-ID:n i URL:en:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Försäljning av biljetter till Maldiverna)En autentiserad användare av webbplatsen vill meddela sina vänner om försäljningen och skickar ett e-postmeddelande. Vännerna får sessions-ID och kan användas för att göra obehöriga ändringar eller missbruka de sparade kreditkortsuppgifterna.
2. En applikation är sårbar för XSS, genom vilken en angripare kan komma åt sessions-ID:t och kan användas för att kapa sessionen.
3. Programtidsgränser är inte korrekt inställda. Användaren använder en offentlig dator och stänger webbläsaren istället för att logga ut och går därifrån. Angriparen använder samma webbläsare en tid senare, och sessionen autentiseras.

Rekommendationer

1. Alla krav på autentisering och sessionshantering bör definieras enligt OWASP Application Security Verification Standard.
2. Avslöja aldrig några referenser i webbadresser eller loggar.
3. Starka ansträngningar bör också göras för att undvika XSS-brister som kan användas för att stjäla sessions-ID:n.

Osäkra direkta objektreferenser

BESKRIVNING

Det inträffar när en utvecklare exponerar en referens till ett internt implementeringsobjekt, såsom en fil, katalog eller databasnyckel som i URL eller som en FORM-parameter. Angriparen kan använda denna information för att komma åt andra objekt och kan skapa en framtida attack för att komma åt obehörig data.

Inblandning

• Genom att använda denna sårbarhet kan en angripare få åtkomst till obehöriga interna objekt, kan ändra data eller äventyra programmet.

Sårbara föremål

• I URL:en.

Exempel:

Att ändra "användar-ID" i följande URL kan få en angripare att se andra användares information.

http://www.vulnerablesite.com/userid=123 Ändrad till http://www.vulnerablesite.com/userid=124

En angripare kan se andras information genom att ändra användar-id-värdet.

Rekommendationer:

1. Genomför passerkontroller.
2. Undvik att exponera objektreferenser i webbadresser.
3. Verifiera behörighet för alla referensobjekt.

Förfalskning på begäran över flera platser

BESKRIVNING

Cross Site Request Forgery är en förfalskad begäran som kom från cross site.

CSRF-attack är en attack som inträffar när en skadlig webbplats, e-post eller program får en användares webbläsare att utföra en oönskad åtgärd på en betrodd webbplats som användaren för närvarande är autentiserad för.

En CSRF-attack tvingar ett inloggat offers webbläsare att skicka en förfalskad HTTP-begäran, inklusive offrets sessionscookie och all annan automatiskt inkluderad autentiseringsinformation, till en sårbar webbapplikation.

En länk kommer att skickas av angriparen till offret när användaren klickar på webbadressen när han är inloggad på den ursprungliga webbplatsen, data kommer att stjälas från webbplatsen.

Inblandning

• Att använda denna sårbarhet som angripare kan ändra användarprofilinformation, ändra status, skapa en ny användare på admins vägnar, etc.

Sårbara föremål

• Användarprofilsida
• Användarkontoformulär
• Affärstransaktionssida

Exempel

Offret är inloggad på en bankwebbplats med giltiga uppgifter. Han får e-post från en angripare som säger "Klicka här för att donera $1 till orsaken."

När offret klickar på den skapas en giltig begäran om att donera $1 till ett visst konto.

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

Angriparen fångar denna begäran och skapar nedanstående begäran och bäddar in en knapp som säger "Jag stöder orsak."

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

Eftersom sessionen är autentiserad och begäran kommer via bankens webbplats, skulle servern överföra $1000 dollar till angriparen.

Rekommendation

1. Beordra användarens närvaro när du utför känsliga åtgärder.
2. Implementera mekanismer som CAPTCHA, återautentisering och unika begärandetokens.

Felaktig konfiguration av säkerhet

BESKRIVNING

Säkerhetskonfiguration måste definieras och distribueras för applikationen, ramverken, applikationsservern, webbservern, databasservern och plattformen. Om dessa är korrekt konfigurerade kan en angripare ha obehörig åtkomst till känslig data eller funktionalitet.

Ibland resulterar sådana brister i fullständig systemkompromiss. Att hålla programvaran uppdaterad är också bra säkerhet.

Inblandning

• Genom att använda sig av denna sårbarhet kan angriparen räkna upp den underliggande tekniken och applikationsserverversionsinformation, databasinformation och få information om applikationen för att montera några fler attacker.

Sårbara föremål

• URL
• Form fält
• Inmatningsfält

Exempel

1. Applikationsserverns administratörskonsol installeras automatiskt och tas inte bort. Standardkonton ändras inte. Angriparen kan logga in med standardlösenord och kan få obehörig åtkomst.
2. Kataloglista är inte inaktiverad på din server. Angriparen upptäcker och kan helt enkelt lista kataloger för att hitta vilken fil som helst.

Rekommendationer

1. En stark applikationsarkitektur som ger bra separation och säkerhet mellan komponenterna.
2. Ändra standardanvändarnamn och lösenord.
3. Inaktivera kataloglistor och implementera kontroller av åtkomstkontroll.

Osäker kryptografisk lagring

BESKRIVNING

Osäker kryptografisk lagring är en vanlig sårbarhet som finns när den känsliga informationen inte lagras säkert.

Användaruppgifter, profilinformation, hälsodetaljer, kreditkortsinformation etc. hamnar under känslig datainformation på en webbplats.

Dessa data kommer att lagras i applikationsdatabasen. När denna data lagras felaktigt genom att inte använda kryptering eller hash*, kommer den att vara sårbar för angriparna.

(*Hashing är omvandling av strängtecken till kortare strängar med fast längd eller en nyckel. För att dekryptera strängen bör algoritmen som används för att bilda nyckeln vara tillgänglig)

Inblandning

• Genom att använda denna sårbarhet kan en angripare stjäla, modifiera sådan svagt skyddad data för att utföra identitetsstöld, kreditkortsbedrägerier eller andra brott.

Sårbara föremål

• Ansökningsdatabas.

Exempel

I en av bankapplikationerna använder lösenordsdatabasen osaltade hash* för att lagra allas lösenord. Ett SQL-injektionsfel gör att angriparen kan hämta lösenordsfilen. Alla osaltade hash kan tvingas fram på nolltid, medan de saltade lösenorden skulle ta tusentals år.

(*Osaltade hash – Salt är en slumpmässig data som läggs till originaldata. Salt läggs till lösenordet innan hash)

Rekommendationer

1. Säkerställ lämpliga starka standardalgoritmer. Skapa inte egna kryptografiska algoritmer. Använd endast godkända offentliga algoritmer som AES, RSA public key cryptography och SHA-256, etc.
2. Se till att externa säkerhetskopior är krypterade, men att nycklarna hanteras och säkerhetskopieras separat.

Det gick inte att begränsa URL-åtkomst

BESKRIVNING

Webbapplikationer kontrollerar URL-åtkomsträttigheter innan de renderar skyddade länkar och knappar. Applikationer måste utföra liknande åtkomstkontroller varje gång dessa sidor öppnas.

I de flesta av applikationerna presenteras inte de privilegierade sidorna, platserna och resurserna för de privilegierade användarna.

Genom en intelligent gissning kan en angripare komma åt privilegiesidor. En angripare kan komma åt känsliga sidor, anropa funktioner och se konfidentiell information.

Inblandning

• Genom att använda den här sårbarhetsangriparen kan du få tillgång till de obehöriga webbadresserna utan att logga in i programmet och utnyttja sårbarheten. En angripare kan komma åt känsliga sidor, anropa funktioner och se konfidentiell information.

Sårbara föremål:

• Webbadresser

Exempel

1. Angriparen märker att webbadressen indikerar rollen som "/user/getaccounts." Han ändrar som "/admin/getaccounts".
2. En angripare kan lägga till roll till URL:en.

http://www.vulnerablsite.com kan ändras som http://www.vulnerablesite.com/admin

Rekommendationer

1. Genomför starka kontroller av passerkontroll.
2. Autentiserings- och auktoriseringspolicyer bör vara rollbaserade.
3. Begränsa åtkomsten till oönskade webbadresser.

Otillräckligt transportlagerskydd

BESKRIVNING

Hanterar informationsutbyte mellan användaren (klienten) och servern (applikationen). Applikationer överför ofta känslig information som autentiseringsdetaljer, kreditkortsinformation och sessionstokens över ett nätverk.

Genom att använda svaga algoritmer eller använda utgångna eller ogiltiga certifikat eller att inte använda SSL kan kommunikationen exponeras för opålitliga användare, vilket kan äventyra en webbapplikation och eller stjäla känslig information.

Inblandning

• Genom att använda sig av denna webbsäkerhetssårbarhet kan en angripare sniffa legitima användares autentiseringsuppgifter och få tillgång till applikationen.
• Kan stjäla kreditkortsinformation.

Sårbara föremål

• Data skickas över nätverket.

Rekommendationer

1. Aktivera säker HTTP och framtvinga överföring av autentiseringsuppgifter endast över HTTPS.
2. Se till att ditt certifikat är giltigt och inte har gått ut.

Exempel:

1. En applikation som inte använder SSL, en angripare kommer helt enkelt att övervaka nätverkstrafik och observera en autentiserad offersessionscookie. En angripare kan stjäla den kakan och utföra Man-in-the-Middle-attack.

Ovaliderade omdirigeringar och vidarebefordran

BESKRIVNING

Webbapplikationen använder få metoder för att omdirigera och vidarebefordra användare till andra sidor för ett avsett syfte.

Om det inte finns någon korrekt validering när man omdirigerar till andra sidor, kan angripare använda sig av detta och kan omdirigera offer till nätfiske- eller malware-webbplatser, eller använda forwards för att komma åt obehöriga sidor.

Inblandning

• En angripare kan skicka en URL till användaren som innehåller en äkta URL med en kodad skadlig URL. En användare kan genom att bara se den äkta delen av angriparens webbadress bläddra i den och kan bli ett offer.

Exempel

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

Ändrad till

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

Rekommendationer

1. Undvik helt enkelt att använda omdirigeringar och vidarebefordran i applikationen. Om det används, använd inte användarparametrar för att beräkna destinationen.
2. Om destinationsparametrarna inte kan undvikas, se till att det angivna värdet är giltigt och auktoriserat för användaren.