VANEK: Tak o čem se tu bavíme není opatření přímo proti phishingu, ale o situaci, kdy klient nějaký příkaz k transakci skutečně zadal a ten se během zpracování pozměnil (částka, kterou zadal klient není ta, která se ve webové aplikaci posílá jako výsledek, číslo účtu zadané klientem je jiné, než to, které ve finále zpracuje šelmostroj atd). Technicky jde o popsané útoky a lze se proti nim bránit.
Jedno řešení je mít "tak dobře" napsanou aplikaci, že danou zranitelnost vůbec nepřipouští, ale to je z řady důvodů často problém (vždycky se bavíme jen o větší či menší spolehlivosti - a spolehlivost aplikace jako jednoho bodu je limitovaná tím, že útok se jí píše na míru).
Technologicky se tomu lze bránit inteligentním web aplikačním firewallem nebo zařízením, které sleduje aplikační logiku (nikoliv jen hodnoty), kterou ji někdo naučí. Tím se do systému dostává druhý filtr navíc na dost jiných principech atd.
Konkrétní postupy pak závisí na tom, před jakým přesně typem útoku se chce aplikace chránit (a kde to má smysl), typicky co si takhle z hlavy dovedu představit u obecné aplikace internetbankingu je ochrana před
- manipulací s datovým polem, kde jde právě o to, že chytrý aplikační firewall je schopen zajistit kontrolu, že vstup zadaný v kroku jedna je potom skutečně aplikací používán i v krocích tři, čtyři a sedm, že nedochází k jeho změně "po cestě" (používá se to typicky jako obrana proti nákupům za jednu korunu v eshopech atd)
- manipulace s pořadím kroků v aplikaci, kdy lze sledovat, jestli při vyhodnocování kroku tři proběhly korektně kroky dva a jedna a zda náhodou útočník se nepokouší rovnou přejít do jiného stavu aplikace a pokračovat od něj dál. Hrubé je například vstupování do kroku objednávka/platba bez kroku autentikace, ale daleko subtilnější a v některých aplikacích hůř detekovatelné je právě to, když dojde k autentikaci a jednom celém průchodu aplikací (klient si skutečně vykoná svůj převod/objednávku) a toto pak slouží k simulování, kdy se už neopakuje krok autentikace, ale rovnou se útočník pokusí přejít k převodu a jeho vyřízení.
Samozřejmě neznám ani trochu ibanking Mbank, takže vycházím jen ze zdůvodnění, proč posílají ty "kontrolní smsky" s instrukcí "zkontroluj si kliente, jestli to my nemáme rozbitý" a ze znalosti obecných možných protiopatření na trhu. Konkrétní produkty (kdyby si to někdo chtěl dohledat podle řešení a podívat se na prezentace výrobců atd), které já znám jsou třeba od firem F5 (jejich Application Security Manager) nebo RSA (produkt Envision). Nechci tu teď rozpoutávat flame o tom, jestli konkurence je lepší nebo horší, jen dát nějaký výchozí bod, kdyby to někoho zajímalo, ať se podívá a případně si sám srovná.