security testing
Hur man testar applikationssäkerhet - Testtekniker för webb- och skrivbordsapplikationer
Behovet av säkerhetstestning?
Mjukvaruindustrin har uppnått ett gedigen erkännande i denna tid. Under det senaste decenniet verkar dock cybervärlden vara ännu mer dominerande och drivande kraft som utformar de nya formerna för nästan alla företag. Webbaserade affärssystem som används idag är det bästa beviset på att IT har revolutionerat vår älskade globala by.
Dessa dagar är webbplatser inte endast avsedda för reklam eller marknadsföring utan dessa har utvecklats till de starkare verktygen för att tillgodose kompletta affärsbehov.
Webbaserade lönesystem, köpcentra, bank, applikation för handel med aktier används inte bara av organisationer utan säljs också som produkter idag.
Detta innebär att onlineapplikationer har fått förtroende hos kunder och användare beträffande deras viktiga funktion som heter SECURITY.
Utan tvekan är säkerhetsfaktorn också av primärt värde för stationära applikationer.
Men när vi pratar om webben ökar vikten av säkerhet exponentiellt. Om ett online-system inte kan skydda transaktionsdata kommer ingen någonsin att tänka på att använda den. Säkerhet är varken ett ord på jakt efter dess definition ännu, och det är inte heller ett subtilt koncept. Jag vill dock lista några komplimanger för säkerheten.
hur man öppnar XML-filen i Word
Exempel på säkerhetsfel i en applikation
- Ett studenthanteringssystem är osäkert om 'antagningsgrenen' kan redigera data från 'Exam' -grenen
- Ett ERP-system är inte säkert om DEO (datainmatningsoperatör) kan generera 'Rapporter'
- Ett köpcentrum online har ingen säkerhet om kundens kreditkortsdetalj inte är krypterad
- En anpassad programvara har otillräcklig säkerhet om en SQL-fråga hämtar sina användares faktiska lösenord
säkerhet
Nu presenterar jag den enklaste definitionen av säkerhet i mina egna ord.
'Säkerhet innebär att auktoriserad åtkomst beviljas skyddad data och obehörig åtkomst är begränsad' .
Så det har två huvudaspekter; det första är skyddet av data och det andra är åtkomst till dessa uppgifter. Dessutom, oavsett om applikationen är stationär eller webbaserad, kretsar säkerheten kring de två ovannämnda aspekterna.
Låt oss ha en översikt över säkerhetsaspekter för både stationära och webbaserade program.
Vad du kommer att lära dig:
Testning av skrivbords- och webbsäkerhet
En stationär applikation bör vara säker inte bara när det gäller åtkomst utan även med avseende på organisation och lagring av dess data.
På samma sätt kräver webbapplikation, ännu mer, säkerhet med avseende på åtkomst tillsammans med dataskydd. En webbutvecklare bör göra applikationen immun mot SQL-injektioner, Brute Force Attacks och XSS (cross-site scripting). Om webbapplikationen underlättar fjärråtkomstpunkter måste dessa också vara säkra.
Dessutom, kom ihåg att Brute Force Attack inte bara är relaterat till webbapplikationer, skrivbordsprogramvara är också sårbar för detta.
Jag hoppas att detta förord är tillräckligt och låt mig nu komma till saken. Vänligen acceptera min ursäkt om du hittills trodde att du läser om ämnet för den här artikeln. Även om jag kort har förklarat programvarusäkerhet och dess viktigaste problem, är mitt ämne ”Säkerhetstestning”.
Rekommenderad läsning => Säkerhetstestning av webbapplikationer
Jag kommer nu att förklara hur säkerhetsfunktionerna implementeras i programvaran och hur ska dessa testas. Mitt fokus kommer att vara på vad och hur säkerhetstester, inte säkerhet.
Rekommenderade säkerhetstestverktyg
# 1) Net parker
Netsparker är en testlösning för webbapplikationssäkerhet med funktioner för automatisk genomsökning och genomsökning för alla typer av äldre och moderna webbapplikationer som HTML5, Web 2.0 och enstaka sidapplikationer. Den använder sig av Proof-Based Scanning Technology och skalbara skanningsagenter.
Det ger dig fullständig synlighet även om du har ett stort antal tillgångar att hantera. Det har många fler funktioner som teamhantering och sårbarhetshantering. Den kan integreras i CI / CD-plattformarna som Jenkins, TeamCity eller Bamboo.
=> Prova det bästa Netsparker-säkerhetstestverktyget#två) Kiuwan
Hitta och åtgärda sårbarheter i din kod i alla steg i SDLC.
Kiuwan uppfyller de strängaste säkerhetsstandarderna inklusive OWASP, CWE, SANS 25, HIPPA och mer. Integrera Kiuwan i din IDE för omedelbar feedback under utvecklingen. Kiuwan stöder alla större programmeringsspråk och integreras med ledande DevOps-verktyg.
=> Skanna din kod gratis# 3) Indusface VAR Gratis Malware Check
Indusface VAR tillhandahåller både manuell penetrationstest med sin egen automatiska sårbarhetsskanner för webbapplikation som upptäcker och rapporterar sårbarheter baserat på OWASP topp 10 och inkluderar också en webbplatsens ryktekontroll av länkar, skadlig programvara och utplåningskontroller av webbplatsen i varje skanning
=> Kör en snabb webbplatsgenomsökning gratis
=> Kontakta oss för att föreslå en lista här.
Lista över de 8 bästa teknikerna för säkerhetstestning
# 1) Tillgång till applikation
Oavsett om det är en stationär applikation eller en webbplats implementeras åtkomstsäkerhet av ”Roller och rättighetshantering”. Det görs ofta implicit under täckning av funktionalitet,
Till exempel, i ett sjukhushanteringssystem är en receptionist minst bekymrad över laboratorietesterna eftersom hans jobb är att bara registrera patienterna och planera sina möten med läkare.
Så alla menyer, formulär och skärmar relaterade till laboratorietester kommer inte att vara tillgängliga för 'Receptionist'. Det korrekta genomförandet av roller och rättigheter garanterar därför åtkomstsäkerheten.
Hur man testar: För att testa detta bör noggranna tester av alla roller och rättigheter utföras.
Testaren ska skapa flera användarkonton med olika såväl som flera roller. Då skulle han använda applikationen med hjälp av dessa konton och bör verifiera att varje roll endast har tillgång till sina egna moduler, skärmar, formulär och menyer. Om testaren hittar någon konflikt bör han logga ett säkerhetsproblem med fullständigt förtroende.
Detta kan också förstås som autentiserings- och auktoriseringstest, som mycket vackert avbildas i bilden nedan:
Så i princip måste du testa om 'vem du är' och 'vad du kan göra' för distinkta användare.
Några av autentiseringstesterna inkluderar ett test för lösenordskvalitetsregler, test för standardinloggningar, test för lösenordsåterställning, test captcha, test för utloggningsfunktionalitet, test för lösenordsändring, test för säkerhetsfråga / svar etc.
På liknande sätt inkluderar några av auktorisationstesterna ett test för sökväg, test för saknad auktorisering, test för horisontella åtkomstkontrollproblem etc.
# 2) Dataskydd
Det finns tre aspekter av datasäkerhet. Den första är det en användare kan bara se eller använda de data som han ska använda . Detta säkerställs också av roller och rättigheter
Till exempel, TSR (företagsrepresentant) för ett företag kan se uppgifter om tillgängligt lager, men kan inte se hur mycket råvara som köptes för produktion.
Så denna aspekt av säkerhetstestning har redan förklarats ovan. Den andra aspekten av dataskydd är relaterad till hur dessa data lagras i DB .
Ytterligare läsning = >> Vad är databas säkerhetstestning
Alla känsliga data måste krypteras för att göra dem säkra. Kryptering bör vara stark, särskilt för känslig data som lösenord för användarkonton, kreditkortsnummer eller annan affärskritisk information.
Den tredje och den sista aspekten är en förlängning av denna andra aspekt. Korrekta säkerhetsåtgärder måste vidtas när flödet av känslig eller affärskritisk data inträffar. Oavsett om den här informationen flyter mellan olika moduler i samma applikation eller överförs till olika applikationer, måste den krypteras för att hålla den säker.
Hur man testar dataskydd: Testaren bör fråga databasen för 'lösenord' för användarkontot, faktureringsinformation för klienter, andra affärskritiska och känsliga data och bör verifiera att all sådan information sparas i krypterad form i DB.
På samma sätt måste han verifiera att data överförs mellan olika former eller skärmar endast efter korrekt kryptering. Dessutom bör testaren säkerställa att de krypterade uppgifterna dekrypteras ordentligt på destinationen. Särskild uppmärksamhet bör ägnas olika 'skicka' åtgärder.
Testaren måste verifiera att när informationen överförs mellan klienten och servern visas den inte i adressfältet i en webbläsare i ett förståeligt format. Om någon av dessa verifieringar misslyckas har applikationen definitivt ett säkerhetsfel.
Testaren bör också kontrollera att saltningen används korrekt (lägga till ett extra hemligt värde till slutinmatningen som lösenord och därmed göra det starkare och svårare att knäcka).
Osäker slumpmässighet bör också testas eftersom det är en slags sårbarhet. Ett annat sätt att testa dataskydd är att söka efter svag algoritmanvändning.
hur man öppnar eps-filer i Windows 10
Till exempel, Eftersom HTTP är ett klartextprotokoll, om känsliga data som användaruppgifter överförs via HTTP, är det ett hot mot applikationssäkerheten. Istället för HTTP bör känslig data överföras via HTTPS (skyddad genom SSL, TLS-tunnel).
HTTPS ökar dock attackytan och därför bör det testas att serverkonfigurationerna är korrekta och certifikatets giltighet garanteras.
# 3) Brute-Force Attack
Brute Force Attack utförs mestadels av vissa programverktyg. Konceptet är att genom att använda ett giltigt användar-ID, s Oftware försöker gissa det associerade lösenordet genom att försöka logga in igen och igen.
Ett enkelt exempel på säkerhet mot en sådan attack är kontoavstängning under en kort tidsperiod som alla e-postapplikationer som 'Yahoo', 'Gmail' och 'Hotmail' gör. Om ett visst antal på varandra följande försök (mestadels 3) inte loggar in framgångsrikt, blockeras kontot under en tid (30 minuter till 24 timmar).
Hur man testar Brute-Force Attack: Testaren måste verifiera att någon mekanism för kontosuspension är tillgänglig och fungerar korrekt. (S) Han måste försöka logga in med ogiltiga användar-ID och lösenord alternativt för att se till att programvara blockerar kontona om kontinuerliga försök görs för att logga in med ogiltiga referenser.
Om ansökan gör det är det säkert mot brute-force attack. Annars måste denna säkerhetsproblem rapporteras av testaren.
Testning av brute force kan också delas in i två delar - testning av svart låda och test av grå låda.
I Black Box-test upptäcks och testas den autentiseringsmetod som används av applikationen. Dessutom är testningen av grå rutor baserad på delvis kunskap om lösenord & kontouppgifter och minnesavvägningsattacker.
Klick här för att utforska svart låda & grå låda brute force testning tillsammans med exempel.
Ovanstående tre säkerhetsaspekter bör beaktas för både webb- och skrivbordsapplikationer medan följande punkter endast är relaterade till webbaserade applikationer.
# 4) SQL Injection And XSS (Cross-Site Scripting)
Konceptuellt sett är temat för båda dessa hackningsförsök likartat, så dessa diskuteras tillsammans. I detta tillvägagångssätt, skadligt skript används av hackare för att manipulera en webbplats .
Det finns flera sätt att immun mot sådana försök. För alla inmatningsfält på webbplatsen bör fältlängder definieras tillräckligt små för att begränsa inmatningen av alla skript
hur man hittar nätverkssäkerhetsnyckel för wifi
Till exempel, Efternamnet bör ha fältlängd 30 istället för 255. Det kan finnas vissa inmatningsfält där stora datainmatningar är nödvändiga, för sådana fält bör korrekt validering av inmatningen utföras innan data sparas i applikationen.
Dessutom måste alla HTML-taggar eller inmatning av skripttaggar i sådana fält vara förbjudna. För att provocera XSS-attacker bör applikationen kasta skriptomdirigeringar från okända eller opålitliga applikationer.
Hur test SQL Injection och XSS: Testaren måste se till att maximala längder för alla inmatningsfält definieras och implementeras. (S) Han bör också se till att den definierade längden på inmatningsfält inte rymmer någon skriptingång liksom tagginmatning. Båda dessa kan enkelt testas
Till exempel, Om 20 är den maximala längden som anges för fältet 'Namn' och inmatningssträngen '
thequickbrownfoxjumpsoverthelazydog ”kan verifiera båda dessa begränsningar.
Det bör också verifieras av testaren att applikationen inte stöder anonyma åtkomstmetoder. Om någon av dessa sårbarheter existerar är applikationen i fara.
I grund och botten kan SQL-injektionstest göras på följande fem sätt:
- Detekteringstekniker
- Standard SQL-injektionstekniker
- Fingeravtryck databasen
- Tekniskt utnyttjande
- SQL Injection Signature Invasion Techniques
Klick här att läsa i detalj om ovanstående sätt att testa SQL-injektion.
XSS är också en typ av injektion som injicerar skadligt skript på en webbplats. Klick här för att utforska djupare om testning för XSS.
# 5) Serviceåtkomstpunkter (förseglade och säkra öppna)
Idag är företag beroende och samarbetar med varandra, detsamma gäller för applikationer, särskilt webbplatser. I ett sådant fall bör båda medarbetarna definiera och publicera några åtkomstpunkter för varandra.
Hittills verkar scenariot ganska enkelt och enkelt, men för vissa webbaserade produkter som aktiehandel är det inte så enkelt och enkelt.
När det finns ett stort antal målgrupper bör åtkomstpunkterna vara tillräckligt öppna för att underlätta för alla användare, tillmötesgående tillräckligt för att uppfylla alla användares förfrågningar och säkra nog för att klara alla säkerhetsprov.
Hur man testar servicepunkter: Låt mig förklara det med exempel av webbapplikationen för aktiehandel; en investerare (som vill köpa aktierna) ska ha tillgång till aktuella och historiska data om aktiekurser. Användaren bör ges möjlighet att ladda ner denna historiska data. Detta kräver att ansökan ska vara tillräckligt öppen.
Med tillmötesgående och säker menar jag att applikationen bör underlätta investerare att handla fritt (enligt lagstiftningen). De kan köpa eller sälja 24/7 och uppgifterna om transaktionerna måste vara immuna mot alla hackingattacker.
Dessutom kommer ett stort antal användare att interagera med applikationen samtidigt, så applikationen bör ge tillräckligt många åtkomstpunkter för att underhålla alla användare.
I vissa fall är dessa åtkomstpunkter kan förseglas för oönskade applikationer eller människor . Detta beror på applikationens affärsdomän och dess användare,
Till exempel, Ett anpassat webbaserat Office Management System kan känna igen sina användare på grundval av IP-adresser och nekar att upprätta en anslutning med alla andra system (applikationer) som inte faller inom giltiga IP-adresser för den applikationen.
Testaren måste se till att alla inter-nätverk och intrinnät-åtkomst till applikationen är av betrodda applikationer, maskiner (IP) och användare.
För att verifiera att en öppen åtkomstpunkt är tillräckligt säker måste testaren försöka komma åt den från olika maskiner som har både betrodda och opålitliga IP-adresser. Olika typer av realtidstransaktioner bör prövas i bulk för att ha gott förtroende för applikationens prestanda. Genom att göra detta kommer också kapaciteten för åtkomstpunkter för applikationen att observeras tydligt.
Testaren måste säkerställa att applikationen endast underhåller alla kommunikationsförfrågningar från betrodda IP-adresser och applikationer medan alla andra förfrågningar avvisas.
På samma sätt, om applikationen har en öppen åtkomstpunkt, bör testaren se till att den tillåter (om det behövs) överföra data av användare på ett säkert sätt. På det här säkra sättet menar jag om filstorleksbegränsning, filtypbegränsning och skanning av den uppladdade filen för virus eller andra säkerhetshot.
Det här är hur en testare kan verifiera säkerheten för en applikation med avseende på dess åtkomstpunkter.
# 6) Sessionshantering
En webbsession är en sekvens av HTTP-begäran och svarstransaktioner länkade med samma användare. Sessionshanteringstesterna kontrollerar hur sessionshantering hanteras i webbappen.
Du kan testa för sessionens utgång efter en viss inaktiv tid, sessionsterminering efter maximal livslängd, sessionsterminering efter utloggning, kontrollera om sessionens cookie-omfattning och varaktighet, testa om en enskild användare kan ha flera samtidiga sessioner, etc.
# 7) Felhantering
Testning för felhantering inkluderar:
Sök efter felkoder : Till exempel, test 408 timeout för begäran, 400 dåliga förfrågningar, 404 hittades inte etc. För att testa dessa måste du göra vissa förfrågningar på sidan så att dessa felkoder returneras.
Felkoderna returneras med ett detaljerat meddelande. Dessa meddelanden bör inte innehålla kritisk information som kan användas för hackningssyfte
Kontrollera om det finns stackspår : Det inkluderar i princip att ge några exceptionella inmatningar till applikationen så att det returnerade felmeddelandet innehåller stackspår som har intressant information för hackare.
# 8) Specifika riskfunktioner
Huvudsakligen är de två riskabla funktionerna betalningar och filöverföringar . Dessa funktioner bör testas mycket bra. För filöverföringar måste du först testa att oönskad eller skadlig filuppladdning är begränsad.
För betalningar måste du främst testa för sårbarheter vid injektion, osäker kryptografisk lagring, buffertöverflöden, gissning av lösenord etc.
=> Kontakta oss för att föreslå en lista här.Vidare läsning:
- Säkerhetstestning av webbapplikationer
- Topp 30 intervjufrågor om säkerhetstestning
- Skillnad mellan SAST / DAST / IAST / RASP
- SANS Topp 20 säkerhetsproblem
Rekommenderad läsning
- Guide för testning av webbapplikationssäkerhet
- Alpha Testing och Beta Testing (En komplett guide)
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
- Testning av nätverkssäkerhet och bästa verktyg för nätverkssäkerhet
- Nybörjarhandbok för penetreringstestning för webbapplikationer
- Byggverifieringstestning (BVT-testning) Komplett guide
- Funktionell testning mot icke-funktionell testning
- En fullständig testguide för penetration med exempel på testfall