Sikkerhedstest (En komplet guide)

security testing

Sådan testes applikationssikkerhed - Teknikker til test af applikationssikkerhed på web og desktop

Behovet for sikkerhedstestning?

Softwareindustrien har opnået en solid anerkendelse i denne tidsalder. I det seneste årti ser cyberverdenen imidlertid ud til at være endnu mere dominerende og drivkraft, der udformer de nye former for næsten alle virksomheder. Web-baserede ERP-systemer, der anvendes i dag, er det bedste bevis for, at IT har revolutioneret vores elskede globale landsby.

I disse dage er websteder ikke kun beregnet til reklame eller markedsføring, men disse er blevet udviklet til de stærkere værktøjer til at imødekomme komplette forretningsbehov.

Web-baserede lønsystemer, indkøbscentre, bank, applikation til handel med varer bruges ikke kun af organisationer, men sælges også som produkter i dag.

Dette betyder, at online-applikationer har fået tillid hos kunder og brugere med hensyn til deres vitale funktion, der hedder SIKKERHED.

Ingen tvivl om, at sikkerhedsfaktoren også er af primær værdi for desktop-applikationer.

Men når vi taler om internettet, øges vigtigheden af ​​sikkerhed eksponentielt. Hvis et online system ikke kan beskytte transaktionsdataene, vil ingen nogensinde tænke på at bruge dem. Sikkerhed er hverken et ord på jagt efter dets definition endnu, og det er heller ikke et subtilt koncept. Jeg vil dog gerne nævne nogle komplimenter til sikkerheden.

hvad er en 7z-fil?

Eksempler på sikkerhedsfejl i en applikation

• Et studentledelsessystem er usikkert, hvis 'optagelsesgrenen' kan redigere dataene i 'eksamensgrenen'
• Et ERP-system er ikke sikkert, hvis DEO (dataindtjeningsoperatør) kan generere 'Rapporter'
• Et online indkøbscenter har ingen sikkerhed, hvis kundens kreditkortdetalje ikke er krypteret
• En brugerdefineret software har utilstrækkelig sikkerhed, hvis en SQL-forespørgsel henter faktiske adgangskoder for sine brugere

Sikkerhed

Nu præsenterer jeg for dig den enkleste definition af sikkerhed med mine egne ord.

'Sikkerhed betyder, at autoriseret adgang gives til beskyttede data, og uautoriseret adgang er begrænset' .

Så det har to hovedaspekter; det første er beskyttelsen af ​​data, og det andet er adgangen til disse data. Desuden, uanset om applikationen er desktop eller webbaseret, drejer sikkerhed sig om de to ovennævnte aspekter.

Lad os få et overblik over sikkerhedsaspekter for både desktop- og webbaseret softwareapplikationer.

Hvad du vil lære:

• Test af desktop- og websikkerhed
  • Anbefalede sikkerhedstestværktøjer
• Liste over top 8 sikkerhedstestteknikker
  • # 1) Adgang til applikation
  • # 2) Databeskyttelse
  • # 3) Brute-Force Attack
  • # 4) SQL Injection And XSS (Cross-Site Scripting)
  • # 5) Serviceadgangspunkter (forseglet og sikker åben)
  • # 6) Sessionsstyring
  • # 7) Fejlhåndtering
  • # 8) Specifikke risikofyldte funktioner
  • Anbefalet læsning

Test af desktop- og websikkerhed

En desktop-applikation skal være sikker ikke kun med hensyn til adgang, men også med hensyn til organisering og lagring af dens data.

Tilsvarende kræver webapplikation endnu mere sikkerhed med hensyn til dets adgang sammen med databeskyttelse. En webudvikler skal gøre applikationen immun over for SQL Injections, Brute Force Attacks og XSS (scripting på tværs af websteder). Tilsvarende, hvis webapplikationen letter fjernadgangspunkter, skal disse også være sikre.

Desuden skal du huske på, at Brute Force Attack ikke kun er relateret til webapplikationer, desktop-software er også sårbar over for dette.

Jeg håber, at dette forord er nok, og lad mig nu komme til det punkt. Accepter venligst min undskyldning, hvis du indtil videre troede, at du læser om emnet for denne artikel. Selvom jeg kort har forklaret softwaresikkerhed og dens største bekymringer, er mit emne 'Sikkerhedstestning'.

Anbefalet læsning => Test af webapplikationssikkerhed

Jeg vil nu forklare, hvordan sikkerhedsfunktionerne implementeres i softwareapplikationer, og hvordan skal disse testes. Mit fokus vil være på Whats and Hows af sikkerhedstest, ikke af sikkerhed.

Anbefalede sikkerhedstestværktøjer

# 1) Netparker

Netsparker er en sikkerhedsløsningsløsning til webapplikationer med funktioner til automatisk gennemsøgning og scanning til alle typer ældre og moderne webapplikationer såsom HTML5, Web 2.0 og applikationer med en enkelt side. Det gør brug af bevisbaseret scanningsteknologi og skalerbare scanningsagenter.

Det giver dig fuld synlighed, selvom du har et stort antal aktiver at administrere. Det har mange flere funktioner som teamledelse og sårbarhedsstyring. Det kan integreres i CI / CD-platforme som Jenkins, TeamCity eller Bamboo.

#to) Kiuwan

Find og rett sårbarheder i din kode på hvert trin i SDLC.

Kiuwan er i overensstemmelse med de strengeste sikkerhedsstandarder, herunder OWASP, CWE, SANS 25, HIPPA og mere. Integrer Kiuwan i din IDE for øjeblikkelig feedback under udvikling. Kiuwan understøtter alle større programmeringssprog og integreres med førende DevOps-værktøjer.

# 3) Indusface VAR Gratis Malware-kontrol på hjemmesiden

Indusface VAR leverer både manuel penetrationstest pakket med sin egen automatiserede sårbarhedsscanner til webapplikationer, der registrerer og rapporterer sårbarheder baseret på OWASP top 10 og inkluderer også en websteds omdømmekontrol af links, malware og afviklingskontrol af hjemmesiden i hver scanning

=> Kør en hurtig websidescanning gratis

Liste over top 8 sikkerhedstestteknikker

# 1) Adgang til applikation

Uanset om det er en desktop-applikation eller et websted, implementeres adgangssikkerhed af 'Roller og rettighedsstyring'. Det gøres ofte implicit under dækning af funktionalitet,

For eksempel, i et hospitalsledelsessystem er en receptionist mindst bekymret over laboratorietestene, da hans job er at bare registrere patienterne og planlægge deres aftaler med læger.

Så alle menuer, formularer og skærme relateret til laboratorietests vil ikke være tilgængelige for 'Receptionist'. Derfor vil den korrekte implementering af roller og rettigheder garantere sikkerheden for adgangen.

Sådan testes: For at teste dette skal der udføres grundig test af alle roller og rettigheder.

Testeren skal oprette flere brugerkonti med forskellige såvel som flere roller. Derefter skulle han bruge applikationen ved hjælp af disse konti og kontrollere, at hver rolle kun har adgang til sine egne moduler, skærme, formularer og menuer. Hvis testeren finder nogen konflikt, skal han logge et sikkerhedsproblem med fuld tillid.

Dette kan også forstås som godkendelses- og autorisationstest, der er meget smukt afbildet i nedenstående billede:

Så grundlæggende skal du teste om 'hvem du er' og 'hvad du kan gøre' for forskellige brugere.

Nogle af godkendelsestestene inkluderer en test for adgangskodekvalitetsregler, test for standardlogins, test for gendannelse af adgangskode, test captcha, test for logout-funktionalitet, test for ændring af adgangskode, test for sikkerhedsspørgsmål / svar osv.

Tilsvarende inkluderer nogle af godkendelsestestene en test for stiovergang, test for manglende godkendelse, test for vandrette adgangskontrolproblemer osv.

# 2) Databeskyttelse

Der er tre aspekter af datasikkerhed. Den første er det en bruger kan kun se eller bruge de data, som han skal bruge . Dette sikres også af roller og rettigheder

For eksempel, TSR (repræsentant for telesalg) for et firma kan se data om tilgængelig lager, men kan ikke se, hvor meget råmateriale der blev købt til produktion.

Så dette aspekt af sikkerhedstest er allerede forklaret ovenfor. Det andet aspekt af databeskyttelse er relateret til hvordan disse data lagres i DB .

Yderligere læsning = >> Hvad er databasesikkerhedstest

hvor er netværkssikkerhedsnøglen på min router

Alle følsomme data skal krypteres for at gøre dem sikre. Kryptering skal være stærk, især for følsomme data som adgangskoder til brugerkonti, kreditkortnumre eller anden forretningskritisk information.

Tredje og sidste aspekt er en udvidelse af dette andet aspekt. Korrekte sikkerhedsforanstaltninger skal vedtages, når strømmen af ​​følsomme eller forretningskritiske data opstår. Uanset om disse data flyder mellem forskellige moduler i den samme applikation eller transmitteres til forskellige applikationer, skal de krypteres for at holde dem sikre.

Sådan tester du databeskyttelse: Testeren skal forespørge i databasen for 'adgangskoder' til brugerkontoen, faktureringsoplysninger for klienter, andre forretningskritiske og følsomme data og bør kontrollere, at alle sådanne data er gemt i krypteret form i DB.

Tilsvarende skal han kontrollere, at data transmitteres mellem forskellige former eller skærme efter korrekt kryptering. Desuden skal testeren sikre, at de krypterede data dekrypteres korrekt på destinationen. Der skal lægges særlig vægt på forskellige 'indsend' -aktioner.

Testeren skal kontrollere, at når oplysningerne transmitteres mellem klienten og serveren, vises de ikke i adresselinjen i en webbrowser i et forståeligt format. Hvis nogen af ​​disse verifikationer mislykkes, har applikationen bestemt en sikkerhedsfejl.

Testeren skal også kontrollere, om saltning anvendes korrekt (tilføje en ekstra hemmelig værdi til slutindgangen som adgangskode og dermed gøre den stærkere og sværere at blive revnet).

Usikker tilfældighed skal også testes, da det er en slags sårbarhed. En anden måde at teste databeskyttelse på er at kontrollere for svag algoritmeforbrug.

For eksempel, Da HTTP er en klar tekstprotokol, hvis de følsomme data som brugeroplysninger overføres via HTTP, er det en trussel mod applikationssikkerhed. I stedet for HTTP skal følsomme data overføres via HTTPS (sikret via SSL, TLS-tunnel).

HTTPS øger dog angrebsoverfladen, og det bør derfor testes, at serverkonfigurationer er korrekte, og certifikatgyldigheden er sikret.

# 3) Brute-Force Attack

Brute Force Attack udføres for det meste af nogle softwareværktøjer. Konceptet er, at ved hjælp af et gyldigt bruger-id, s Oftware forsøger at gætte den tilknyttede adgangskode ved at prøve at logge ind igen og igen.

Et simpelt eksempel på sikkerhed mod et sådant angreb er kontosuspension i en kort periode, som alle mailapplikationer som 'Yahoo', 'Gmail' og 'Hotmail' gør. Hvis et bestemt antal på hinanden følgende forsøg (for det meste 3) ikke logger ind med succes, er den konto blokeret i nogen tid (30 minutter til 24 timer).

Sådan tester du Brute-Force Attack: Testeren skal kontrollere, at en eller anden mekanisme til kontosuspension er tilgængelig og fungerer korrekt. (S) Han skal forsøge at logge ind med ugyldige bruger-id'er og adgangskoder alternativt for at sikre sig, at softwareapplikationer blokerer kontiene, hvis der løbende forsøges at logge ind med ugyldige legitimationsoplysninger.

Hvis applikationen gør det, er det sikkert mod brute-force angreb. Ellers skal denne sikkerhedssårbarhed rapporteres af testeren.

Test for brute force kan også opdeles i to dele - test af sort boks og test af grå boks.

Ved test af sort boks opdages og testes den godkendelsesmetode, der anvendes af applikationen. Desuden er test af grå bokse baseret på delvis kendskab til adgangskode- og kontooplysninger og hukommelseskombinationangreb.

Klik på her for at udforske sort boks & grå kasse test for brute force sammen med eksempler.

Ovenstående tre sikkerhedsaspekter skal tages i betragtning for både web- og desktopapplikationer, mens de følgende punkter kun er relateret til webbaserede applikationer.

# 4) SQL Injection And XSS (Cross-Site Scripting)

Konceptuelt set er temaet for begge disse hackingforsøg ens, så disse diskuteres sammen. I denne tilgang er den ondsindet script bruges af hackere til at manipulere et websted .

Der er flere måder at immunisere mod sådanne forsøg på. For alle inputfelter på webstedet skal feltlængder defineres små nok til at begrænse input af ethvert script

qa føre interviewspørgsmål og svar pdf

For eksempel, Efternavnet skal have feltlængde 30 i stedet for 255. Der kan være nogle inputfelter, hvor store dataindtastninger er nødvendige, for sådanne felter skal korrekt validering af input udføres, før dataene gemmes i applikationen.

Desuden skal HTML-tags eller input af script-tag i sådanne felter være forbudt. For at provokere XSS-angreb skal applikationen kassere script-omdirigeringer fra ukendte eller ikke-tillid til applikationer.

Hvordan test SQL Injection og XSS: Testeren skal sikre, at de maksimale længder for alle inputfelter defineres og implementeres. (S) Han skal også sikre, at den definerede længde af inputfelter ikke rummer noget script input såvel som tag input. Begge disse kan let testes

For eksempel, Hvis 20 er den maksimale længde, der er angivet for feltet 'Navn', og inputstrengen '

thequickbrownfoxjumpsoverthelazydog ”kan kontrollere begge disse begrænsninger.

Det skal også verificeres af testeren, at applikationen ikke understøtter anonyme adgangsmetoder. Hvis nogen af ​​disse sårbarheder findes, er applikationen i fare.

Grundlæggende kan SQL-injektionstest udføres på følgende fem måder:

• Detektionsteknikker
• Standard SQL-injektionsteknikker
• Fingeraftryk databasen
• Teknisk udnyttelse
• SQL Injection Signature Invasion Techniques

Klik på her at læse i detaljer om ovenstående måder at teste SQL-injektion på.

XSS er også en type injektion, der injicerer ondsindet script på et websted. Klik på her for at udforske dybtgående om testning af XSS.

# 5) Serviceadgangspunkter (forseglet og sikker åben)

I dag er virksomheder afhængige af og samarbejder med hinanden, det samme gælder applikationer, især websteder. I et sådant tilfælde skal begge samarbejdspartnere definere og offentliggøre nogle adgangspunkter for hinanden.

Indtil videre virker scenariet ret simpelt og ligetil, men for nogle webbaserede produkter som aktiehandel er tingene ikke så enkle og lette.

Når der er et stort antal målgrupper, skal adgangspunkterne være åbne nok til at lette alle brugere, imødekommende nok til at imødekomme alle brugeres anmodninger og sikre nok til at klare ethvert sikkerhedsforsøg.

Sådan tester du serviceadgangspunkter: Lad mig forklare det med eksempel af aktiehandelens webapplikation en investor (som ønsker at købe aktierne) skal have adgang til aktuelle og historiske data om aktiekurser. Brugeren skal have mulighed for at downloade disse historiske data. Dette kræver, at ansøgningen skal være åben nok.

Ved at imødekomme og sikre mener jeg, at applikationen skal gøre det lettere for investorer at handle frit (under lovgivningen). De kan købe eller sælge 24/7, og dataene for transaktionerne skal være immune over for ethvert hackingangreb.

Desuden vil et stort antal brugere interagere med applikationen samtidigt, så applikationen skal give adgangspunkter nok til at underholde alle brugerne.

I nogle tilfælde er disse adgangspunkter kan forsegles til uønskede applikationer eller personer . Dette afhænger af applikationens forretningsdomæne og dets brugere,

For eksempel, Et brugerdefineret webbaseret Office Management System kan genkende sine brugere på basis af IP-adresser og nægter at etablere en forbindelse med alle andre systemer (applikationer), der ikke falder inden for gyldige IP-adresser for den applikation.

Testeren skal sikre, at alle inter-netværk og intra-netværksadgang til applikationen er af pålidelige applikationer, maskiner (IP'er) og brugere.

For at kontrollere, at et åbent adgangspunkt er sikkert nok, skal testeren forsøge at få adgang til det fra forskellige maskiner, der har både betroede og ikke-tillid til IP-adresser. Forskellige slags realtidstransaktioner skal forsøges samlet for at have god tillid til applikationens ydeevne. Ved at gøre dette vil kapaciteten af ​​adgangspunkter for applikationen også blive observeret tydeligt.

Testeren skal sikre, at applikationen kun underholder alle kommunikationsanmodninger fra pålidelige IP'er og applikationer, mens alle andre anmodninger afvises.

På samme måde, hvis applikationen har et åbent adgangspunkt, skal testeren sikre, at det tillader (om nødvendigt) at uploade data af brugere på en sikker måde. På denne sikre måde mener jeg om filstørrelsesbegrænsning, filtypebegrænsning og scanning af den uploadede fil for vira eller andre sikkerhedstrusler.

Dette er alt, hvordan en tester kan verificere en applikations sikkerhed med hensyn til dens adgangspunkter.

# 6) Sessionsstyring

En websession er en sekvens af HTTP-anmodning og svarstransaktioner, der er knyttet til den samme bruger. Sessionsledelsestestene kontrollerer, hvordan sessionsadministration håndteres i webappen.

Du kan teste for sessionens udløb efter en bestemt inaktiv tid, sessionens afslutning efter den maksimale levetid, sessionens afslutning efter aflogning, kontrollere om sessionens cookieomfang og varighed, test om en enkelt bruger kan have flere samtidige sessioner osv.

# 7) Fejlhåndtering

Test for fejlhåndtering inkluderer:

Kontroller for fejlkoder : For eksempel, test 408 timeout for anmodning, 400 dårlige anmodninger, 404 ikke fundet osv. For at teste disse skal du stille visse anmodninger til siden, så disse fejlkoder returneres.

Fejlkoderne returneres med en detaljeret besked. Disse meddelelser bør ikke indeholde vigtige oplysninger, der kan bruges til hackingsformål

Kontroller for stakspor : Det grundlæggende inkluderer at give nogle ekstraordinære input til applikationen, så den returnerede fejlmeddelelse indeholder stakspor, der har interessant information til hackere.

# 8) Specifikke risikofyldte funktioner

Hovedsageligt er de to risikable funktioner betalinger og fil uploads . Disse funktioner skal testes meget godt. For filuploads skal du primært teste, at uønsket eller ondsindet filupload er begrænset.

For betalinger skal du primært teste for sårbarheder ved injektion, usikker kryptografisk opbevaring, bufferoverløb, gætning af adgangskode osv.

Yderligere læsning:

• Sikkerhedstest af webapplikationer
• Top 30 spørgsmål om sikkerhedstestinterview
• Forskel mellem SAST / DAST / IAST / RASP
• SANS Top 20 sikkerhedssårbarheder

Anbefalet læsning

• Vejledning til test af webapplikationssikkerhed
• Alpha Testing og Beta Testing (En komplet guide)
• ETL Testing Data Warehouse Testing Tutorial (En komplet guide)
• Netværkssikkerhedstest og de bedste netværkssikkerhedsværktøjer
• Begyndervejledning til penetrationstest af webapplikationer
• Build Verification Testing (BVT Testing) Komplet guide
• Funktionel testning mod ikke-funktionel testning
• En komplet penetrationstestguide med eksempler på testtilfælde