OWASP eller Open Web Security Project är en ideell välgörenhetsorganisation som fokuserar på att förbättra säkerheten för programvara och webbapplikationer.
Organisationen publicerar en lista över de bästa säkerhetsproblemen på webben baserat på data från olika säkerhetsorganisationer.
Webbsäkerhetsproblemen prioriteras beroende på exploaterbarhet, detekterbarhet och inverkan på programvaran.
- Utnyttjbarhet -
Vad behövs för att utnyttja säkerhetsproblemet? Högsta utnyttjbarhet 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.
- Slag eller skada -
Hur stor skada kommer att göras om säkerhetsproblemen utsätts för eller attackeras? Högsta är fullständig systemkrasch och lägsta är ingenting alls.
Huvudsyftet med OWASP Top 10 är att utbilda utvecklare, designers, chefer, arkitekter och organisationer om de viktigaste säkerhetsproblemen.
De 10 bästa säkerhetsproblemen enligt OWASP Top 10 är:
- SQL-injektion
- Cross Site Scripting
- Trasig autentisering och sessionshantering
- Osäkra direkta referenser
- Förfalskning på begäran över flera platser
- Felaktig konfiguration av säkerhet
- Osäker kryptografisk lagring
- Det gick inte att begränsa URL-åtkomst
- Otillräckligt skydd för transportlager
- Ogiltiga omdirigeringar och framåt
SQL-injektion
Beskrivning
Injektion är en säkerhetsproblem som gör det möjligt för en angripare att ändra SQL-satser för backend genom att manipulera de data som användaren tillhandahåller.
Injektion sker när användarinmatningen skickas till en tolk som en del av kommandot eller frågan och lurar tolken att utföra oavsiktliga kommandon och ger åtkomst till obehörig data.
SQL-kommandot som när det körs av webbapplikationen också kan exponera backend-databasen.
Inblandning
- En angripare kan injicera skadligt innehåll i de utsatta fälten.
- Känsliga data som användarnamn, lösenord etc. kan läsas från databasen.
- Databasdata kan modifieras (Infoga / Uppdatera / Radera).
- Administration kan utföras på databasen
Sårbara objekt
- Inmatningsfält
- Webbadresser som interagerar med databasen.
Exempel:
- SQL-injektion på inloggningssidan
Logga in på ett program utan att ha giltiga referenser.
Giltigt användarnamn är tillgängligt och lösenord är inte tillgängligt.
Test-URL: http://demo.testfire.net/default.aspx
Användarnamn: sjones
Lösenord: 1 = 1 'eller pass123
SQL-fråga skapades och skickades till tolk enligt nedan
VÄLJ * FRÅN användare VAR Användarnamn = sjones OCH lösenord = 1 = 1 'eller pass123;
Rekommendationer
- Vit som anger inmatningsfälten
- Undvik att visa detaljerade felmeddelanden som är användbara för en angripare.
Cross Site Scripting
Beskrivning
Cross Site Scripting är också kort känt som XSS.
XSS-sårbarheter riktar sig till skript som är inbäddade i en sida som körs på klientsidan, dvs. användarbläddraren snarare än på serversidan. Dessa brister kan uppstå när applikationen tar otillförlitliga data och skickar dem till webbläsaren utan korrekt validering.
Angripare kan använda XSS för att utföra skadliga skript på användarna i detta fall offerbläddrare. Eftersom webbläsaren inte kan veta om skriptet är tillförlitligt eller inte kommer skriptet att köras och angriparen kan kapa sessionskakor, avlägsna webbplatser eller omdirigera användaren till en oönskad och skadlig webbplats.
XSS är en attack som gör det möjligt för angriparen att utföra skript i offrets webbläsare.
Inblandning:
- Genom att använda denna säkerhetsproblem kan en angripare injicera skript i applikationen, stjäla sessionskakor, avlägsna webbplatser och kan köra skadlig kod på offrets maskiner.
Sårbara objekt
- Inmatningsfält
- URL: er
Exempel
1. http://www.vulnerablesite.com/home ?" < script > alert(" xss") script >
Ovanstående skript när det körs i en webbläsare visas en meddelandefält om webbplatsen är sårbar för XSS.
Den allvarligare attacken kan göras om angriparen vill visa eller lagra session-cookie.
2. http://demo.testfire.net/search.aspx?txtSearch
Ovanstående skript när det körs laddar webbläsaren 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
- Inmatningsfält för vitlistning
- Ingångskodning
Trasig autentisering och sessionshantering
Beskrivning
Webbplatserna skapar vanligtvis en sessionskaka och session-ID för varje giltig session, och dessa kakor innehåller känsliga uppgifter som användarnamn, lösenord etc. När sessionen avslutas antingen genom att logga ut eller webbläsaren stängs plötsligt, bör dessa kakor ogiltiga, dvs. för varje session det borde finnas en ny cookie.
Om kakorna inte ogiltigförklaras finns känsliga data i systemet. Till exempel, en användare som använder en offentlig dator (Cyber Cafe), kakorna på den sårbara webbplatsen sitter i systemet och utsätts för en angripare. En angripare använder samma offentliga dator efter en tid, känsliga data ä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 plötsligt. En angripare använder samma system, när man surfar på samma utsatta webbplats öppnas offrets tidigare session. Angriparen kan göra vad han vill göra genom att stjäla profilinformation, kreditkortsinformation etc.
En kontroll bör göras för att hitta styrkan i autentiseringen och sessionshanteringen. Nycklar, sessionstoken, cookies bör implementeras ordentligt utan att lösenord äventyras.
Sårbara objekt
- Sessions-ID som exponeras på URL kan leda till attacker för fixering av sessioner.
- Sessions-ID: n samma före och efter utloggning och inloggning.
- Sessionstimeouts implementeras inte korrekt.
- Ansökan tilldelar samma session-ID för varje ny session.
- Autentiserade delar av applikationen skyddas med SSL och lösenord lagras i hasht eller krypterat format.
- Sessionen kan återanvändas av en användare med låg privilegium.
Inblandning
- Genom att använda denna sårbarhet kan en angripare kapa en session, få obehörig åtkomst till systemet vilket möjliggör avslöjande och modifiering av obehörig information.
- Sessionerna kan vara höga med hjälp av stulna cookies eller sessioner med XSS.
Exempel
- Flygbolagsbokningsapplikationen stöder URL-omskrivning och lägger in session-ID 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 sessionens ID och kan användas för att göra obehöriga ändringar eller missbruka de sparade kreditkortsuppgifterna.
- En applikation är sårbar för XSS, genom vilken en angripare kan komma åt session-ID och kan användas för att kapa sessionen.
- Tidsgränser för applikationer ä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 bort. Angriparen använder samma webbläsare en tid senare och sessionen autentiseras.
Rekommendationer
- Alla autentiserings- och sessionshanteringskrav bör definieras enligt OWASP Application Security Verification Standard.
- Utsätt aldrig några referenser i webbadresser eller loggar.
- Starka ansträngningar bör också göras för att undvika XSS-brister som kan användas för att stjäla session-ID: n.
Osäkra direkta referenser
Beskrivning
Det inträffar när en utvecklare exponerar en referens till ett internt implementeringsobjekt, till exempel 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 få åtkomst till obehöriga data.
Inblandning
- Med hjälp av denna sårbarhet kan en angripare få tillgång till obehöriga interna objekt, kan ändra data eller äventyra applikationen.
Sårbara objekt
- I webbadressen.
Exempel:
Om du ändrar "userid" i följande URL kan en angripare visa andra användares information.
http://www.vulnerablesite.com/userid=123 Ändrad till http://www.vulnerablesite.com/userid=124
En angripare kan visa information om andra genom att ändra användar-ID-värdet.
Rekommendationer:
- Implementera åtkomstkontrollkontroller.
- Undvik att exponera objektreferenser i webbadresser.
- Verifiera auktorisering för alla referensobjekt.
Förfalskning på begäran över flera platser
Beskrivning
Cross Site Request Forgery är en förfalskad begäran från cross site.
CSRF-attack är en attack som inträffar när en skadlig webbplats, e-post eller ett 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 offrets webbläsare att skicka en förfalskad HTTP-begäran, inklusive offrets sessionskaka 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 den är inloggad på den ursprungliga webbplatsen, data kommer att stjälas från webbplatsen.
Inblandning
- Att använda denna sårbarhet som en angripare kan ändra användarprofilinformation, ändra status, skapa en ny användare på administratörens vägnar etc.
Sårbara objekt
- Användarprofilsida
- Användarkontoformulär
- Sidan för affärstransaktioner
Exempel
Offret är inloggad på en banks webbplats med giltiga referenser. Han får e-post från en angripare som säger "Vänligen klicka här för att donera $ 1 för att orsaka."
När offret klickar på det 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 nedanför begäran och bäddar in en knapp som säger "Jag stöder orsaken."
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
- Mandatanvändarens närvaro när han utför känsliga åtgärder.
- Implementera mekanismer som CAPTCHA, Re-Authentication och Unique Request Tokens.
Felaktig konfiguration av säkerhet
Beskrivning
Säkerhetskonfiguration måste definieras och distribueras för applikationen, ramverk, applikationsserver, webbserver, databasserver och plattform. 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 denna sårbarhet kan angriparen räkna upp den underliggande informationen om teknik och applikationsservers version, databasinformation och få information om applikationen för att få några fler attacker.
Sårbara föremål
- URL
- Formfält
- Inmatningsfält
Exempel
- 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.
- Kataloglistning är inte inaktiverad på din server. Attacker upptäcker och kan helt enkelt lista kataloger för att hitta valfri fil.
Rekommendationer
- En stark applikationsarkitektur som ger god separation och säkerhet mellan komponenterna.
- Ändra standard användarnamn och lösenord.
- Inaktivera katalogförteckningar och implementera åtkomstkontrollkontroller.
Osäker kryptografisk lagring
Beskrivning
Osäker kryptografisk lagring är en vanlig sårbarhet som finns när känslig data inte lagras säkert.
Användaruppgifter, profilinformation, hälsoinformation, kreditkortsinformation etc. kommer under känslig information på en webbplats.
Dessa data kommer att lagras i applikationsdatabasen. När dessa data lagras felaktigt genom att inte använda kryptering eller hashing * kommer de att vara sårbara för angriparna.
(* Hashing är transformation 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ådana svagt skyddade data för att utföra identitetsstöld, kreditkortsbedrägerier eller andra brott.
Sårbara föremål
- Applikationsdatabas.
Exempel
I en av bankapplikationerna använder lösenordsdatabasen osaltad hash * för att lagra allas lösenord. En SQL-injektionsfel gör det möjligt för angriparen att hämta lösenordsfilen. Alla osaltade haschar kan tvingas på kort tid, medan de saltade lösenorden skulle ta tusentals år.
(* Osaltade Hashes - Salt är en slumpmässig data som läggs till originaldata. Salt läggs till lösenordet innan hashing)
Rekommendationer
- Säkerställ lämpliga starka standardalgoritmer. Skapa inte egna kryptografiska algoritmer. Använd endast godkända offentliga algoritmer som AES, RSA-nyckelkryptografi och SHA-256, etc.
- Se till att säkerhetskopior utanför webbplatsen är krypterade, men nycklarna hanteras och säkerhetskopieras separat.
Det gick inte att begränsa URL-åtkomst
Beskrivning
Webbapplikationer kontrollerar URL-åtkomsträttigheter innan de gör skyddade länkar och knappar. Applikationer måste utföra liknande kontroller varje gång dessa sidor öppnas.
I de flesta applikationer presenteras inte de privilegierade sidorna, platserna och resurserna för de privilegierade användarna.
Genom en intelligent gissning kan en angripare komma åt behörighetssidor. En angripare kan komma åt känsliga sidor, åberopa funktioner och visa konfidentiell information.
Inblandning
- Att använda denna sårbarhetsangripare kan få tillgång till obehöriga webbadresser utan att logga in i applikationen och utnyttja sårbarheten. En angripare kan komma åt känsliga sidor, åberopa funktioner och visa konfidentiell information.
Sårbara objekt:
- URL: er
Exempel
- Attacker märker att URL: n anger rollen som "/ user / getaccounts." Han ändrar sig som "/ admin / getaccounts".
- En angripare kan lägga till roll i URL: en.
http://www.vulnerablsite.com kan ändras som http://www.vulnerablesite.com/admin
Rekommendationer
- Implementera starka åtkomstkontrollkontroller.
- Verifierings- och auktoriseringspolicyer bör vara rollbaserade.
- Begränsa åtkomsten till oönskade webbadresser.
Otillräckligt skydd för transportlager
Beskrivning
Hanterar informationsutbyte mellan användaren (klienten) och servern (applikationen). Applikationer överför ofta känslig information som autentiseringsinformation, kreditkortsinformation och sessionstoken över ett nätverk.
Genom att använda svaga algoritmer eller använda utgångna eller ogiltiga certifikat eller 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 denna webbsäkerhetsproblem kan en angripare sniffa legitima användares referenser och få tillgång till applikationen.
- Kan stjäla kreditkortsinformation.
Sårbara föremål
- Data skickas över nätverket.
Rekommendationer
- Aktivera säker HTTP och genomdriv endast referensöverföring via HTTPS.
- Se till att ditt certifikat är giltigt och inte har upphört att gälla.
Exempel:
1. En applikation som inte använder SSL, en angripare övervakar helt enkelt nätverkstrafik och observerar en autentiserad cookie för offretsession. En angripare kan stjäla den kakan och utföra Man-in-the-Middle-attack.
Ogiltiga omdirigeringar och framåt
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 vid omdirigering till andra sidor kan angripare använda detta och kan omdirigera offer till nätfiske- eller skadlig webbplats eller använda vidarebefordran för att komma åt obehöriga sidor.
Inblandning
- En angripare kan skicka en URL till användaren som innehåller en äkta URL bifogad med kodad skadlig URL. En användare genom att bara se den äkta delen av angriparens skickade URL kan 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
- Undvik helt enkelt att använda omdirigeringar och framåt i applikationen. Om det används ska du inte använda användarparametrar för att beräkna destinationen.
- Om målparametrarna inte kan undvikas, se till att det angivna värdet är giltigt och godkänt för användaren.
Den här artikeln har bidragit av Prasanthi Eati