Již několikrát jsem dostal otázku na téma bezpečnosti aplikace SAWAPP, zejména s ohledem na to, že je vytvořena v nových technologiích. Tento článek rozebere, jak se naše technologie brání typickým útokům, a získáte odpověď na otázku, zda je to bezpečnější než aplikace napsané v tradičních technologiích.
Jiná aplikace může získat vaše session ID a použít ho k vyvolání nějaké funkce. Session ID je typicky uloženo v cookie (ano, to je ta sušenka, jejíž existenci musíte v každé webové aplikaci schválit). Pokud by útočník nějakým trikem přiměl oběť spustit vedle přihlášení do banky také nějakou napadenou stránku a ta by skutečně byla schopna získat session ID dané banky, mohl by útočník zavolat libovolnou funkci – třeba „převeď peníze na můj účet“.
Parametr SameSite: Ta sušenka (cookie) má různé parametry, jedním z nich je SameSite. My ho máme vždy nastavený na Strict, čímž prohlížeči říkáme: „Tato sušenka slouží jen pro naši doménu.“
Platnost sušenky: Dalším z parametrů je platnost sušenky. My máme nastaveno 1 den. To znamená, že pokud by uživatel odešel od PC na delší dobu, session vyprší, uživatel se bude muset znovu přihlásit a dostane nové session ID. Toto je obvyklé pro libovolnou webovou aplikaci a WebAssembly se v tomto ničím neliší.
Detekce chyb: Je však třeba říci, co se stane, když je v těchto session parametrech chyba. U běžné webové aplikace to nepoznáte, bude dál fungovat, ale bude mít zranitelnost, o které nebudete vědět. Naproti tomu SAWAPP využívá nejnovější API webového prohlížeče, která již v základním nastavení vyžadují SameSite=Strict. Pokud by tedy v SAWAPP.cloud byla nějaká chyba tohoto typu, poznáte to okamžitě: aplikace se vůbec nespustí.
Útočník se pokusí zadávat do vašich formulářů různé apostrofy a řídicí znaky jazyka SQL. Pokud je v aplikaci chyba, může tím ovlivnit práci s databází.
Příklad zranitelnosti: Máme formulář, kde zadáváme jméno uživatele, a máme naivní aplikaci, která filtruje tabulku osob podle jména:
SELECT jmeno, prijmeni, role FROM uzivatele WHERE name = '{$jmeno}';
Průběh útoku: Kde $jmeno$ jsme získali z formuláře. Útočník do pole zadá například:
kk'; UPDATE uzivatele SET role='admin' WHERE prijmeni='hacker_nick'; --
V databázi pak vznikne dotaz, kde útočníkovi sice stránka vypíše seznam uživatelů, ale zároveň se v systému stane adminem. Dvě pomlčky -- jsou komentář, takže takto upravený dotaz je z hlediska syntaxe validní a v databázi projde.
Automatizované útoky: Ačkoliv je drtivá většina aplikací proti tomuto ošetřena, hackery tohle fascinuje natolik, že si programují roboty, kteří bombardují veškeré formuláře na internetu a zkoušejí tam vkládat apostrofy. Vyplnit vám formulář 50 000krát za noc útočníka nic nestojí.
Validace dat: Pokud jde o formuláře, máme hned několik ochran. Prvně už na klientovi (v prohlížeči) otestujeme, zda jsou data správného typu – například zda celá čísla obsahují jen číslice. Pak se formulářová data pošlou na server. Tam je úplně stejná funkce, která to zkontroluje ještě jednou pro případ, že by útočník volal naše API přímo, bez našeho klienta.
Sdílený kód: Zde je právě obrovská výhoda naší technologie: můžeme mít stejné zdrojové texty nasazené jak na klientovi, tak na serveru.
Prepared Queries: Další ochrana spočívá v tom, že i knihovna pro práci s databází používá tzv. Prepared Queries, kde se opět testuje, zda je řetězec validní. Nelepíme tedy textové stringy dohromady, jako bylo ukázáno v příkladu výše.
Útočník si vyrobí vlastní web, který vypadá úplně stejně jako ten pravý. Oběť v domnění, že se přihlašuje do pravého systému, zadá jméno a heslo, které tímto prozradí útočníkovi.
Metody útočníka: Útočník má v podstatě tři možnosti:
Lidský faktor: Body 2 a 3 spoléhají výhradně na nepozornost oběti. V případě smyšlené domény uvidíte jinou adresu v adresním řádku URL, u spoofingu uvidíte červený zámeček nebo nápis „nezabezpečeno“. Bohužel lidé jsou nepozorní. Pro útočníka je vždy jednodušší obelhat člověka než aplikaci. Aby uživatel uviděl správnou doménu a zelený zámeček, musel by útočník napadnout TLS certifikát a uhodnout jeho klíč, což se v reálném čase nejspíš nikomu nepodařilo.
Náročnost kopírování: Zkopírovat HTML stránky je velmi snadné (zdrojový text uvidíte přes „Zobrazit zdrojový kód“). Zkopírovat ale WebAssembly aplikaci je úplně jiná úroveň náročnosti. Sice můžete zkopírovat WASM objekt a spustit ho jinde, ale ten se bude stále připojovat k nám a nebude fungovat kvůli ochraně proti CSRF.
Reverzní inženýrství: Disassemblování do původního zdrojového textu v podstatě nejde. Jediné, co lze, je získat strojový formát (soubor .wat). Práce s ním je však extrémně náročná – dokonce mnohonásobně pracnější než vytvořit aplikaci zcela znovu. Nám trvaly práce na aplikaci 4 roky; vaše aplikace pravděpodobně není pro útočníka takovým aktivem, aby se o něco podobného pokoušel.
Vynucené zabezpečení: Stejně jako u CSRF vyžadují některá pokročilá API prohlížeče validní certifikát, jinak aplikace nebude správně fungovat.
Pro útočníka je vždy jednodušší obelhat člověka než aplikaci. Proto bude zkoušet různá hesla. Útočník si napíše skript, který se bude zkoušet přihlásit třeba milionkrát za noc. Hesla může zkusit vygenerovat nebo využít existujících slovníků (slovníkový útok) a zkoušet reálná slova. Ideální pro útočníka je opatřit si databázi uniklých hesel z jiných služeb a zkoušet ta, protože lidé používají stejná hesla opakovaně.
Časová prodleva: Necháme útočníka po neúspěšném pokusu o přihlášení několik sekund čekat. Tím omezíme frekvenci pokusů.
Blokování účtu: Po 5 neúspěšných pokusech se účet zablokuje. Odemknout účet oběti může pouze administrátor aplikace.
V některých systémech (typicky WordPress) se v minulosti našly zranitelnosti, které umožnily útočníkovi získat konfigurační data, jako třeba heslo do databáze. Navíc řada systémů (v PHP) má na veřejné adrese přístupného správce databáze.
Izolovaná databáze: Databáze SAWAPP.cloud není veřejně přístupná a má veškeré potřebné zabezpečení.
Kontrola API: U všech API volání striktně kontrolujeme parametry. Riziko, že by útočník naši aplikaci nějak „rozhodil“, je omezeno na minimum.
Docker kontejner: I kdyby útočník našel chybu, běží naše aplikace v Docker kontejneru. Dostat se z tohoto systému ven na hostitele je úplně jiný level bezpečnosti, to se mu jen tak nepovede.
Šifrování konfigurací: I kdyby se útočník dostal do kontejneru, konfigurační soubory jsou zašifrované. Klíč k nim je pouze v operační paměti a jeho vydolování je pro útočníka dalším složitým problémem.
Útočník se nesnaží systém prolomit, ale vyřadit ho z provozu tím, že ho zahltí obrovským množstvím požadavků.
Ochrana serverovny: Naše aplikace je umístěna v renomované serverovně v Česku, která disponuje funkčními anti-DDoS ochranami.
Každá země má své zákony. Pokud použijete cloudové řešení americké firmy s daty fyzicky uloženými třeba v Německu, téměř libovolný americký úředník si může vaše data vyžádat a má na ně nárok.
Fyzické umístění v ČR: U nás máme data uložena fyzicky v renomované serverovně v Praze. Serverovna splňuje bezpečnostní požadavky a certifikace, například ISO 9001. Vaše data tak může požadovat pouze česká policie na základě soudního povolení.
Možnost vlastního NAS: Úplně nejvyšší level soukromí je, že naši aplikaci můžete provozovat na vaší vlastní NASce. Ale i tu vám může policie na soudní příkaz zabavit, pokud se bude domnívat, že je na ní něco nelegálního.
