security testing
Jak testovat zabezpečení aplikací - Techniky testování zabezpečení webových a desktopových aplikací
Potřeba testování bezpečnosti?
Softwarový průmysl dosáhl v tomto věku solidního uznání. V posledním desetiletí se však zdá, že kybernetický svět ještě více dominuje a je hybnou silou, která formuje nové formy téměř každého podnikání. Dnes používané webové ERP systémy jsou nejlepším důkazem toho, že IT přineslo revoluci v naší milované globální vesnici.
V dnešní době nejsou webové stránky určeny pouze pro reklamu nebo marketing, ale byly vyvinuty do silnějších nástrojů, které uspokojují obchodní potřeby.
Webové mzdové systémy, nákupní centra, bankovnictví, aplikace Stock Trade nejsou používány pouze organizacemi, ale jsou také dnes prodávány jako produkty.
To znamená, že online aplikace získaly důvěru zákazníků a uživatelů, pokud jde o jejich důležitou funkci nazvanou ZABEZPEČENÍ.
Bezpochyby má bezpečnostní faktor primární hodnotu i pro desktopové aplikace.
Když však mluvíme o webu, význam bezpečnosti exponenciálně roste. Pokud online systém nemůže chránit data transakce, nikoho nikdy nenapadne použít. Zabezpečení není ani slovem při hledání jeho definice, ani není jemným konceptem. Rád bych však uvedl několik komplimentů týkajících se bezpečnosti.
Příklad binárního stromu v C ++
Příklady bezpečnostních nedostatků v aplikaci
- Systém správy studentů není bezpečný, pokud větev „Přijímací“ může upravovat údaje větve „Zkouška“
- Systém ERP není bezpečný, pokud DEO (operátor zadávání dat) může generovat „zprávy“
- Nákupní centrum online nemá žádné zabezpečení, pokud nejsou údaje o kreditní kartě zákazníka zašifrovány
- Vlastní software má nedostatečné zabezpečení, pokud dotaz SQL načte skutečná hesla svých uživatelů
Bezpečnostní
Nyní vám představuji nejjednodušší definici bezpečnosti podle mých vlastních slov.
„Zabezpečení znamená, že k chráněným datům je poskytnut autorizovaný přístup a je omezen neoprávněný přístup.“ .
Má tedy dva hlavní aspekty; první je ochrana dat a druhou přístup k těmto datům. Kromě toho, ať už jde o stolní nebo webovou aplikaci, zabezpečení se točí kolem dvou výše uvedených aspektů.
Pojďme si udělat přehled bezpečnostních aspektů pro desktopové i webové softwarové aplikace.
Co se naučíte:
Testování zabezpečení pro počítače a weby
Desktopová aplikace by měla být zabezpečená nejen co se týče jejího přístupu, ale také s ohledem na organizaci a ukládání jejích dat.
Podobně vyžaduje webová aplikace ještě větší zabezpečení, pokud jde o její přístup, spolu s ochranou dat. Webový vývojář by měl učinit aplikaci imunní vůči SQL Injection, Brute Force Attacks a XSS (cross-site scripting). Podobně, pokud webová aplikace umožňuje vzdálené přístupové body, musí být také bezpečné.
Navíc mějte na paměti, že Brute Force Attack se netýká pouze webových aplikací, desktopový software je vůči tomu také zranitelný.
Doufám, že tato předmluva stačí a nyní mi dovolte, abych k věci přišel. Laskavě přijměte moji omluvu, pokud jste si dosud mysleli, že čtete o předmětu tohoto článku. Ačkoli jsem stručně vysvětlil zabezpečení softwaru a jeho hlavní obavy, mým tématem je „Testování zabezpečení“.
Doporučené čtení => Testování zabezpečení webových aplikací
Nyní vysvětlím, jak jsou funkce zabezpečení implementovány do softwarové aplikace a jak by měly být testovány. Zaměřím se na to, co a jak testovat zabezpečení, ne na bezpečnost.
Doporučené nástroje pro testování zabezpečení
# 1) Čistý parker
Netsparker je řešení testování zabezpečení webových aplikací s možností automatického procházení a skenování všech typů starších a moderních webových aplikací, jako jsou HTML5, Web 2.0 a Jednostránkové aplikace. Využívá technologii skenování založenou na důkazech a škálovatelné skenovací agenty.
Poskytuje vám úplnou viditelnost, i když máte ke správě velké množství aktiv. Má mnohem více funkcí, jako je správa týmu a správa zranitelností. Může být integrován do platforem CI / CD, jako je Jenkins, TeamCity nebo Bamboo.
=> Vyzkoušejte nejlepší nástroj pro testování zabezpečení Netsparker#dva) Kiuwan
Najděte a opravte chyby zabezpečení v kódu v každé fázi SDLC.
Kiuwan odpovídá nejpřísnějším bezpečnostním standardům včetně OWASP, CWE, SANS 25, HIPPA a dalších. Integrujte Kiuwan do svého IDE pro okamžitou zpětnou vazbu během vývoje. Kiuwan podporuje všechny hlavní programovací jazyky a integruje se s předními nástroji DevOps.
=> Naskenujte svůj kód zdarma# 3) Indusface BEZPLATNÁ kontrola malwaru webových stránek
Indusface BOL poskytuje ruční testování penetrace dodávané s vlastním automatizovaným skenerem zranitelnosti webových aplikací, který detekuje a hlásí zranitelnosti na základě top 10 OWASP, a zahrnuje kontrolu reputace webových stránek u odkazů, malwaru a kontroly zničení webu v každém skenování
=> Spusťte zdarma rychlé skenování webových stránek
=> Kontaktujte nás navrhnout seznam zde.
Seznam 8 nejlepších technik testování bezpečnosti
# 1) Přístup k aplikaci
Ať už se jedná o desktopovou aplikaci nebo web, zabezpečení přístupu implementuje „Role a správa práv“. Často se to děje implicitně a zároveň se vztahuje na funkčnost,
Například, v systému pro správu nemocnic je recepční nejméně znepokojen laboratorními testy, protože jeho úkolem je pouze registrovat pacienty a naplánovat jejich schůzky s lékaři.
Role „recepčního“ tedy nebudou mít k dispozici všechna menu, formuláře a obrazovky související s laboratorními testy. Správná implementace rolí a práv tedy zaručí bezpečnost přístupu.
Jak testovat: Abychom to mohli otestovat, je třeba provést důkladné testování všech rolí a práv.
Tester by měl vytvořit několik uživatelských účtů s různými i více rolemi. Poté by měl aplikaci používat pomocí těchto účtů a měl by ověřit, že každá role má přístup pouze k vlastním modulům, obrazovkám, formulářům a nabídkám. Pokud tester zjistí jakýkoli konflikt, měl by s jistotou zaznamenat bezpečnostní problém.
Lze to také chápat jako testování ověřování a autorizace, které je velmi krásně znázorněno na následujícím obrázku:
V zásadě tedy musíte vyzkoušet, „kdo jste“ a „co můžete dělat“ u různých uživatelů.
Některé z testů ověřování zahrnují test na pravidla kvality hesla, test na výchozí přihlášení, test na obnovení hesla, test captcha, test na funkčnost odhlášení, test na změnu hesla, test na bezpečnostní otázku / odpověď atd.
Podobně některé z autorizačních testů zahrnují test průchodu cesty, test chybějící autorizace, test problémů s horizontálním řízením přístupu atd.
# 2) Ochrana údajů
Existují tři aspekty zabezpečení dat. První je to uživatel může prohlížet nebo využívat pouze data, která má používat . To zajišťují také role a práva
Například, TSR (zástupce prodeje) společnosti může zobrazit údaje o dostupných zásobách, ale nevidí, kolik surovin bylo zakoupeno pro výrobu.
Tento aspekt testování zabezpečení je tedy již vysvětlen výše. Druhý aspekt ochrany údajů souvisí s jak jsou tato data uložena v DB .
Další čtení = >> Co je Testování zabezpečení databáze
Všechna citlivá data musí být šifrována, aby byla zabezpečena. Šifrování by mělo být silné, zejména u citlivých dat, jako jsou hesla uživatelských účtů, čísla kreditních karet nebo jiné důležité obchodní informace.
Třetí a poslední aspekt je rozšířením tohoto druhého aspektu. Pokud dojde k toku citlivých nebo kritických dat, musí být přijata náležitá bezpečnostní opatření. Ať už se tato data pohybují mezi různými moduly stejné aplikace nebo jsou přenášena do různých aplikací, musí být pro zajištění bezpečnosti šifrována.
Jak otestovat ochranu dat: Tester by měl v databázi vyhledávat „hesla“ uživatelského účtu, fakturační údaje o klientech, další důležitá obchodní a citlivá data a měl by ověřit, zda jsou všechna taková data uložena v zašifrované podobě v databázi.
Podobně musí ověřit, že data jsou přenášena mezi různými formami nebo obrazovkami pouze po správném šifrování. Tester by navíc měl zajistit, aby byla šifrovaná data v cíli správně dešifrována. Zvláštní pozornost by měla být věnována různým akcím „odeslání“.
Tester musí ověřit, že když se informace přenáší mezi klientem a serverem, nejsou zobrazeny v adresním řádku webového prohlížeče v srozumitelném formátu. Pokud některá z těchto verzí selže, pak má aplikace rozhodně bezpečnostní chybu.
Tester by měl také zkontrolovat správné použití solení (přidání dodatečné tajné hodnoty ke koncovému vstupu, jako je heslo, a tím ztěžovat a ztěžovat jeho prolomení).
Měla by být také testována nejistá náhodnost, protože jde o druh zranitelnosti. Dalším způsobem, jak otestovat ochranu dat, je zkontrolovat slabé použití algoritmu.
Například, protože HTTP je protokol s čistým textem, jsou-li citlivá data, jako jsou pověření uživatele, přenášena přes HTTP, pak jde o ohrožení bezpečnosti aplikace. Namísto protokolu HTTP by měla být citlivá data přenášena prostřednictvím protokolu HTTPS (zabezpečeného prostřednictvím SSL, tunelu TLS).
HTTPS však zvyšuje útočnou plochu, a proto je třeba otestovat, zda jsou konfigurace serveru správné a zda je zajištěna platnost certifikátu.
# 3) Brute-Force Attack
Brute Force Attack se většinou provádí pomocí některých softwarových nástrojů. Koncept spočívá v tom, že pomocí platného ID uživatele se s oftware se pokouší uhodnout přidružené heslo opakovaným pokusem o přihlášení.
Jednoduchým příkladem zabezpečení proti takovému útoku je pozastavení účtu na krátkou dobu, jak to dělají všechny poštovní aplikace jako „Yahoo“, „Gmail“ a „Hotmail“. Pokud se určitý počet po sobě jdoucích pokusů (většinou 3) nepodaří úspěšně přihlásit, je tento účet na nějakou dobu (30 minut až 24 hodin) blokován.
nejlepší bezplatný video převodník pro Windows 10
Jak otestovat útok Brute-Force: Tester musí ověřit, zda je k dispozici nějaký mechanismus pozastavení účtu a zda funguje správně. (S) Musí se pokusit přihlásit pomocí neplatných uživatelských ID a hesel, aby se ujistil, že softwarová aplikace blokuje účty, pokud se neustále pokouší přihlásit s neplatnými přihlašovacími údaji.
Pokud to aplikace dělá, je zabezpečená proti útoku hrubou silou. Jinak musí tato chyba zabezpečení nahlásit tester.
Testování hrubou silou lze také rozdělit na dvě části - testování černé skříňky a testování šedé skříně.
V testování černé skříňky je metoda ověřování použitá aplikací objevena a testována. Testování šedého pole je dále založeno na částečné znalosti podrobností o heslech a účtech a útocích na kompromis paměti.
Klepněte na tady prozkoumat testování hrubou silou v černé a šedé skříňce spolu s příklady.
Výše uvedené tři aspekty zabezpečení by měly být brány v úvahu pro webové i desktopové aplikace, zatímco následující body se týkají pouze webových aplikací.
# 4) Vkládání SQL a XSS (skriptování mezi weby)
Koncepčně lze říci, že téma obou těchto pokusů o hackerství je podobné, takže jsou diskutovány společně. V tomto přístupu je škodlivý skript používají hackeři k manipulaci s webem .
Existuje několik způsobů, jak se imunizovat proti těmto pokusům. Pro všechna vstupní pole webu by měly být délky polí definovány dostatečně malé, aby omezovaly vstup jakéhokoli skriptu
herní brýle pro virtuální realitu xbox 360
Například, Příjmení by mělo mít délku pole 30 místo 255. Mohou existovat některá vstupní pole, kde je nutný velký vstup dat, pro taková pole by měla být provedena správná validace vstupu před uložením těchto dat do aplikace.
V těchto polích musí být navíc zakázány jakékoli značky HTML nebo vstup značek skriptů. Aby bylo možné vyvolat útoky XSS, aplikace by měla zahodit přesměrování skriptů z neznámých nebo nedůvěryhodných aplikací.
Jak otestujte SQL Injection a XSS: Tester musí zajistit, aby byly definovány a implementovány maximální délky všech vstupních polí. (S) Měl by také zajistit, aby definovaná délka vstupních polí nepřijala žádný vstup skriptu ani vstup značky. Oba lze snadno otestovat
Například, Pokud je 20 maximální délka zadaná pro pole „Název“ a vstupní řetězec „
thequickbrownfoxjumpsoverthelazydog “může ověřit obě tato omezení.
Tester by měl také ověřit, že aplikace nepodporuje anonymní přístupové metody. V případě, že některá z těchto chyb zabezpečení existuje, je aplikace v nebezpečí.
Testování vkládání SQL lze v zásadě provést následujícími pěti způsoby:
- Detekční techniky
- Standardní techniky vkládání SQL
- Otisk databáze
- Technické využití
- Techniky invaze podpisu SQL Injection
Klepněte na tady podrobně si přečíst výše uvedené způsoby testování injekce SQL.
XSS je také typ injekce, která injektuje škodlivý skript na web. Klepněte na tady podrobně prozkoumat testování pro XSS.
# 5) Servisní přístupové body (uzavřené a bezpečné otevřené)
Dnes jsou podniky vzájemně závislé a spolupracují, totéž platí pro aplikace, zejména pro webové stránky. V takovém případě by měli spolupracovníci navzájem definovat a zveřejnit některé přístupové body.
Scénář se zatím jeví jako docela jednoduchý a přímý, ale u některých webových produktů, jako je obchodování s akciemi, to není tak jednoduché a snadné.
Pokud je cílového publika velké množství, měly by být přístupové body dostatečně otevřené, aby umožnily všem uživatelům, dostatečně přizpůsobivé k tomu, aby vyhověly požadavkům všech uživatelů, a dostatečně zabezpečené, aby zvládly jakýkoli bezpečnostní pokus.
Jak testovat servisní přístupové body: Vysvětlím to pomocí příklad webové aplikace pro obchodování s akciemi; investor (který chce akcie koupit) by měl mít přístup k aktuálním a historickým údajům o cenách akcií. Uživatel by měl mít možnost stáhnout si tato historická data. To vyžaduje, aby aplikace byla dostatečně otevřená.
Tím, že jsem vyhověl a zajistil, mám na mysli, že aplikace by měla investorům usnadnit volný obchod (podle legislativních předpisů). Mohou nakupovat nebo prodávat 24 hodin denně, 7 dní v týdnu a data transakcí musí být imunní vůči jakémukoli hackerskému útoku.
Kromě toho bude s aplikací interagovat velký počet uživatelů současně, takže aplikace by měla poskytovat dostatek přístupových bodů, aby pobavila všechny uživatele.
V některých případech tyto přístupové body mohou být zapečetěny pro nežádoucí aplikace nebo lidi . To záleží na obchodní doméně aplikace a jejích uživatelích,
Například, Vlastní webový systém pro správu Office může rozpoznat své uživatele na základě adres IP a odmítá navázat spojení se všemi ostatními systémy (aplikacemi), které nespadají do rozsahu platných adres IP pro danou aplikaci.
Tester musí zajistit, aby všechny přístup mezi sítěmi a uvnitř sítě k aplikaci využívají důvěryhodné aplikace, stroje (IP) a uživatelé.
Aby bylo možné ověřit, zda je otevřený přístupový bod dostatečně bezpečný, musí se tester pokusit o přístup z různých počítačů, které mají důvěryhodné i nedůvěryhodné adresy IP. Měli byste hromadně vyzkoušet různé druhy transakcí v reálném čase, abyste měli dobrou důvěru ve výkon aplikace. Tímto způsobem bude také jasně sledována kapacita přístupových bodů aplikace.
Tester musí zajistit, aby aplikace bavila všechny požadavky na komunikaci z důvěryhodných IP adres a aplikací, zatímco všechny ostatní požadavky byly odmítnuty.
Podobně, pokud má aplikace nějaký otevřený přístupový bod, měl by se tester ujistit, že umožňuje (je-li to požadováno) bezpečné nahrávání dat uživateli. Tímto bezpečným způsobem mám na mysli limit velikosti souboru, omezení typu souboru a skenování nahraného souboru na viry nebo jiné bezpečnostní hrozby.
To je vše, jak může tester ověřit zabezpečení aplikace s ohledem na její přístupové body.
# 6) Správa relací
Webová relace je sled transakcí požadavku a odpovědi HTTP propojených se stejným uživatelem. Testy správy relací kontrolují, jak se ve webové aplikaci zachází se správou relací.
Můžete otestovat vypršení platnosti relace po určité době nečinnosti, ukončení relace po maximální době životnosti, ukončení relace po odhlášení, zkontrolovat rozsah a trvání souborů cookie relace, otestovat, zda jeden uživatel může mít více současných relací atd.
# 7) Zpracování chyb
Testování zpracování chyb zahrnuje:
Zkontrolujte chybové kódy : Například, otestujte časový limit požadavku 408, 400 chybných požadavků, 404 nebyl nalezen atd. Chcete-li je otestovat, musíte na stránku zadat určité požadavky, aby se tyto chybové kódy vrátily.
Chybové kódy jsou vráceny s podrobnou zprávou. Tyto zprávy by neměly obsahovat žádné důležité informace, které lze použít k hackerským účelům
Zkontrolujte stopy zásobníku : V zásadě to zahrnuje poskytnutí nějakého výjimečného vstupu do aplikace, takže vrácená chybová zpráva obsahuje stopy zásobníku, které mají pro hackery zajímavé informace.
# 8) Specifické rizikové funkce
Jedná se hlavně o dvě rizikové funkce Platby a nahrávání souborů . Tyto funkce by měly být testovány velmi dobře. U nahrávání souborů musíte nejprve otestovat, zda je omezeno jakékoli nežádoucí nebo škodlivé nahrávání souborů.
U plateb musíte primárně otestovat zranitelnost injekcí, nezabezpečené kryptografické úložiště, přetečení vyrovnávací paměti, hádání hesla atd.
=> Kontaktujte nás navrhnout seznam zde.Další čtení:
- Testování zabezpečení webových aplikací
- Top 30 otázek týkajících se testování zabezpečení
- Rozdíl mezi SAST / DAST / IAST / RASP
- Top 20 bezpečnostních zranitelností SANS
Doporučené čtení
- Průvodce testováním zabezpečení webových aplikací
- Alfa testování a beta testování (kompletní průvodce)
- Výukový program pro testování datového skladu ETL (kompletní průvodce)
- Testování zabezpečení sítě a nejlepší nástroje pro zabezpečení sítě
- Průvodce pro začátečníky k testování penetrace webových aplikací
- Kompletní průvodce pro testování ověřování sestavení (testování BVT)
- Funkční testování vs. nefunkční testování
- Kompletní příručka pro testování penetrace se vzorky testovacích případů