Co zjišťujeme

Test může zjistit některé základní bezpečnostní chyby zjistitelné zvenku. Pokud jsou zranitelnosti ošetřeny, snižuje se celková zranitelnost webu. Rychlý ruční test a interpretace výsledků minimalizuje falešná pozitiva a umožňuje objevit některé další zranitelnosti, které skener neobjeví. K podání uceleného obrazu o bezpečnosti systému tyto testy neslouží, (muselo by se přihlédnout k širšímu kontextu bezpečnostních aspektů).

Znalosti zranitelností serverů mohou ohrozit provozovatele serveru anebo ostatní provozovatele webů, kteří hostují na stejném serveru. Proto jestliže nejste provozovatelem serveru, kde je webová aplikace hostována, zjištěné slabiny vám můžeme sdělit pouze po svolení provozovatele serveru, a to pouze v případě, že tímto sdělením nebude ohrožen jiný provozovatel webu.

Ostatní
Do testů zahrnujeme také zjišťování dalších slabin – např. citlivost na Google Hacking, zbytečné informace usnadňující napadení webu, únik dat na Internet a řadu dalších skutečností.

A1 - Injektování (Injection)

Chyby umožňující napadení aplikace vložením kódu přes neošetřený vstup. Vkládáním kódu do neošetřeného vstupu útočník může spouštět příkazy s privilegovanými právy, k nimž by neměl mít přístup.

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
snadná
Rozšíření
běžné
Zjistitelnost
průměrná
Dopad
vážný
Aplikační / obchodní specifikum
Vezměte v úvahu každého, kdo může posílat nedůvěryhodná data do systému, včetně externích uživatelů, interních uživatelů a administrátorů. Útočník posílá jednoduché textové příkazy, které zneužívají syntaxi cílového interpretu. Přenašečem injektování může být téměř každý zdroj dat včetně interních. Chyby typu injektování vznikají, když aplikace posílá do interpretu nedůvěryhodná data. Tyto chyby jsou velmi rozšířené, obzvláště v tzv. Legacy Code. Často bývají nalezeny v dotazech SQL, LDAPu, Xpath, nebo v NoSQL; v příkazech OS, parserech XML, hlavičkách SMTP, argumentech programů atd. Chyby typu injektování se snadno zjiš ťují zkoumáním kódu, ale často hůře jiným testováním. S nalezením těchto chyb mohou útočníkům pomoci skenery a fuzzery. Injektování může mít za následek ztrátu nebo narušení integrity, odpovědnosti či dostupnosti. Někdy může injektování vést ke kompletnímu ovládnutí hostitelského serveru. Zvažte obchodní hodnotu dotčených dat a platformy, na níž běží interpret. Mohou být ukradena, změněna nebo odstraněna všechna data. Nemůže dojít k poškození vaší pověsti?
Jsem zranitelný vůči injektování?

Nejlepším způsobem jak zjistit, zda je aplikace zranitelná na injektováním, je ověřit, jestli všechna použití interpretů jasně oddělují nedůvěryhodná data od příkazů či dotazů. V případě volání SQL to znamená použít bind variables (vázané proměnné) ve všech prepared statements (připravených příkaz\ ech) a stored procedures (uložených procedurách) a vyhnout se dynamickým dotazům (dynamic queries).

Rychlým a přesným způsobem jak zjistit, zda aplikace používá intereprety bezpečně, je kontrola kódu. Bezpečnostním analytikům mohou pomoci najít místa použití interpretů a sledovat tok dat nástroje pro analýzu kódu. Penetrační testeři mohou ověřit nalezené zranitelnosti vytvořením exploitů, které \ zranitelnost potvrdí.

Automatické dynamické skenování, které otestuje aplikaci, může poskytnout informaci, zda se v aplikaci vyskytují nějaké trhliny umožňující injektování. Skenery ne vždy dosáhnou na interpety a mají potíže se zjištěním, jestli byl útok úspěšný. Špatné ošetřování chyb znesnadňuje objevování chyb inje\ ktování.

Jak mohu předejít „injektování“?

Abychom zabránili injektování, měli bychom oddělovat nedůvěryhodná data od používaných příkazů a dotazů.

  • 1. Preferovanou možností je použít bezpečné API, které vůbec nepoužívá interpret nebo poskytuje parametrizované rozhraní. Buďte však opatrní v případě API, která, ačkoliv jsou parametrizovaná, skrytě umožňují injektování, např. stored procedures (uložené procedury).
  • 2. Není-li parametrizované API k dispozici, měli byste pečlivě escapovat pomocí syntaxe specifické pro daný interpret. Mnoho \ escapovacich rutin poskytuje OWASP ESAPI.
  • 3. Také se doporučuje ověřování vstupů na základě pozitivních zkoušek nebo „white listů“. Takovou obranu ovšem nelze považova\ t za úplnou, neboť mnoho aplikací na vstupu vyžaduje speciální znaky. Pouze výše uvedené přístupy 1. a 2. zajistí, aby použití takových znaků bylo bezpečné. OWASP ESAPI obsahuje rozšířitelnou knihovnu rutin, které ověřují vstupy na základě „white listů“.
Příklady možných útoků

Příklad č. #1: Aplikace používá při vytvoření následujícího zranitelného volání SQL nedůvěryhodná data:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Příklad č. #2: Podobně slepá důvěra aplikace k frameworku může vyústit v dotazy, které jsou stále zranitelné (např. Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'");

V obou případech změní útočník hodnotu parametru ’ id’ v prohlížeči tak, aby poslal ' or '1'='1. Například:

http://example.com/app/acountView?id=:' or '1'='1

Toto změní smysl obou dotazů tak, že se vrátí všechny záznamy z tabulky „accounts“. Nebezpečnější útoky mohou změnit data, či dokonce vyvolat stored procedures (uložené procedury).

Odkazy
OWASP: Externí: