Phenquestions
Innehållsförteckning
- Databasinjektion
- Trasig autentisering
- Känslig exponering av data
- XML-externa enheter (XEE)
- Trasig åtkomstkontroll
- Felaktig konfiguration av säkerhet
- Cross-site Scripting (XSS)
- Osäker deserialisering
- Använda komponenter med kända sårbarheter
- Otillräcklig loggning och övervakning
Databasinjektion:
Om du skickar opålitliga data till tolk som en del av kommandot genom något område som tar användarinmatning i.e-formulärinmatning eller annat dataöverföringsområde uppstår injektionsfel. Angriparens skadliga frågor kan lura tolk till att utföra kommandon som kan visa konfidentiell information som användaren inte har behörighet att titta på. Till exempel i en SQL-injektionsattack, när formulärinmatningen inte är korrekt sanerad, kan angriparen komma in i SQL-databasen och komma åt dess innehåll utan auktorisering, bara genom att ange skadlig SQL-databaskod i ett formulär som förväntar sig en klartext. Varje typ av fält som tar användarens inmatning kan injiceras i.e-parametrar, miljövariabler, alla webbtjänster osv.
Applikationen är sårbar för injektionsattacket när användaruppgifterna inte saneras och valideras genom användning av dynamiska frågor utan att kontextmedveten flyr och användning av fientliga data direkt. Injektionsfel kan lätt upptäckas genom granskning av kod och med hjälp av automatiserade verktyg som skannrar och fuzzers. För att förhindra injektionsattacker finns det en viss åtgärd som kan vidtas som att separera data från kommandon och frågor, användning av ett säkert API som ger ett parametrerat gränssnitt, användning av "vitlista" validering av serverns ingång via verktyg som Snort, fly från specialtecken med hjälp av specifik flykt-syntax, etc.
En injektionsattack kan leda till en massiv dataförlust, avslöjande av konfidentiell information, nekande av åtkomst och det kan till och med leda till en fullständig övertagande av ansökan. Vissa SQL-kontroller som LIMIT kan användas för att kontrollera stora mängder dataförlust vid en attack. Vissa typer av injektionsattacker är SQL-, OS-, NoSQL-, LDAP-injektionsattacker.
Trasig autentisering:
Angripare kan komma åt användarkonton och kan till och med äventyra hela värdsystemet via administratörskonton med hjälp av sårbarheterna i autentiseringssystem. Autentiseringsfel gör det möjligt för angriparen att kompromissa med lösenord, sessionstoken, autentiseringsnycklar och kan kedjas med andra attacker som kan leda till obehörig åtkomst till något annat användarkonto eller session tillfälligt och i vissa fall permanent. Låt oss säga att en användare har en ordlista eller en ordlista med miljontals giltiga användarnamn och lösenord som erhållits under ett brott. Han kan använda dem en efter en på extremt kortare tid med hjälp av automatiserade verktyg och skript på inloggningssystemet för att se om någon fungerar. Dålig implementering av identitetshantering och åtkomstkontroller leder till sårbarheter som trasig autentisering.
Applikationen är sårbar för autentiseringsattack när den tillåter försök med olika användarnamn och lösenord, tillåter ordboksattacker eller brute force-attacker utan någon försvarsstrategi, använder enkla standardlösenord eller lösenord som läcks ut i något brott, exponerar session-id i URL, använder dåligt lösenordsåterställningsschema, använder ett mönster av kakor. Trasig autentisering kan enkelt utnyttjas med enkla verktyg för brute-forcing och ordbokattacker med en bra ordbok. Dessa typer av attacker kan förhindras med autentiseringssystem med flera faktorer, genom att genomföra svaga lösenordskontroller genom att köra ett lösenord genom en dålig lösenordsdatabas, genom att inte använda standardreferenser, genom att anpassa lösenordskomplexitetspolicyn, genom att använda god server-sida session manager som genererar ett nytt slumpmässigt session-id efter inloggning, etc.
Bruten autentiseringssårbarhet kan leda till att några användarkonton och ett administratörskonto äventyras, det är allt som en angripare behöver äventyra ett system. Dessa typer av attacker leder till identitetsstöld, social trygghet, penningtvätt och avslöjande av högt klassificerad information. Attacken omfattar ordlistaattacker, brute-forcing, sessionskapning och session management attacker.
Känslig dataxponering:
Ibland skyddar webbapplikationer inte känslig data och information som lösenord, databasinformation, etc. En angripare kan enkelt stjäla eller modifiera dessa svagt skyddade referenser och använda den för olagliga ändamål. Känsliga data ska krypteras i vila eller under transport och ha ett extra säkerhetsskikt, annars kan angripare stjäla dem. Angripare kan få tag på känslig exponerad data och stjäla hashade eller klara textanvändare och databasinformation från servern eller en webbläsare. Till exempel, om en lösenordsdatabas använder osaltad eller enkel hash för att lagra lösenord, kan en filöverföringsfel tillåta en angripare att hämta lösenordsdatabasen som leder till att alla lösenord exponeras med en regnbågstabell med förberäknade haschar.
Huvudfelet är inte bara att data inte är krypterade, även om de är krypterade, men svag nyckelgenerering, svag hashingalgoritmer, svag chiffrering kan också resultera i dessa typer av en av de vanligaste attackerna. För att förhindra dessa typer av attacker, klassificera först vilken typ av data som kan anses vara känsliga enligt sekretesslagarna och tillämpa kontroller enligt klassificeringen. Försök att inte lagra sekretessbelagda data som du inte behöver, tvätta den så snart du använder den. För data under transport, kryptera den med säkra protokoll i.e TLS med PFS-chiffer osv.
Dessa typer av sårbarheter kan resultera i exponering av mycket känslig information som kreditkortsuppgifter, hälsoposter, lösenord och andra personuppgifter som kan leda till identitetsstöld och bankbedrägeri, etc.
XML-externa enheter (XEE):
Dåligt konfigurerade XML-processorer bearbetar externa entitetsreferenser i XML-dokument. Dessa externa enheter kan användas för att hämta interna filers data som / etc / passwd fil eller för att utföra andra skadliga uppgifter. Sårbara XML-processorer kan enkelt utnyttjas om en angripare kan ladda upp ett XML-dokument eller inkludera XML etc. Dessa sårbara XML-enheter kan upptäckas med SAST- och DAST-verktyg eller manuellt genom att inspektera beroenden och konfigurationer.
En webbapplikation är sårbar för XEE-attacken på grund av många anledningar, till exempel om applikationen accepterar direkt XML-inmatning från opålitliga källor, Dokumenttypsdefinitioner (DTD: er) på applikationen är aktiverade, applikationen använder SAML för identitetsbehandling eftersom SAML använder XML för identitet infogningar osv. XEE-attacker kan mildras genom att man undviker serialisering av känslig data med mindre komplicerade dataformat i.JSON, patchning av XML-processorer applikationen används för tillfället och till och med biblioteken, inaktiverar DTD i alla XML-parsers, validering av XML-filöverföringsfunktionalitet med hjälp av XSD-verifiering, etc.
Applikationen som är sårbar för dessa typer av attacker kan leda till DOS-attack, Billion Laughs-attack, skanning av interna system, intern portskanning, körning av ett fjärrkommando som resulterar i att alla applikationsdata påverkas.
Trasig åtkomstkontroll:
Access Control ger användarna behörighet att göra specifika uppgifter. Bruten åtkomstkontroll sårbarhet sker när användarna inte är ordentligt begränsade till de uppgifter de kan utföra. Angripare kan utnyttja denna sårbarhet som kan hamna i att få åtkomst till obehörig funktionalitet eller information. Låt oss säga att en webbapp tillåter användaren att ändra det konto som han är inloggad från genom att bara ändra webbadressen till en annan användares konto utan ytterligare verifiering. Att utnyttja sårbarheten för åtkomstkontroll är en attack för alla angripare, denna sårbarhet kan hittas manuellt samt med hjälp av SAFT- och DAFT-verktyg. Dessa sårbarheter finns på grund av brist på testning och automatisk detektering av webbapplikationer, även om det bästa sättet att hitta dem är att göra det manuellt.
Sårbarheter innehåller eskalering av behörigheter i.om du agerar som en användare som du inte är eller agerar som administratör medan du är användare, kringgår åtkomstkontrollkontroller bara genom att ändra webbadressen eller ändra applikationens tillstånd, metadatahantering, så att den primära nyckeln kan ändras som en annan användares primära nyckel, etc. För att förhindra sådana typer av attacker måste åtkomstkontrollmekanismer implementeras i serverns sidkod där angripare inte kan ändra åtkomstkontrollerna. Tillämpning av unika applikationsaffärsgränser av domänmodeller, inaktivering av listningskataloger, varningsadministratör vid upprepade misslyckade inloggningsförsök, ogiltigförklaring av JWT-tokens efter utloggning måste säkerställas för att mildra denna typ av attack.
Angripare kan agera som en annan användare eller administratör med hjälp av denna sårbarhet för att utföra skadliga uppgifter som att skapa, radera och ändra poster, etc. Massiv dataförlust kan uppstå om uppgifterna inte är säkrade även efter ett intrång.
Felkonfiguration av säkerhet:
Den vanligaste sårbarheten är säkerhetskonfiguration. Den främsta anledningen till sårbarheten är användningen av standardkonfiguration, ofullständig konfiguration, Adhoc-konfigurationer, dåligt konfigurerade HTTP-rubriker och detaljerade felmeddelanden som innehåller mer information än vad användaren faktiskt borde ha känt. På alla nivåer i en webbapplikation kan säkerhetskonfigurationer uppstå i.e-databas, webbserver, applikationsserver, nättjänster etc. Angripare kan utnyttja opatchade system eller komma åt oskyddade filer och kataloger för att ha ett obehörigt grepp om systemet. Till exempel, ett program överdriva felmeddelanden som hjälper angriparen att känna till sårbarheter i applikationssystemet och hur det fungerar. Automatiserade verktyg och skannrar kan användas för att upptäcka dessa typer av säkerhetsfel.
En webbapplikation innehåller den här typen av sårbarhet om den saknar säkerhetshärdningsåtgärder över någon del av applikationen, onödiga portar är öppna eller det möjliggör onödiga funktioner, standardlösenord används, felhantering avslöjar över informativa fel till angriparen, den använder omatchad eller föråldrad säkerhetsprogramvara, etc. Det kan förhindras genom att ta bort onödiga funktioner i koden, dvs.en minimal plattform utan onödiga funktioner, dokumentation, etc, som gör det möjligt för en uppgift att uppdatera och korrigera säkerhetshålen som en del av patchhanteringsprocesser, användningen av en process för att verifiera effektiviteten av de säkerhetsåtgärder som vidtagits, användningen av repeterbar härdningsprocess för att göra det är enkelt att distribuera en annan miljö som är ordentligt låst.
Dessa typer av sårbarheter eller brister gör det möjligt för angriparen att få obehörig åtkomst till systemdata vilket leder till fullständig kompromiss av systemet.
Cross-Site Scripting (XSS):
XSS-sårbarheter inträffar vid den tidpunkt då en webbapplikation innehåller otillförlitliga data på en ny webbplats utan legitimt godkännande eller att fly, eller uppdaterar en aktuell webbplats med klientinformation, med hjälp av ett webbläsar-API som kan skapa HTML eller JavaScript. XSS-brister uppstår om webbplatsen tillåter en användare att lägga till anpassad kod i en URL-sökväg som kan ses av andra användare. Dessa brister används för att köra skadlig JavaScript-kod i målets webbläsare. Låt oss säga att en angripare kan skicka en länk till offret som innehåller en länk till vilket företags webbplats som helst. Den här anslutningen kan ha en del skadlig JavaScript-kod inbäddad. Om bankens webbsida inte är korrekt skyddad mot XSS-attacker, klickar du på länken den skadliga koden i offrets webbläsare.
Cross-Site Scripting är en säkerhetsproblem som finns i nästan ⅔ av webbapplikationerna. En applikation är sårbar för XSS om applikationen lagrar en oanitiserad användarinmatning som kan ses av en annan användare, med hjälp av JavaScript-strukturer, en-sida-applikationer och API: er som kraftfullt införlivar angriparstyrbar information till en sida är hjälplösa mot DOM XSS. XSS-attacker kan mildras genom att använda ramar som undgår och sanerar XSS-ingångar av naturen som React JS etc, genom att lära sig ramarnas begränsningar och täcka dem med egna fall, undvika onödiga och opålitliga HTML-data överallt jag.e i HTML-attribut, URI, Javascript, etc, användning av kontextkänslig kodning vid ändring av dokument på klientsidan, etc.
XSS-baserade attacker är av tre typer i.e Reflekterad XSS, DOM XSS och lagrad XSS. Alla typer av dessa attacker har en betydande inverkan men när det gäller Stored XSS är effekten ännu större i.stjäla referenser, skicka skadlig kod till offret osv.
Osäker deserialisering:
Serialisering av data innebär att ta objekt och konvertera dem till vilket format som helst så att dessa data kan användas för andra ändamål senare, medan deserialisering av data betyder motsatsen till det. Deserialisering är att packa upp denna serieinformation för användning av applikationer. Osäker deserialisering betyder härdning av data som har serierats precis innan som håller på att packas upp eller deserialiseras. Osäker deserialisering leder till fjärrkörning av koden och den används för att utföra andra uppgifter för skadliga ändamål som eskalering av privilegier, injektionsattacker, omspelningsattacker, etc. Det finns några verktyg tillgängliga för att upptäcka denna typ av brister men mänsklig hjälp behövs ofta för att validera problemet. Att utnyttja deserialisering är lite svårt eftersom exploateringen inte fungerar utan några manuella ändringar.
När applikationen deserialiserar skadliga objekt som tillhandahålls av den angripande enheten. Detta kan leda till två typer av attacker i.e-attacker relaterade till datastruktur och objekt där angriparen ändrar applikationslogik eller utför fjärrkod och typiska datafakturattacker där befintliga datastrukturer används med modifierat innehåll till exempel åtkomstkontrollrelaterade attacker. Serialisering kan användas i fjärrprocesskommunikation (RPC) eller en interprocesskommunikation (IPC), cachning av data, webbtjänster, databascacheserver, filsystem, API-autentiseringstoken, HTML-kakor, HTML-formulärsparametrar etc. Deserialiseringsattacker kan mildras genom att inte använda serieobjekt från opålitliga källor, implementera integritetskontroller, isolera koden som körs i en miljö med låg privilegium, övervaka inkommande och utgående nätverksanslutningar från servrar som deserialiseras ofta.
Använda komponenter med kända sårbarheter:
Olika komponenter som bibliotek, ramar och mjukvarumoduler används av de flesta utvecklare i webbapplikationen. Dessa bibliotek hjälper utvecklaren att undvika onödigt arbete och tillhandahålla den funktionalitet som behövs. Angripare letar efter brister och sårbarheter i dessa komponenter för att samordna en attack. I händelse av att hitta ett säkerhetshål i en komponent kan göra alla webbplatser som använder samma komponent, sårbara. Utnyttjande av dessa sårbarheter är redan tillgängligt när man skriver en anpassad exploatering från grunden kräver mycket ansträngning. Det här är en mycket vanlig och utbredd fråga, användningen av stora mängder komponenter för att utveckla en webbapplikation kan leda till att inte ens känna till och förstå alla komponenter som används, lappa och uppdatera alla komponenter är långt ifrån.
En applikation är sårbar om utvecklaren inte känner till vilken version av en komponent som används, programvaran är föråldrad i.e operativsystemet, DBMS, programvara som körs, runtime-miljöer och biblioteken, sårbarhetssökning görs inte regelbundet, kompatibiliteten för patchad programvara testas inte av utvecklarna. Det kan förhindras genom att ta bort oanvända beroenden, filer, dokumentation och bibliotek, kontrollera versionen av klient- och serversidesdelarna regelbundet, hämta komponenter och bibliotek från officiella och betrodda säkra källor, övervaka de omatchade biblioteken och komponenterna, säkerställa en plan för att uppdatera och korrigera sårbara komponenter regelbundet.
Dessa sårbarheter leder till mindre påverkan men kan också leda till kompromiss mellan servern och systemet. Många stora överträdelser förlitar sig på kända sårbarheter hos komponenter. Användningen av sårbara komponenter undergräver försvaret av applikationer och kan vara en utgångspunkt för en stor attack.
Otillräcklig loggning och övervakning:
De flesta system vidtar inte tillräckligt många åtgärder och åtgärder för att upptäcka dataintrång. Den genomsnittliga svarstiden för en incident är 200 dagar efter att den har hänt, det här är mycket tid att göra alla de otäcka sakerna för en attackerande enhet. Otillräcklig loggning och övervakning tillåter angriparen att ytterligare attackera systemet, behålla sitt grepp om systemet, manipulera, hålla och extrahera data enligt behov. Angripare använder bristen på övervakning och respons till sin fördel för att attackera webbapplikationen.
Otillräcklig loggning och övervakning sker när som helst i.e-loggar över applikationer som inte övervakas för ovanliga aktiviteter, granskbara händelser som misslyckade inloggningsförsök och höga transaktionsvärden loggas inte ordentligt, varningar och fel genererar oklara felmeddelanden, ingen utlösningsvarning vid pentesting med automatiska DAST-verktyg, utan att kunna upptäcka eller varna aktiva attacker snabbt, etc. Dessa kan mildras genom att säkerställa att alla inloggningar, åtkomstkontrollfel och validering av ingångsservrar på serversidan kan loggas för att identifiera skadligt användarkonto och hålls tillräckligt lång tid för försenad kriminalteknisk utredning, genom att säkerställa att loggarna som skapas är i ett format kompatibel med centraliserade logghanteringslösningar, genom att säkerställa integritetskontroller vid värdefulla transaktioner, genom att inrätta ett system för snabba varningar om misstänkta aktiviteter, etc.
De flesta framgångsrika attacker börjar med att söka efter och undersöka om det finns sårbarheter i ett system, så att dessa sårbarhetssonder kan leda till att hela systemet äventyras.
Slutsats:
Säkerhetsproblemen i en webbapplikation påverkar alla enheter som är relaterade till den applikationen. Dessa sårbarheter måste tas om hand för att ge en säker och säker miljö för användarna. Angripare kan använda dessa sårbarheter för att kompromissa med ett system, få tag på det och eskalera privilegier. Effekten av en komprometterad webbapplikation kan visualiseras från stulna kreditkortsuppgifter och identitetsstöld till läckage av mycket konfidentiell information etc. beroende på behov och attackvektorer för skadliga enheter.
