security testing
Ako testovať zabezpečenie aplikácií - techniky testovania zabezpečenia webových a desktopových aplikácií
Potreba testovania bezpečnosti?
Softvérový priemysel dosiahol v tomto veku solídne uznanie. V poslednom desaťročí sa však zdá, že kybernetický svet ešte viac dominuje a je hnacou silou, ktorá formuje nové formy takmer každého podnikania. Webové systémy ERP, ktoré sa dnes používajú, sú najlepším dôkazom toho, že IT prinieslo revolúciu v našej milovanej globálnej dedine.
V dnešnej dobe nie sú webové stránky určené iba na propagáciu alebo marketing, ale vyvinuli sa z nich silnejšie nástroje, ktoré uspokojujú obchodné potreby.
Webové mzdové systémy, nákupné centrá, bankovníctvo, aplikácia Stock Trade nielenže používajú organizácie, ale aj sa dnes predávajú ako produkty.
To znamená, že online aplikácie si získali dôveru zákazníkov a používateľov, pokiaľ ide o ich dôležitú funkciu pomenovanú ako BEZPEČNOSŤ.
Bezpochyby má bezpečnostný faktor primárnu hodnotu aj pre desktopové aplikácie.
Keď však hovoríme o webe, význam bezpečnosti exponenciálne rastie. Ak online systém nemôže chrániť údaje o transakcii, nikoho nikdy nenapadne použiť. Bezpečnosť zatiaľ nie je hľadaním svojej definície ani slovom, ani jemným konceptom. Rád by som však uviedol niekoľko pochvál s bezpečnosťou.
Príklady bezpečnostných chýb v aplikácii
Otázky a odpovede na pohovor s testerom qa
- Systém správy študentov nie je bezpečný, ak pobočka „Vstupné“ môže upravovať údaje pobočky „Skúška“
- Systém ERP nie je bezpečný, ak DEO (operátor zadávania údajov) dokáže generovať „správy“
- Nákupné centrum online nemá žiadne zabezpečenie, ak nie sú údaje o kreditnej karte zákazníka šifrované
- Zákazkový softvér nemá dostatočné zabezpečenie, ak dotaz SQL načítava skutočné heslá jeho používateľov
Bezpečnosť
Teraz vám predstavím najjednoduchšiu definíciu bezpečnosti podľa mojich vlastných slov.
„Zabezpečenie znamená, že k chráneným údajom je udelený autorizovaný prístup a neoprávnený prístup je obmedzený.“ .
Má to teda dva hlavné aspekty; prvou je ochrana údajov a druhou prístup k týmto údajom. Navyše, či už ide o počítačovú alebo webovú aplikáciu, bezpečnosť sa točí okolo dvoch vyššie spomenutých aspektov.
Poďme si urobiť prehľad bezpečnostných aspektov pre desktopové aj webové softvérové aplikácie.
Čo sa dozviete:
Testovanie bezpečnosti na počítači a webe
Aplikácia pre stolné počítače by mala byť bezpečná nielen pokiaľ ide o jej prístup, ale aj pokiaľ ide o organizáciu a ukladanie jej údajov.
Podobne webová aplikácia vyžaduje ešte viac bezpečnosti, pokiaľ ide o jej prístup, spolu s ochranou údajov. Webový vývojár by mal zabezpečiť, aby bola aplikácia odolná voči SQL Injection, Brute Force Attacks a XSS (skriptovanie medzi stránkami). Podobne, ak webová aplikácia umožňuje vzdialené prístupové body, musia byť tiež zabezpečené.
Okrem toho nezabúdajte, že Brute Force Attack sa netýka iba webových aplikácií, je voči tomu zraniteľný aj desktopový softvér.
Dúfam, že táto predhovor je dostatočná, a dovoľte mi teraz prísť k veci. Ak ste si doteraz mysleli, že čítate o téme tohto článku, prijmite moje ospravedlnenie. Aj keď som v krátkosti vysvetlil softvér Zabezpečenie a jeho hlavné obavy, mojou témou je „Testovanie zabezpečenia“.
Odporúčané čítanie => Testovanie bezpečnosti webových aplikácií
Teraz vysvetlím, ako sa funkcie zabezpečenia implementujú do softvérových aplikácií a ako by sa mali testovať. Ja sa zameriam na Čo a ako testovať bezpečnosť, nie na bezpečnosť.
Odporúčané nástroje na testovanie bezpečnosti
# 1) Čistý parker
Netsparker je riešenie na testovanie bezpečnosti webových aplikácií s možnosťou automatického prehľadávania a skenovania všetkých typov starších a moderných webových aplikácií, ako sú HTML5, Web 2.0 a Single Page Applications. Využíva technológiu skenovania založenú na dôkazoch a škálovateľné skenovacie prostriedky.
Poskytuje vám úplnú viditeľnosť, aj keď máte na správu veľké množstvo aktív. Má oveľa viac funkcií, ako napríklad správu tímu a správu zraniteľností. Môže byť integrovaný do platforiem CI / CD ako Jenkins, TeamCity alebo Bamboo.
=> Vyskúšajte najlepší bezpečnostný nástroj Netsparker#dva) Kiuwan
Nájdite a opravte chyby v kóde v každej fáze SDLC.
Kiuwan je v súlade s najprísnejšími bezpečnostnými štandardmi vrátane OWASP, CWE, SANS 25, HIPPA a ďalších. Integrujte Kiuwan do svojho IDE pre okamžitú spätnú väzbu počas vývoja. Kiuwan podporuje všetky hlavné programovacie jazyky a integruje sa s poprednými nástrojmi DevOps.
=> Naskenujte svoj kód zadarmo# 3) Indusface BEZPLATNÁ kontrola malvéru na webových stránkach
Indusface BOL poskytuje manuálne testovanie prieniku dodávané s vlastným automatizovaným skenerom zraniteľností webových aplikácií, ktorý detekuje a hlási zraniteľnosti na základe top 10 OWASP a pri každom skenovaní obsahuje aj kontrolu reputácie webových stránok, odkazov, škodlivého softvéru a kontroly poškodenia webových stránok
=> Spustite rýchle skenovanie webových stránok zadarmo
=> Kontaktuj nás navrhnúť zoznam tu.
Zoznam 8 najlepších techník testovania bezpečnosti
# 1) Prístup k aplikácii
Či už je to desktopová aplikácia alebo web, zabezpečenie prístupu je implementované pomocou „Úlohy a správa práv“. Často sa to deje implicitne, zatiaľ čo sa kryje funkčnosť,
Napríklad, v systéme riadenia nemocníc sa recepčný najmenej obáva laboratórnych testov, pretože jeho úlohou je iba registrovať pacientov a plánovať ich schôdzky s lekármi.
Takže všetky ponuky, formuláre a obrazovky súvisiace s laboratórnymi testami nebudú dostupné pre úlohu „recepčného“. Správna implementácia rolí a práv teda zaručí bezpečnosť prístupu.
Ako testovať: Aby sme to otestovali, malo by sa vykonať dôkladné otestovanie všetkých rol a práv.
Tester by mal vytvoriť niekoľko používateľských účtov s rôznymi aj viacerými rolami. Potom by mal aplikáciu používať pomocou týchto účtov a mal by overiť, či má každá rola prístup iba k svojim vlastným modulom, obrazovkám, formulárom a ponukám. Ak tester zistí akýkoľvek konflikt, mal by s úplnou istotou zaznamenať bezpečnostný problém.
Dá sa to chápať aj ako testovanie autentifikácie a autorizácie, ktoré je veľmi pekne znázornené na nasledujúcom obrázku:
V zásade teda musíte otestovať, kto ste a čo môžete urobiť pre rôznych používateľov.
Niektoré z testov autentifikácie zahŕňajú test pravidiel kvality hesla, test predvolených prihlásení, test obnovenia hesla, test captcha, test funkčnosti odhlásenia, test zmeny hesla, test bezpečnostnej otázky / odpovede atď.
Niektoré z autorizačných testov zahŕňajú test priechodu cesty, test chýbajúcej autorizácie, test problémov s horizontálnym prístupom atď.
# 2) Ochrana údajov
Existujú tri aspekty bezpečnosti údajov. Prvý je ten používateľ môže prezerať alebo využívať iba údaje, ktoré má používať . To tiež zaisťujú roly a práva
Napríklad, TSR (zástupca obchodného predaja) spoločnosti môže zobraziť údaje o dostupných zásobách, ale nevidí, koľko surovín bolo zakúpených na výrobu.
Tento aspekt testovania bezpečnosti je už teda vysvetlený vyššie. Druhý aspekt ochrany údajov súvisí s ako sú tieto údaje uložené v databáze .
Ďalšie čítanie = >> Čo je to Testovanie bezpečnosti databázy
Všetky citlivé údaje musia byť šifrované, aby boli zabezpečené. Šifrovanie by malo byť silné, najmä pre citlivé údaje, ako sú heslá používateľských účtov, čísla kreditných kariet alebo iné dôležité obchodné informácie.
Tretí a posledný aspekt je rozšírením tohto druhého aspektu. Keď dôjde k toku citlivých alebo obchodných kritických údajov, musia sa prijať náležité bezpečnostné opatrenia. Či už tieto údaje plávajú medzi rôznymi modulmi tej istej aplikácie alebo sa prenášajú do rôznych aplikácií, musia byť v záujme bezpečnosti šifrované.
Ako otestovať ochranu údajov: Tester by mal v databáze vyhľadávať „heslá“ používateľského účtu, fakturačné údaje klientov, ďalšie dôležité obchodné údaje a citlivé údaje a mal by overiť, či sú všetky tieto údaje uložené v zašifrovanej podobe v databáze DB.
Podobne musí overiť, že údaje sa prenášajú medzi rôznymi formami alebo obrazovkami iba po správnom šifrovaní. Tester by navyše mal zabezpečiť, aby sa šifrované údaje v mieste určenia správne dešifrovali. Osobitná pozornosť by sa mala venovať rôznym akciám „predložiť“.
Tester musí overiť, či sa informácie prenášané medzi klientom a serverom nezobrazujú v adresnom riadku webového prehľadávača v zrozumiteľnom formáte. Ak niektoré z týchto overení zlyhá, potom má aplikácia určite bezpečnostnú chybu.
Tester by mal skontrolovať aj správne použitie solenia (pridanie extra tajnej hodnoty ku konečnému vstupu, ako je heslo, a tým pádom zvýšiť jeho odolnosť a sťažiť jeho prelomenie).
Mali by ste tiež otestovať nezabezpečenú náhodnosť, pretože ide o druh zraniteľnosti. Ďalším spôsobom, ako otestovať ochranu údajov, je skontrolovať slabé použitie algoritmu.
Napríklad, pretože HTTP je protokol s čistým textom, ak sa citlivé údaje, ako sú prihlasovacie údaje používateľa, prenášajú prostredníctvom protokolu HTTP, potom to predstavuje hrozbu pre bezpečnosť aplikácie. Namiesto protokolu HTTP by sa mali citlivé údaje prenášať prostredníctvom protokolu HTTPS (zabezpečeného pomocou protokolu SSL, tunela TLS).
najlepšie miesto na pozeranie anime online
Avšak HTTPS zvyšuje útočnú plochu, a preto by sa malo vyskúšať, či sú konfigurácie servera správne a či je zaručená platnosť certifikátu.
# 3) Brute-Force Attack
Brute Force Attack sa väčšinou vykonáva pomocou niektorých softvérových nástrojov. Koncept je taký, že s použitím platného ID užívateľa bude s oftware sa pokúša uhádnuť príslušné heslo pokusom o prihlásenie znova a znova.
Jednoduchým príkladom zabezpečenia proti takémuto útoku je pozastavenie účtu na krátke obdobie, ako to robia všetky poštové aplikácie ako Yahoo, Gmail a Hotmail. Ak sa určitý počet po sebe idúcich pokusov (väčšinou 3) nepodarí úspešne prihlásiť, potom je tento účet na nejaký čas (30 minút až 24 hodín) zablokovaný.
Ako otestovať útok Brute-Force: Tester musí overiť, či je k dispozícii nejaký mechanizmus pozastavenia účtu a či funguje správne. Musí sa pokúsiť prihlásiť pomocou neplatných ID používateľov a hesiel, aby sa ubezpečil, že softvérová aplikácia zablokuje účty, ak sa neustále pokúša prihlásiť s neplatnými povereniami.
Ak to aplikácia robí, je zabezpečená proti útoku hrubou silou. V opačnom prípade musí túto bezpečnostnú chybu nahlásiť tester.
Testovanie hrubej sily možno tiež rozdeliť na dve časti - testovanie čiernej skrinky a testovanie šedej skrinky.
Pri testovaní čiernej skrinky je objavená a testovaná metóda autentifikácie použitá aplikáciou. Testovanie šedej skrinky je ďalej založené na čiastočnej znalosti podrobností hesla a účtu a útokoch kompromisu pamäte.
Kliknite tu preskúmať testovanie hrubou silou v čiernej a šedej skrinke spolu s príkladmi.
Vyššie uvedené tri aspekty zabezpečenia by sa mali brať do úvahy pre webové aj desktopové aplikácie, zatiaľ čo nasledujúce body sa týkajú iba webových aplikácií.
# 4) SQL Injection a XSS (skriptovanie medzi servermi)
Koncepčne možno povedať, že téma oboch týchto hackerských pokusov je podobná, takže sa o nich diskutuje spoločne. V tomto prístupe hackeri používajú škodlivý skript na manipuláciu s webovou stránkou .
Existuje niekoľko spôsobov, ako sa proti takýmto pokusom imunizovať. Pre všetky vstupné polia webových stránok by mali byť dĺžky polí definované dostatočne malé, aby obmedzili vstup ľubovoľného skriptu
Napríklad, Priezvisko by malo mať dĺžku poľa 30, nie 255. Môžu sa vyskytnúť niektoré vstupné polia, kde je potrebný veľký vstup údajov, pre tieto polia by sa mala pred uložením týchto údajov do aplikácie vykonať správna validácia vstupu.
najlepšia herná spoločnosť, pre ktorú môžete pracovať
V týchto poliach musia byť navyše zakázané všetky značky HTML alebo vstup značiek skriptov. S cieľom vyvolať útoky XSS by aplikácia mala zahodiť presmerovania skriptov z neznámych alebo nedôveryhodných aplikácií.
Ako otestujte SQL Injection a XSS: Tester musí zabezpečiť, aby boli definované a implementované maximálne dĺžky všetkých vstupných polí. (S) Mal by tiež zabezpečiť, aby definovaná dĺžka vstupných polí nezodpovedala žiadnemu vstupu skriptu, ako aj vstupu značky. Oboje sa dá ľahko otestovať
Napríklad, Ak je 20 maximálna dĺžka uvedená v poli „Názov“ a vstupný reťazec „
thequickbrownfoxjumpsoverthelazydog “dokáže overiť obe tieto obmedzenia.
Tester by mal tiež overiť, že aplikácia nepodporuje metódy anonymného prístupu. V prípade, že existuje niektorá z týchto chýb zabezpečenia, je aplikácia v nebezpečenstve.
Testovanie vstrekovania SQL je možné v zásade vykonať nasledujúcimi piatimi spôsobmi:
- Detekčné techniky
- Štandardné techniky vkladania SQL
- Odtlačok prsta v databáze
- Technické využitie
- Techniky invázie podpisu SQL Injection
Kliknite tu podrobne si prečítať vyššie uvedené spôsoby testovania vstrekovania SQL.
XSS je tiež typ injekcie, ktorá vstrekuje škodlivý skript na webovú stránku. Kliknite tu podrobne preskúmať testovanie na XSS.
# 5) Servisné prístupové body (uzavreté a bezpečné otvorené)
Dnes sú podniky navzájom závislé a spolupracujú, to isté platí pre aplikácie, najmä pre webové stránky. V takom prípade by mali obaja spolupracovníci navzájom definovať a zverejniť niektoré prístupové body.
Zatiaľ sa scenár zdá celkom jednoduchý a priamy, ale pre niektoré webové produkty, ako je obchodovanie s akciami, veci nie sú také jednoduché a ľahké.
Ak je cieľového publika veľké množstvo, prístupové body by mali byť dostatočne otvorené na to, aby to uľahčili všetkým používateľom, vyhovujúce na splnenie všetkých požiadaviek používateľov a dostatočne zabezpečené na zvládnutie akejkoľvek bezpečnostnej skúšky.
Ako otestovať prístupové body k službe: Vysvetlím to pomocou príklad webovej aplikácie na obchodovanie s akciami; investor (ktorý chce kúpiť akcie) by mal mať prístup k aktuálnym a historickým údajom o cenách akcií. Užívateľ by mal mať možnosť tieto historické údaje stiahnuť. To si vyžaduje, aby bola aplikácia dostatočne otvorená.
Pod pojmom ústretový a zabezpečený mám na mysli, že aplikácia by mala investorom uľahčiť voľný obchod (podľa legislatívnych predpisov). Môžu nakupovať alebo predávať 24 hodín denne, 7 dní v týždni a údaje o transakciách musia byť imunné proti hackerským útokom.
Okrem toho bude s aplikáciou interagovať veľký počet používateľov súčasne, takže aplikácia by mala poskytovať dostatok prístupových bodov na pobavenie všetkých používateľov.
V niektorých prípadoch aj tieto prístupové body môžu byť zapečatené pre nežiaduce aplikácie alebo ľudí . Závisí to od obchodnej domény aplikácie a jej používateľov,
Napríklad, Vlastný webový systém správy Office môže rozpoznať svojich používateľov na základe adries IP a odmietnuť nadviazanie spojenia so všetkými ostatnými systémami (aplikáciami), ktoré nespadajú do rozsahu platných adries IP pre danú aplikáciu.
Tester musí zabezpečiť, aby všetky medzisieťový a vnútrosieťový prístup k aplikácii slúžia dôveryhodné aplikácie, stroje (IP) a používatelia.
Aby sa overilo, či je otvorený prístupový bod dostatočne bezpečný, musí sa tester pokúsiť o prístup z rôznych počítačov, ktoré majú dôveryhodné aj nedôveryhodné adresy IP. Aby ste mali dobrú dôveru vo výkonnosť aplikácie, mali by ste hromadne vyskúšať rôzne druhy transakcií v reálnom čase. Týmto spôsobom bude tiež zreteľne dodržaná kapacita prístupových bodov aplikácie.
Tester musí zabezpečiť, aby aplikácia uspokojila všetky komunikačné požiadavky z dôveryhodných adries IP a aplikácií, až kým nebudú zamietnuté všetky ostatné požiadavky.
Podobne, ak má aplikácia otvorený prístupový bod, potom by sa mal tester ubezpečiť, že umožňuje (ak je to potrebné) bezpečné nahrávanie údajov používateľmi. Týmto bezpečným spôsobom mám na mysli limit veľkosti súboru, obmedzenie typu súboru a skenovanie nahraného súboru na prítomnosť vírusov alebo iných bezpečnostných hrozieb.
Takto môže tester overiť bezpečnosť aplikácie vzhľadom na jej prístupové body.
# 6) Správa relácie
Webová relácia je postupnosť transakcií požiadaviek a odpovedí HTTP spojených s rovnakým používateľom. Testy správy relácií kontrolujú, ako sa vo webovej aplikácii zaobchádza so správou relácií.
Môžete otestovať vypršanie platnosti relácie po určitom nečinnom čase, ukončenie relácie po maximálnej dobe životnosti, ukončenie relácie po odhlásení, skontrolovať rozsah a trvanie súborov cookie relácie, otestovať, či jeden používateľ môže mať viac súčasných relácií atď.
# 7) Spracovanie chýb
Testovanie spracovania chýb obsahuje:
Skontrolujte chybové kódy : Napríklad, otestujte časový limit žiadosti 408, 400 zlých požiadaviek, 404 nenájdených atď. Ak ich chcete otestovať, musíte na stránku odoslať určité požiadavky, aby sa tieto chybové kódy vrátili.
Chybové kódy sa vrátia s podrobnou správou. Tieto správy by nemali obsahovať žiadne dôležité informácie, ktoré možno použiť na účely hackerstva
Skontrolujte stopy stohovania : V zásade to zahŕňa poskytnutie niektorých výnimočných vstupov do aplikácie, takže vrátená chybová správa obsahuje stopy zásobníka, ktoré majú zaujímavé informácie pre hackerov.
# 8) Špecifické rizikové funkcie
Jedná sa hlavne o dve rizikové funkcie platby a nahrávanie súborov . Tieto funkcionality by sa mali testovať veľmi dobre. Pri nahrávaní súborov musíte predovšetkým otestovať, či je zakázané akékoľvek nežiaduce alebo škodlivé nahrávanie súborov.
Pri platbách musíte primárne otestovať zraniteľnosť injekcie, nezabezpečené kryptografické úložisko, pretečenia vyrovnávacej pamäte, hádanie hesla atď.
=> Kontaktuj nás navrhnúť zoznam tu.Ďalšie čítanie:
- Testovanie bezpečnosti webových aplikácií
- Najvyšších 30 otázok týkajúcich sa rozhovorov o testovaní zabezpečenia
- Rozdiel medzi SAST / DAST / IAST / RASP
- SANS Top 20 zraniteľností zabezpečenia
Odporúčané čítanie
- Sprievodca testovaním bezpečnosti webových aplikácií
- Alfa testovanie a beta testovanie (kompletný sprievodca)
- Výukový program na testovanie dátových skladov ETL (kompletný sprievodca)
- Testovanie zabezpečenia siete a najlepšie nástroje zabezpečenia siete
- Sprievodca pre začiatočníkov k testovaniu penetrácie webových aplikácií
- Kompletný sprievodca zostavením Verification Testing (BVT Testing)
- Funkčné testovanie vs. Nefunkčné testovanie
- Kompletný sprievodca testovaním penetrácie so vzorovými testovacími prípadmi