Zabezpečení aplikací - Application security
![]() | tento článek pravděpodobně potřebuje reorganizaci, aby vyhověla požadavkům Wikipedie pokyny pro rozložení.Srpna 2016) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) ( |
Část série na |
Informační bezpečnost |
---|
Související kategorie zabezpečení |
Hrozby |
Obrana |
Zabezpečení aplikací zahrnuje opatření přijatá ke zlepšení bezpečnosti aplikace často hledáním, opravou a prevencí bezpečnosti zranitelnosti. K vyplnění takové bezpečnosti se používají různé techniky zranitelnosti v různých fázích životního cyklu aplikací, jako je design, rozvoj, rozvinutí, vylepšit, údržba.
Neustále se vyvíjející, ale do značné míry konzistentní sada společných bezpečnostních nedostatků je vidět napříč různými aplikacemi, viz společné nedostatky.
Podmínky
- Aktivum. Zdroj hodnot, jako jsou data v databázi, peníze na účtu, soubor v souborovém systému nebo jakýkoli systémový prostředek.
- Zranitelnost. Slabina nebo mezera v bezpečnostním programu, kterou lze zneužít hrozbami k získání neoprávněného přístupu k aktivu.
- Záchvat (nebo využít). Akce přijatá k poškození aktiva.
- Ohrožení. Cokoli, co může zneužít zranitelnost a získat, poškodit nebo zničit aktivum.
Techniky
Různé techniky najdou různé podskupiny bezpečnostních chyb číhajících v aplikaci a jsou nejúčinnější v různých dobách životního cyklu softwaru. Každý z nich představuje různé kompromisy času, úsilí, nákladů a nalezených zranitelností.
- Kontrola zabezpečení Whitebox nebo kontrola kódu. Jedná se o bezpečnostního inženýra, který hluboce rozumí aplikaci prostřednictvím ruční kontroly zdrojového kódu a všímání bezpečnostních nedostatků. Díky pochopení zranitelnosti aplikace lze nalézt jedinečná zranitelnost aplikace.
- Bezpečnostní audit Blackboxu. Je to pouze pomocí aplikace, která ji testuje na chyby zabezpečení, není vyžadován žádný zdrojový kód.
- Recenze designu. Před napsáním kódu prochází a model ohrožení aplikace. Někdy spolu se specifikačním nebo designovým dokumentem.
- Nástroje. Existuje mnoho automatizovaných nástrojů, které testují bezpečnostní chyby, často s vyšší mírou falešně pozitivních výsledků, než je zapojení člověka.
- Koordinované platformy zranitelnosti. Jedná se o řešení zabezpečení aplikací využívaná hackery, která nabízejí mnoho webů a vývojářů softwaru a kterým mohou jednotlivci získat uznání a kompenzaci za hlášení chyb.
Vhodným využitím těchto technik v celém systému životní cyklus vývoje softwaru (SDLC) pro maximalizaci zabezpečení je role týmu zabezpečení aplikace.
Hrozby a útoky aplikací
Podle vzorů a postupů Zlepšení zabezpečení webových aplikací knihy jsou následující třídy běžných bezpečnostních hrozeb a útoků:
Kategorie | Hrozby a útoky |
---|---|
Ověření vstupu | Přetečení zásobníku; skriptování mezi weby; Vložení SQL; kanonizace |
Manipulace se softwarem | Útočník upravuje běhové chování existující aplikace tak, aby provádělo neautorizované akce; využíván prostřednictvím binární opravy, nahrazení kódu nebo rozšíření kódu |
Ověření | Odposlech sítě; Útok hrubou silou; slovníkové útoky; přehrávání souborů cookie; krádež pověření |
Oprávnění | Povýšení privilegia; zveřejnění důvěrných údajů; manipulace s daty; lákavé útoky |
Správa konfigurace | Neoprávněný přístup k administračním rozhraním; neoprávněný přístup do konfiguračních obchodů; načítání konfiguračních dat v čistém textu; nedostatek individuální odpovědnosti; nadměrně privilegované účty procesů a služeb |
Citlivé informace | Přístup k citlivému kódu nebo datům v úložišti; odposlech sítě; neoprávněná manipulace s kódem / daty |
Správa relací | Únos relace; přehrávání relace; muž uprostřed |
Kryptografie | Špatné generování klíčů nebo správa klíčů; slabé nebo vlastní šifrování |
Manipulace s parametry | Manipulace s řetězci dotazů; manipulace s polem formuláře; manipulace s cookies; Manipulace s hlavičkou HTTP |
Správa výjimek | Zveřejňování informací; odmítnutí služby |
Auditování a protokolování | Uživatel popírá provedení operace; útočník zneužije aplikaci beze stopy; útočník pokrývá své stopy |
The OWASP komunita zveřejňuje seznam 10 nejzranitelnějších zranitelností webových aplikací a nastiňuje osvědčené bezpečnostní postupy pro organizace, přičemž se snaží vytvořit otevřené standardy pro toto odvětví.[1][propagační zdroj? ] Od roku 2017 uvádí organizace hlavní bezpečnostní hrozby aplikací jako:[2]
Kategorie | Hrozby / útoky |
---|---|
Injekce | SQL injection; NoSQL; Příkaz OS; Objektově-relační mapování; Injekce LDAP |
Nefunkční ověřování | Credential nádivka; útoky hrubou silou; slabá hesla |
Citlivá expozice dat | Slabá kryptografie; nevynucené šifrování |
Externí entity XML | Útok externí entity XML |
Nefunkční řízení přístupu | Nesprávná konfigurace CORS; vynucené procházení; povýšení privilegia |
Chybná konfigurace zabezpečení | Neopravené chyby; selhání nastavení hodnot zabezpečení v nastavení; zastaralý nebo zranitelný software |
Cross-site skriptování (XSS) | Odráží XSS; Uložené XSS; DOM XSS |
Nejistá deserializace | Objektová a datová struktura je upravena; neoprávněná manipulace s daty |
Používání komponent se známými chybami zabezpečení | Zastaralý software; selhání při hledání zranitelností; neschopnost opravit základní rámcové platformy; selhání aktualizované nebo upgradované kompatibility knihovny |
Nedostatečné protokolování a monitorování | Selhání protokolování auditovatelných událostí; selhání generování jasných zpráv protokolu: nevhodné výstrahy; selhání detekce nebo upozornění na aktivní útoky v reálném čase nebo v jeho blízkosti |
Zabezpečení mobilních aplikací
Očekává se, že podíl mobilních zařízení poskytujících funkčnost otevřené platformy bude v budoucnu nadále narůstat. Otevřenost těchto platforem nabízí významné příležitosti všem částem mobilního ekosystému tím, že poskytuje schopnost flexibilního poskytování programů a služeb = možnosti, které lze instalovat, odebírat nebo obnovovat několikrát v souladu s potřebami a požadavky uživatele. S otevřeností však přichází odpovědnost a neomezený přístup k mobilním zdrojům a API aplikacemi neznámého nebo nedůvěryhodného původu by mohl vést k poškození uživatele, zařízení, sítě nebo všech těchto, pokud by nebyly spravovány vhodnými bezpečnostními architekturami a síťovými opatřeními. Zabezpečení aplikací je v určité formě poskytováno na většině otevřených mobilních zařízení s OS (Symbian OS,[3] Microsoft,[Citace je zapotřebí ] VAŘIT, atd.). V roce 2017 Google rozšířil své Program odměn za zranitelnost k pokrytí zranitelností nalezených v aplikacích vyvinutých třetími stranami a zpřístupněných prostřednictvím obchodu Google Play.[4] Průmyslové skupiny rovněž vytvořily doporučení včetně Sdružení GSM a Otevřete platformu mobilních terminálů (OMTP).[5]
Existuje několik strategií pro zvýšení zabezpečení mobilních aplikací, včetně:
- Seznam povolených aplikací
- Zajištění zabezpečení transportní vrstvy
- Silné ověřování a autorizace
- Šifrování dat při zápisu do paměti
- Sandboxing aplikací
- Udělení přístupu k aplikacím na úrovni jednotlivých API
- Procesy vázané na ID uživatele
- Předdefinované interakce mezi mobilní aplikací a OS
- Vyžadování vstupu uživatele pro privilegovaný / zvýšený přístup
- Správné zpracování relace
Testování zabezpečení aplikací
Techniky testování zabezpečení vyhledávají zranitelná místa nebo bezpečnostní díry v aplikacích. Tyto chyby zabezpečení nechávají aplikace otevřené vykořisťování. V ideálním případě je testování zabezpečení implementováno v celém rozsahu životní cyklus vývoje softwaru (SDLC), aby bylo možné zranitelná místa řešit včas a důkladně. Testování se bohužel často provádí jako dodatečný nápad na konci vývojového cyklu. S růstem Kontinuální dodávka a DevOps jako populární modely vývoje a nasazení softwaru,[6][propagační zdroj? ] modely nepřetržitého zabezpečení jsou stále populárnější.[7][propagační zdroj? ][8][propagační zdroj? ]
Skenery zranitelnosti a konkrétněji skenery webových aplikací, jinak známé jako penetrační testování nástroje (tj. etické hackerství nástroje) byly historicky používány bezpečnostními organizacemi v rámci korporací a bezpečnostními konzultanty k automatizaci testování bezpečnosti požadavků / odpovědí http; To však nenahrazuje potřebu skutečné kontroly zdrojového kódu. Kontroly fyzického kódu zdrojového kódu aplikace lze provádět ručně nebo automatizovaným způsobem. Vzhledem k běžné velikosti jednotlivých programů (často 500 000 řádků kódu nebo více) nemůže lidský mozek provést komplexní analýzu toku dat potřebnou k tomu, aby úplně zkontroloval všechny cesty aplikace, aby našel body zranitelnosti. Lidský mozek je vhodný spíše pro filtrování, přerušení a hlášení výstupů komerčně dostupných komerčně dostupných nástrojů pro analýzu zdrojového kódu ve srovnání se snahou vystopovat každou možnou cestu skrz kompilovanou kódovou základnu a najít zranitelná místa na úrovni příčin.
Existuje mnoho druhů automatizovaných nástrojů pro identifikaci zranitelných míst v aplikacích. Některé vyžadují k použití velké množství bezpečnostních zkušeností a jiné jsou navrženy pro plně automatizované použití. Výsledky závisí na typech informací (zdroj, binární údaje, provoz HTTP, konfigurace, knihovny, připojení) poskytovaných nástroji, kvalitě analýzy a rozsahu zahrnutých zranitelností. Mezi běžné technologie používané k identifikaci slabých míst aplikace patří:
Statické testování zabezpečení aplikací (SAST) je technologie, která se často používá jako nástroj pro analýzu zdrojového kódu. Metoda analyzuje zdrojový kód na chyby zabezpečení před spuštěním aplikace a používá se k posílení kódu. Tato metoda produkuje méně falešných poplachů, ale pro většinu implementací vyžaduje přístup ke zdrojovému kódu aplikace[9] a vyžaduje odbornou konfiguraci a velkou výpočetní sílu.[10][propagační zdroj? ]
Dynamické testování zabezpečení aplikací (DAST) je technologie, která je schopna najít viditelné chyby zabezpečení vložením adresy URL do automatizovaného skeneru. Tato metoda je vysoce škálovatelná, snadno integrovatelná a rychlá. Nevýhody DAST spočívají v potřebě odborné konfigurace a vysoké možnosti falešných pozitiv a negativ.[9]
Interaktivní testování zabezpečení aplikací (IAST) je řešení, které hodnotí aplikace zevnitř používání softwarové vybavení. Tato technika umožňuje IAST kombinovat silné stránky metod SAST a DAST a také poskytovat přístup ke kódu, provozu HTTP, informacím o knihovně, back-endovým připojením a konfiguračním informacím.[11] [12] Některé produkty IAST vyžadují napadení aplikace, zatímco jiné lze použít při běžném testování zajištění kvality.[13][propagační zdroj? ][14][propagační zdroj? ]
Bezpečnostní ochrana aplikací
Pokrok v profesionálech Malware zaměřené na internet zákazníci online organizací zaznamenali od roku 2007 změnu požadavků na design webových aplikací. Obecně se předpokládá, že značné procento uživatelů internetu bude ohroženo prostřednictvím malware a že veškerá data přicházející z infikovaného hostitele mohou být poskvrněna. Proto se zabezpečení aplikací začalo projevovat pokročilejšími systémy proti podvodům a heuristickým detekčním systémům v back-office, spíše než v rámci kódu na straně klienta nebo webového serveru.[15][propagační zdroj? ] Od roku 2016 vlastní ochrana běhové aplikace (RASP) byly vyvinuty technologie.[9][16] RASP je technologie nasazená v prostředí běhového prostředí aplikace nebo vedle něj, která nástrojuje aplikaci a umožňuje detekci a prevenci útoků.[17][18]
Koordinované odhalení zranitelnosti
Koordinační centrum CERT popisuje Coordinated Vulnerability Disclosure (CVD) jako „proces snižování nepřátelské výhody při snižování zranitelnosti zabezpečení informací.“ [19] CVD je iterativní vícefázový proces, který zahrnuje více zúčastněných stran (uživatelů, prodejců, bezpečnostních výzkumníků), kteří mohou mít různé priority a kteří musí společně vyřešit tuto chybu zabezpečení. Protože procesy CVD zahrnují více zúčastněných stran, je pro úspěch rozhodující správa komunikace o zranitelnosti a jejím řešení.
Z provozního hlediska může v CVD pomoci mnoho nástrojů a procesů. Patří mezi ně e-mailové a webové formuláře, systémy sledování chyb a Koordinované platformy zranitelnosti.[20]
Bezpečnostní normy a předpisy
- CERT zabezpečené kódování
- CWE
- DISA-STIG
- Zákon Gramm-Leach-Bliley
- Zákon o přenositelnosti a odpovědnosti v oblasti zdravotního pojištění (HIPAA)
- ISO / IEC 27034-1: 2011 Informační technologie - Bezpečnostní techniky - Zabezpečení aplikací - Část 1: Přehled a koncepty
- ISO / IEC TR 24772: 2013 Informační technologie - Programovací jazyky - Pokyny k zabránění zranitelnosti programovacích jazyků prostřednictvím výběru a používání jazyků
- Speciální publikace NIST 800-53
- OWASP
- PCI Data Security Standard (PCI DSS )
- Zákon o Sarbanes-Oxley (SOX)
- ETSI TS 103 645 [21]
Viz také
- Útočná plocha portfolia aplikací
- Protiopatření
- Bezpečnost dat
- Zabezpečení databáze
- HERAS-AF
- Informační bezpečnost
- Důvěryhodný životní cyklus vývoje zabezpečení
- webová aplikace
- Rámec webových aplikací
Reference
- ^ „Co je OWASP a proč je to důležité pro AppSec“. Zabezpečení kontrastu. 23. února 2017. Citováno 10. dubna 2018.
- ^ „OWASP Top 10 - 2017“ (PDF). OWASP. 2017. Citováno 10. dubna 2018.
- ^ „Koncepce zabezpečení platformy“ Simon Higginson.
- ^ „Google spustil nový program odměn za chyby, který má odstranit chyby zabezpečení v aplikacích třetích stran na Google Play“. The Verge. 22. října 2017. Citováno 15. června 2018.
- ^ „Rámec zabezpečení aplikace“. Archivovány od originál 29. března 2009., Otevřete platformu mobilních terminálů
- ^ „Výsledky průzkumu DevOps: Proč podniky přijímají průběžné dodávky = 1. prosince 2017“. oblačné včely. Citováno 26. června 2018.
- ^ „Trvalé zabezpečení ve světě DevOps = 5. července 2016“. Konference RMLL 2016. Citováno 4. července 2018.
- ^ „Tapping Hackers for Continuous Security = 31. března 2017“. HackerOne. Citováno 4. července 2018.
- ^ A b C „Interaktivní testování zabezpečení aplikací: Co je třeba vědět“. Komunita kybernetické bezpečnosti TATA. 9. června 2016. Archivovány od originál 20. června 2018. Citováno 25. ledna 2018.
- ^ Williams, Jeff (22. září 2015). „Proč je šílené důvěřovat statické analýze“. TMAVÉ Čtení. Citováno 10. dubna 2018.
- ^ Williams, Jeff (2. července 2015). „Rozumím SAST a DAST, ale co je IAST a proč na tom záleží?“. Zabezpečení kontrastu. Citováno 10. dubna 2018.
- ^ Velasco, Roberto (7. května 2020). „Co je IAST? Vše o interaktivním testování zabezpečení aplikací“. Zabezpečení HDDIV. Citováno 7. května 2020.
- ^ Abezgauz, Irene (17. února 2014). „Úvod do interaktivního testování zabezpečení aplikací“. Quotium.
- ^ Rohr, Matthias (26. listopadu 2015). „IAST: Nový přístup k agilnímu testování bezpečnosti“. Secodis.
- ^ „Pokračování v podnikání se zákazníky infikovanými malwarem“. Gunter Ollmann. Říjen 2008.
- ^ „Co je IAST? Interaktivní testování zabezpečení aplikací“. Verakód.
- ^ „IT glosář: Runtime Application Self-Protection“. Gartner.
- ^ Feiman, Joseph (červen 2012). „Security Think Tank: RASP - nezbytná bezpečnostní technologie“. Počítač týdně.
- ^ „Průvodce CERT ke zveřejnění koordinované chyby zabezpečení“. Institut softwarového inženýrství, Carnegie Mellon University. Srpna 2017. Citováno 20. června 2018.
- ^ „Průvodce CERT ke zveřejnění koordinované chyby zabezpečení“. Institut softwarového inženýrství, Carnegie Mellon University. Srpna 2017. Citováno 20. června 2018.
- ^ „ETSI TS 103 645“ (PDF).