security testing
Kako testirati sigurnost aplikacija - tehnike testiranja sigurnosti weba i radne površine
Potreba za sigurnosnim ispitivanjem?
Softverska industrija postigla je solidno priznanje u ovo doba. Međutim, čini se da je u posljednjem desetljeću cyber svijet još više dominirajući i pokretačka snaga koja oblikuje nove oblike gotovo svakog poslovanja. Web-bazirani ERP sustavi koji se danas koriste najbolji su dokaz da je IT revolucionirao naše voljeno globalno selo.
Danas web stranice nisu namijenjene samo promidžbi ili marketingu, već su one razvijene u snažnije alate za zadovoljavanje poslovnih potreba.
Internetski sustavi za obračun plaća, trgovački centri, bankarstvo, aplikacija za trgovinu dionicama ne koriste se samo od organizacija, već se danas prodaju i kao proizvodi.
To znači da su internetske aplikacije stekle povjerenje kupaca i korisnika u pogledu njihove vitalne značajke nazvane SIGURNOST.
Bez sumnje, sigurnosni faktor je primarna vrijednost i za stolne programe.
Međutim, kada govorimo o webu, važnost sigurnosti eksponencijalno raste. Ako mrežni sustav ne može zaštititi podatke o transakciji, nitko nikada neće pomisliti koristiti ih. Sigurnost još nije niti riječ u potrazi za svojom definicijom, niti je suptilan pojam. Međutim, želio bih navesti neke komplimente o sigurnosti.
mirna internetska usluga intervjuirati pitanja i odgovore za iskusne
Primjeri sigurnosnih nedostataka u aplikaciji
- Sustav upravljanja studentima nije siguran ako grana ‘Prijem’ može uređivati podatke grane ‘Ispit’
- ERP sustav nije siguran ako DEO (operator unosa podataka) može generirati 'Izvješća'
- Mrežni trgovački centar nema sigurnost ako podaci o kreditnoj kartici kupca nisu šifrirani
- Prilagođeni softver posjeduje neadekvatnu sigurnost ako SQL upit dohvaća stvarne lozinke svojih korisnika
Sigurnost
Sada vam predstavljam najjednostavniju definiciju sigurnosti svojim riječima.
'Sigurnost znači da se zaštićenim podacima daje odobreni pristup, a neovlašteni pristup ograničava' .
Dakle, ima dva glavna aspekta; prvo je zaštita podataka, a drugo pristup tim podacima. Štoviše, bez obzira je li aplikacija stolna ili web, sigurnost se vrti oko dva gore spomenuta aspekta.
Dopustite nam pregled sigurnosnih aspekata softverskih aplikacija za stolna računala i za web.
Što ćete naučiti:
Testiranje radne površine i web sigurnosti
Stolna aplikacija trebala bi biti sigurna ne samo u pogledu pristupa, već i u pogledu organizacije i pohrane svojih podataka.
Slično tome, web aplikacija zahtijeva, čak i više, sigurnost s obzirom na svoj pristup, zajedno sa zaštitom podataka. Web programer trebao bi učiniti aplikaciju imunom na SQL injekcije, Brute Force Attacks i XSS (skriptiranje na više web lokacija). Slično tome, ako web aplikacija omogućuje udaljene pristupne točke, i one moraju biti sigurne.
Štoviše, imajte na umu da se Brute Force Attack ne odnosi samo na web programe, već je i desktop softver ranjiv na to.
Nadam se da je ovaj predgovor dovoljan i sada ću prijeći na stvar. Molimo vas da prihvatite moju ispriku ako ste do sada mislili da čitate o temi ovog članka. Iako sam ukratko objasnio sigurnost softvera i njegove glavne probleme, moja je tema 'Ispitivanje sigurnosti'.
Preporučena literatura => Ispitivanje sigurnosti web aplikacija
Sada ću objasniti kako su sigurnosne značajke implementirane u softversku aplikaciju i kako ih treba testirati. Moj fokus bit će na Whats and Hows sigurnosnog testiranja, a ne sigurnosti.
Preporučeni alati za ispitivanje sigurnosti
# 1) Mrežni parker
Netsparker rješenje je za testiranje sigurnosti web aplikacija s mogućnostima automatskog indeksiranja i skeniranja za sve vrste naslijeđenih i modernih web aplikacija kao što su HTML5, Web 2.0 i Single Page Applications. Koristi tehnologiju skeniranja temeljenu na dokazima i skalabilna sredstva za skeniranje.
Omogućuje vam potpunu vidljivost iako imate velik broj sredstava kojima možete upravljati. Ima mnogo više funkcionalnosti poput upravljanja timovima i upravljanja ranjivostima. Može se integrirati u CI / CD platforme poput Jenkins, TeamCity ili Bamboo.
=> Isprobajte najbolji alat za testiranje sigurnosti Netsparker-a#dva) Kiuwan
Pronađite i popravite ranjivosti u svom kodu u svakoj fazi SDLC-a.
Kiuwan je u skladu s najstrožim sigurnosnim standardima, uključujući OWASP, CWE, SANS 25, HIPPA i druge. Integrirajte Kiuwan u svoj IDE za trenutne povratne informacije tijekom razvoja. Kiuwan podržava sve glavne programske jezike i integrira se s vodećim DevOps alatima.
=> Skenirajte svoj kod besplatno# 3) Indusface JE BIO Besplatna provjera zlonamjernog softvera web stranice
Indusface je bio pruža ručno testiranje prodiranja u paketu s vlastitim automatiziranim skenerom ranjivosti web aplikacija koji otkriva i prijavljuje ranjivosti na temelju OWASP top 10, a također uključuje provjeru reputacije web stranica, zlonamjernog softvera i provjeru oštećenja web stranice u svakom skeniranju
=> Pokrenite brzo skeniranje web stranica
=> Kontaktirajte nas da ovdje predložim popis.
Popis 8 najboljih tehnika ispitivanja sigurnosti
# 1) Pristup aplikaciji
Bez obzira radi li se o stolnoj aplikaciji ili web mjestu, sigurnost pristupa provodi ‘Upravljanje ulogama i pravima’. To se često radi implicitno dok pokriva funkcionalnost,
Na primjer, u sustavu upravljanja bolnicom, recepcionara najmanje brinu laboratorijski testovi jer je njegov posao samo registrirati pacijente i zakazati im sastanke s liječnicima.
Dakle, svi izbornici, obrasci i zasloni koji se odnose na laboratorijske testove neće biti dostupni ulozi 'Recepcionara'. Stoga će pravilna provedba uloga i prava jamčiti sigurnost pristupa.
Kako testirati: Da bi se to testiralo, treba provesti temeljito testiranje svih uloga i prava.
Tester bi trebao stvoriti nekoliko korisničkih računa s različitim, kao i višestrukim ulogama. Tada bi trebao koristiti aplikaciju uz pomoć ovih računa i trebao bi provjeriti ima li svaka uloga pristup samo svojim modulima, zaslonima, obrascima i izbornicima. Ako ispitivač pronađe bilo kakav sukob, trebao bi s potpunim povjerenjem prijaviti sigurnosni problem.
To se također može shvatiti kao provjera autentičnosti i autorizacije, što je vrlo lijepo prikazano na donjoj slici:
Dakle, u osnovi morate testirati 'tko ste vi' i 'što možete učiniti' za različite korisnike.
Neki od testova provjere autentičnosti uključuju test pravila kvalitete lozinke, test zadanih prijava, test oporavka lozinke, test captcha, test funkcionalnosti odjave, test promjene lozinke, test sigurnosnog pitanja / odgovora itd.
Slično tome, neki od testova autorizacije uključuju test za obilaženje puta, test za nedostajuću autorizaciju, test za probleme s horizontalnom kontrolom pristupa itd.
# 2) Zaštita podataka
Tri su aspekta sigurnosti podataka. Prva je ta korisnik može pregledavati ili koristiti samo podatke koje bi trebao koristiti . To se osigurava i ulogama i pravima
Na primjer, TSR (predstavnik prodajne tvrtke) može vidjeti podatke o raspoloživim zalihama, ali ne može vidjeti koliko je sirovina kupljeno za proizvodnju.
Dakle, ovaj aspekt sigurnosnog testiranja već je gore objašnjen. Drugi aspekt zaštite podataka povezan je s kako se ti podaci pohranjuju u DB .
Daljnje čitanje = >> Što je ispitivanje sigurnosti baze podataka
Svi osjetljivi podaci moraju biti šifrirani kako bi bili sigurni. Šifriranje bi trebalo biti snažno, posebno za osjetljive podatke poput lozinki korisničkih računa, brojeva kreditnih kartica ili drugih poslovnih podataka važnih.
Treći i posljednji aspekt je produženje ovog drugog aspekta. Ispravne sigurnosne mjere moraju se usvojiti kada se dogodi protok osjetljivih ili poslovnih kritičnih podataka. Bez obzira plutaju li ti podaci između različitih modula iste aplikacije ili se prenose različitim aplikacijama, oni moraju biti šifrirani kako bi bili sigurni.
pitanja i odgovori za intervju za selenski webdriver
Kako testirati zaštitu podataka: Tester bi trebao ispitati bazu podataka za 'lozinke' korisničkog računa, podatke o naplati klijenata, druge kritične i osjetljive podatke za poslovanje i trebao bi provjeriti jesu li svi takvi podaci u DB-u spremljeni u šifriranom obliku.
Slično tome, mora provjeriti da li se podaci prenose između različitih obrazaca ili zaslona samo nakon odgovarajuće šifriranja. Štoviše, ispitivač bi trebao osigurati da se šifrirani podaci ispravno dešifriraju na odredištu. Posebnu pozornost treba posvetiti različitim akcijama 'podnošenja'.
Tester mora potvrditi da se prilikom prijenosa podataka između klijenta i poslužitelja ne prikazuju u adresnoj traci web preglednika u razumljivom obliku. Ako bilo koja od ovih provjera ne uspije, aplikacija definitivno ima sigurnosnu grešku.
Tester bi također trebao provjeriti pravilno korištenje soljenja (dodavanje dodatne tajne vrijednosti na krajnji ulaz poput lozinke i na taj način čineći ga jačim i težim za pucanje).
Također treba testirati nesigurnu slučajnost jer je to vrsta ranjivosti. Drugi način testiranja zaštite podataka je provjera slabe upotrebe algoritma.
Na primjer, budući da je HTTP protokol s jasnim tekstom, ako se osjetljivi podaci poput korisničkih vjerodajnica prenose putem HTTP-a, to predstavlja prijetnju sigurnosti aplikacije. Umjesto HTTP-a, osjetljivi podaci trebali bi se prenijeti putem HTTPS-a (zaštićeni putem SSL-a, TLS tunela).
Međutim, HTTPS povećava površinu napada i stoga treba testirati ispravnost konfiguracija poslužitelja i valjanost certifikata.
# 3) Napad grubom silom
Brute Force Attack uglavnom rade neki softverski alati. Koncept je da pomoću valjanog korisničkog ID-a s oftware pokušava pogoditi pridruženu lozinku pokušavajući se ponovno prijaviti.
Jednostavan primjer zaštite od takvog napada je suspenzija računa na kratko vrijeme kao što to rade sve aplikacije za slanje pošte poput 'Yahoo', 'Gmail' i 'Hotmail'. Ako se određeni broj uzastopnih pokušaja (uglavnom 3) ne uspije uspješno prijaviti, tada je taj račun blokiran na neko vrijeme (30 minuta do 24 sata).
Kako testirati Brute-Force Attack: Tester mora provjeriti je li dostupan neki mehanizam obustave računa i radi li točno. (S) Alternativno se mora pokušati prijaviti s nevažećim korisničkim ID-ovima i lozinkama kako bi bio siguran da softverska aplikacija blokira račune ako se neprestano pokušavaju prijaviti s nevažećim vjerodajnicama.
Ako aplikacija to čini, sigurna je od napada grubom silom. Inače, ispitivač mora prijaviti ovu sigurnosnu ranjivost.
Ispitivanje grube sile također se može podijeliti u dva dijela - ispitivanje crne kutije i ispitivanje sive kutije.
U testiranju crne kutije otkriva se i testira metoda provjere autentičnosti koju koristi aplikacija. Nadalje, testiranje sivog okvira temelji se na djelomičnom znanju detalja o lozinci i računu i napadima na kompromis memorije.
Klik ovdje istražiti ispitivanje grube sile crne kutije i sive kutije zajedno s primjerima.
Gore navedena tri sigurnosna aspekta treba uzeti u obzir kako za web tako i za stolne programe, dok su sljedeće točke povezane samo s web aplikacijama.
# 4) SQL Injection I XSS (Cross-Site Scripting)
Konceptualno gledano, tema oba pokušaja hakiranja slična je, pa se o njima razgovara zajedno. U ovom pristupu, zlonamjernu skriptu koriste hakeri kako bi manipulirali web stranicom .
Postoji nekoliko načina imunizacije protiv takvih pokušaja. Za sva polja za unos web stranice, duljine polja trebaju biti definirane dovoljno male da ograniče unos bilo koje skripte
kako napisati korisničke priče i kriterije prihvaćanja
Na primjer, Prezime bi trebalo imati duljinu polja umjesto 255. Možda postoje neka polja za unos gdje je potreban velik unos podataka, za takva polja treba izvršiti odgovarajuću provjeru unosa prije spremanja tih podataka u aplikaciju.
Štoviše, u takvim poljima mora biti zabranjeno unošenje bilo kakvih HTML tagova ili skripti. Da bi izazvao XSS napade, aplikacija bi trebala odbaciti preusmjeravanja skripti iz nepoznatih ili nepouzdanih aplikacija.
Kako da test SQL Injection i XSS: Tester mora osigurati da se definiraju i implementiraju maksimalne duljine svih polja za unos. (S) Također bi trebao osigurati da definirana duljina polja za unos ne sadrži nijedan unos skripte, kao ni unos oznake. Oboje se mogu lako testirati
Na primjer, Ako je 20 maksimalna duljina navedena za polje „Ime“, a ulazni niz „
thequickbrownfoxjumpsoverthelazydog 'može provjeriti oba ova ograničenja.
Tester bi također trebao potvrditi da aplikacija ne podržava anonimne metode pristupa. U slučaju da postoji bilo koja od ovih ranjivosti, aplikacija je u opasnosti.
U osnovi, testiranje ubrizgavanja SQL može se obaviti na sljedećih pet načina:
- Tehnike otkrivanja
- Standardne tehnike ubrizgavanja SQL-a
- Otisak prsta u bazi podataka
- Tehničko iskorištavanje
- Tehnike invazije potpisa ubrizgavanja SQL
Klik ovdje kako biste detaljno pročitali gornje načine testiranja SQL ubrizgavanja.
XSS je također vrsta injekcije koja ubrizgava zlonamjernu skriptu u web stranicu. Klik ovdje istražiti detaljno o testiranju za XSS.
# 5) Pristupne točke usluge (zapečaćene i sigurne otvorene)
Danas tvrtke ovise i međusobno surađuju, isto vrijedi i za aplikacije, posebno web stranice. U takvom bi slučaju suradnici trebali međusobno definirati i objaviti neke pristupne točke.
Zasad se scenarij čini prilično jednostavnim i neposrednim, ali za neke web proizvode, poput trgovanja dionicama, stvari nisu tako jednostavne i lagane.
Kada postoji velik broj ciljne publike, pristupne točke trebale bi biti dovoljno otvorene da olakšaju sve korisnike, dovoljno prilagodljive da ispune sve zahtjeve korisnika i dovoljno sigurne da se nose s bilo kojim sigurnosnim probnim razdobljem.
Kako testirati pristupne točke usluge: Dopustite mi da objasnim s primjer web aplikacije za trgovanje dionicama; investitor (koji želi kupiti dionice) trebao bi imati pristup trenutnim i povijesnim podacima o cijenama dionica. Korisnik bi trebao dobiti mogućnost preuzimanja ovih povijesnih podataka. To zahtjeva da aplikacija mora biti dovoljno otvorena.
Prilagođavanjem i sigurnošću mislim da bi aplikacija trebala olakšati investitorima slobodnu trgovinu (u skladu sa zakonskim propisima). Oni mogu kupovati ili prodavati 24/7, a podaci o transakcijama moraju biti imuni na bilo kakav napad hakiranja.
Štoviše, velik broj korisnika istovremeno će komunicirati s aplikacijom, pa bi aplikacija trebala osigurati dovoljno pristupnih točaka za zabavu svih korisnika.
U nekim slučajevima to pristupne točke mogu biti zapečaćene za neželjene programe ili ljude . To ovisi o poslovnoj domeni aplikacije i njezinim korisnicima,
Na primjer, Prilagođeni web sustav upravljanja Officeom može prepoznati svoje korisnike na temelju IP adresa i odbija uspostaviti vezu sa svim ostalim sustavima (aplikacijama) koji ne spadaju u raspon valjanih IP-ova za tu aplikaciju.
Ispitivač mora osigurati da svi pristup mreži i mreži aplikaciji pružaju pouzdane aplikacije, strojevi (IP-ovi) i korisnici.
Da bi provjerio je li otvorena pristupna točka dovoljno sigurna, ispitivač joj mora pokušati pristupiti s različitih računala koji imaju i pouzdane i nepouzdane IP adrese. Treba imati u velikom broju različite vrste transakcija u stvarnom vremenu kako bi imali dobro povjerenje u izvedbu aplikacije. Čineći to, kapacitet pristupnih točaka aplikacije također će se jasno promatrati.
Ispitivač mora osigurati da aplikacija zadovoljava sve komunikacijske zahtjeve s pouzdanih IP-ova i aplikacija samo dok su svi ostali zahtjevi odbijeni.
Slično tome, ako aplikacija ima neku otvorenu pristupnu točku, tester bi trebao osigurati da korisnicima dopušta (ako je potrebno) prijenos podataka na siguran način. Na ovaj siguran način mislim na ograničenje veličine datoteke, ograničenje vrste datoteke i skeniranje učitane datoteke na viruse ili druge sigurnosne prijetnje.
Ovo je sve kako ispitivač može provjeriti sigurnost aplikacije s obzirom na pristupne točke.
# 6) Upravljanje sjednicama
Web sesija je slijed HTTP zahtjeva i transakcija odgovora povezanih s istim korisnikom. Testovi upravljanja sesijama provjeravaju kako se upravlja sesijama u web aplikaciji.
Možete testirati istek sesije nakon određenog vremena mirovanja, prekid sesije nakon maksimalnog životnog vijeka, prekid sesije nakon odjave, provjeriti opseg i trajanje kolačića sesije, testirati može li jedan korisnik imati više istodobnih sesija itd.
# 7) Rukovanje pogreškama
Testiranje rješavanja pogrešaka uključuje:
Provjerite postoje li kodovi pogrešaka : Na primjer, testirajte vrijeme čekanja 408 zahtjeva, 400 loših zahtjeva, 404 nije pronađeno itd. Da biste ih testirali, trebate uputiti određene zahtjeve na stranicu tako da se ti kodovi pogrešaka vrate.
Kodovi pogrešaka vraćaju se s detaljnom porukom. Te poruke ne bi trebale sadržavati nikakve kritične informacije koje se mogu upotrijebiti za hakiranje
Provjerite ima li tragova stoga : To u osnovi uključuje davanje nekih iznimnih podataka aplikaciji, tako da vraćena poruka pogreške sadrži tragove steka koji imaju zanimljive informacije za hakere.
# 8) Specifične rizične funkcije
Dvije su rizične funkcionalnosti uglavnom plaćanja i prijenos datoteka . Te bi funkcionalnosti trebalo vrlo dobro ispitati. Za prijenose datoteka morate prvenstveno testirati je li ograničen svaki neželjeni ili zlonamjerni prijenos.
Za plaćanja morate prvenstveno testirati ranjivosti ubrizgavanja, nesigurnu kriptografsku pohranu, preljeve međuspremnika, pogađanje lozinke itd.
=> Kontaktirajte nas da ovdje predložim popis.Daljnje čitanje:
- Ispitivanje sigurnosti web aplikacija
- Top 30 pitanja o ispitivanju sigurnosti
- Razlika između SAST / DAST / IAST / RASP
- SANS-ovih 20 glavnih sigurnosnih ranjivosti
Preporučena literatura
- Vodič za ispitivanje sigurnosti web aplikacija
- Alfa testiranje i beta testiranje (cjelovit vodič)
- Vodič za ispitivanje skladišta podataka ETL-a (cjelovit vodič)
- Testiranje mrežne sigurnosti i najbolji alati mrežne sigurnosti
- Vodič za početnike za ispitivanje prodora web aplikacija
- Kompletni vodič za testiranje provjere izrade (BVT testiranje)
- Funkcionalno ispitivanje vs nefunkcionalno testiranje
- Cjelovit vodič za ispitivanje prodiranja s uzorcima ispitnih slučajeva