Ochrana webovej aplikácie — bezpečnostné hlavičky, CSRF a čistenie obsahu

Po ľudsky

Webová aplikácia sa nemusí chrániť len pred tým, kto sa do nej chce vlámať, ale aj pred trikmi, pri ktorých útočník zneužije vás — váš prehliadač a vaše prihlásenie. Napríklad: otvoríte cudziu stránku a tá sa v pozadí pokúsi v Module niečo zmeniť vaším menom. Alebo niekto pošle e-mail s ukrytým kódom, ktorý by sa pri zobrazení spustil. Alebo vloží Modulo do neviditeľného okna na svojej stránke a naláka vás kliknúť. Proti každému z týchto trikov máme samostatnú poistku — podobne ako dom nemá len zámok na dverách, ale aj mreže, alarm a kukátko.

Technicky

Bezpečnostné hlavičky HTTP (posielané pri každej odpovedi aplikácie):

• Strict-Transport-Security (HSTS) — prehliadač si na rok zapamätá, že doména (aj subdomény) sa smie otvárať len cez HTTPS; útočník v sieti nemôže spojenie „stiahnuť“ na nešifrované.
• X-Frame-Options: SAMEORIGIN — cudzia stránka nemôže Modulo vložiť do rámca (ochrana pred clickjackingom, keď vás niekto naláka kliknúť do neviditeľného okna).
• X-Content-Type-Options: nosniff — prehliadač nesmie hádať typ súboru; nahratý súbor sa tak nespustí ako skript.
• Referrer-Policy: strict-origin-when-cross-origin — pri prechode na cudzí web sa neprenáša celá adresa stránky, len doména.
• Server neprezrádza, na akej technológii beží.

Ochrana pred CSRF (Cross-Site Request Forgery — podvrhnutá požiadavka cudzej stránky s vaším prihlásením):

• Súbor cookie s prihlásením má príznak SameSite.
• Každá zápisová požiadavka (a niekoľko čítacích, ktoré menia stav) overenej cez cookie sa kontroluje podľa hlavičky Sec-Fetch-Site, ktorú posiela prehliadač a z JavaScriptu sa podvrhnúť nedá; povolené sú len požiadavky z tej istej stránky. Staršie prehliadače sa kontrolujú podľa hlavičky Origin. Požiadavky z inej subdomény alebo cudzieho webu sú odmietnuté.

Ochrana pred XSS (Cross-Site Scripting — podstrčený skript v obsahu):

• Obsah, ktorý nepochádza z nášho kódu (telá prijatých e-mailov, články, poznámky, podpisy), sa pred zobrazením čistí podľa zoznamu povolených značiek a atribútov: odstránia sa skripty, formuláre, vložené rámce, štýly schopné prekryť rozhranie, obslužné atribúty (onclick a pod.) aj odkazy typu javascript:.
• Druhá vrstva čistenia prebehne už pri uložení na serveri, aby v databáze neležal škodlivý kód pre iné cesty (export, asistent, PDF).
• Vložené obrázky vo formáte SVG sa čistia zvlášť, lebo môžu niesť skript.

Ďalšie opatrenia

• Produkčné nasadenia Modula odpovedajú len na ostrej doméne — technické náhľadové adresy hostingu sú pre produkciu zamknuté.
• Odkaz na obnovu hesla sa skladá z pevnej adresy administrácie, nie z adresy v požiadavke, ktorú by šlo podvrhnúť.
• Prepojenie s Google overuje náhodný parameter state, takže útočník nemôže k vášmu účtu podstrčiť svoje prepojenie.
• Rozhranie portálu Stravník prijíma požiadavky z prehliadača len z vlastných domén Stravníka.

Ako to máme my

• Administrácia Modula: všetky uvedené hlavičky, ochrana CSRF, dve vrstvy čistenia HTML, zámok náhľadových adries.
• Weby postavené na Module: bezpečnostné hlavičky (HSTS, X-Frame-Options, nosniff, Referrer-Policy) pri každej odpovedi.
• Veredar zobrazuje HTML e-maily očistené od skriptov.

Časté otázky

Môže mi niekto poslať e-mail, ktorý po otvorení v Module spustí škodlivý kód?

Obsah e-mailov sa pred zobrazením čistí — skripty, formuláre, vložené rámce a nebezpečné odkazy sa odstránia. Stále však platí bežná opatrnosť pri prílohách a odkazoch od neznámych odosielateľov.

Čo je CSRF a prečo by ma to malo zaujímať?

Útok, pri ktorom cudzia stránka, ktorú máte otvorenú, pošle do Modula požiadavku vaším menom, lebo ste prihlásený. Modulo také požiadavky rozpozná podľa hlavičiek prehliadača a odmietne ich.

Prečo sa Modulo nedá vložiť do inej stránky (iframe)?

Zámerne. Zabraňuje to clickjackingu — triku, keď útočník prekryje Modulo neviditeľnou vrstvou a naláka vás kliknúť tam, kam nechcete.