Zabezpečení XSS v populárních knihovnách Javascriptu. Mám se stále obávat?

XSS

Žijeme v době rámců, nikoli jazyků. Z toho vyplývá, že programátoři by se měli méně starat o mnoho aspektů vývoje, včetně bezpečnosti. Většina současných backendových frameworků implementuje bezpečnostní moduly, které testují externí specializované firmy a velké společnosti. Proto, klesající povědomí o bezpečnosti může být patrný například mezi mladými programátory, kteří přebírají větší odpovědnost za produkty, zejména pokud jde o práci na volné noze.

Jedním z častých útoků na straně klienta aplikace je XSS (Cross-Site Scripting). Provádí se injektováním spustitelných skriptů na straně klienta do webových aplikací [1] a využívá implementované metody vykreslování HTML nebo Javascript kód hodnotitelé, kteří jej provádějí. XSS je poměrně lukrativní, protože může shromažďovat mnoho různých údajů, včetně souborů cookie relace nebo údajů o uživateli, a může nainstalovat sledovací aplikaci, například keylogger, což je nebezpečné jak pro uživatele, tak pro majitele firem. Někdy jsou prováděny další formy útoku, které umožňují XSS na stránce, jako např. Injekce SQL.

Příklad

Přihlašovací formulář na stránce vykresluje parametr loginName odeslaný v rámci požadavku GET v zadání přihlašovacího jména. Hodnota není zpracována ani na straně serveru, ani na straně klienta aplikace. Při požadavku: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
kód je prováděn a data jsou vystavena

Toto je příklad Odražený útok XSS, kdy jsou skripty injektovány prostřednictvím speciálně připravené adresy URL odeslané oběti a reflektované odpovědí serveru. Další známé populární formy útoků jsou následující:

• Uložený XSS provedené pomocí injektovaných dat uložených na straně serveru, obvykle pomocí formulářů dostupných v aplikaci. Klientská aplikace vykresluje kód, který je uložen například v databázi.
• DOM XSS provede útok XSS bez použití serveru. V další části článku se zaměříme na tuto formu útoku.

Aktuální zranitelnosti v knihovnách React a Vue

U současných verzí React/Vue byly zjištěny dva závažné problémy, které dosud nebyly oficiálně odstraněny. První zranitelnost má stejnou povahu pro každý framework a souvisí s metodami umožňujícími vykreslování surového HTML v rámci šablon: v-html a dangerouslySetInnerHTML, respektive pro Vue a React. V každé dokumentaci [2] jsou čtenáři upozorněni, že při nerozumném používání mohou být uživatelé vystaveni útoku XSS. Pokud nejsou k dispozici žádné jiné možnosti řešení problému, zajistěte, aby byla data filtrováno a unikl. Přestože jsou nebezpečné, neměli byste očekávat, že tyto metody budou opraveny. Používejte je na vlastní nebezpečí.

V prvním čtvrtletí roku 2018 byla v systému React zjištěna rozsáhlá chyba, která umožňovala přímé spuštění kódu nastavením vlastnosti pro prvek tag. Předávání příkladového kódu v rámci atributů, jako např. javascript:alert(1) a spuštěním vykresleného odkazu se kód spustí. Tento problém [4] je stále otevřený a nebyla připravena a sloučena žádná oprava, takže se ujistěte, že je váš kód bezpečný. Příklady navržené v oficiální diskusi naznačují některé způsoby, jak tento problém překonat.

Pokud aktualizace na nejnovější verze není možná, zajistěte, aby vám staré problémy nezpůsobovaly problémy, a to tak, že zajistíte, aby váš kód nebyl vystaven pro:

• dítě uzel vstřikování - React, použití React.createElement [5]
• vykreslování na straně serveru - React/Vue [6]
• Vstřikování CSS [8]

Stále se jedná o Javascript. Stále jde o front-end

Nezapomeňte, že kromě samotných frameworků nebo knihoven má Javascript jako jazyk některé nebezpečné funkce, kterým je třeba se vyhnout nebo je používat s opatrností. Obecně se týkají manipulace s DOM nebo spouštění skriptů. eval() představuje vlajkové funkce tohoto druhu a je velmi nebezpečný, protože přímo vykonává daný řetězcový kód [9]. Při nalezení některé z těchto funkcí se také lépe podívejte na svůj kód:

• document.write
• document.writeln
• (element).innerHTML
• (element).outerHTML
• (element).insertAdjacentHTML

Zde může být při hledání takových zranitelných bodů užitečné použití linterů s vhodně nastavenými pravidly. Existuje také spousta otevřených nebo komerčních analyzátorů kódu, které vám mohou pomoci odhalit bezpečnostní mezery ve vyvíjeném kódu.

Bez ohledu na to, jakou knihovnu/framework si vybereme, musíme mít stále na paměti základní zásady týkající se vývoje front-endu. Za prvé, vždy se ujistěte, že externí kód, který injektujete, pochází z důvěryhodného zdroje. Audit závislosti a vybírejte je s rozmyslem. Některé z nich mohou obsahovat závažné zranitelnosti, které váš kód vystaví nebezpečí, i když je s ním samotným vše v pořádku. Více informací o zabezpečení závislostí si můžete přečíst zde:

https://thecodest.co/blog/security-in-javascript-packages/

Takže... měli byste se stále obávat?

Ano - a všem důrazně doporučuji, aby nikdy nevěřili externím knihovnám ani sami sobě, pokud jde o zabezpečení. Bez ohledu na to, jak bezpečné očekáváte, že váš software bude, vždy se snažte jej co nejvíce otestovat z hlediska běžných forem útoků [10].

1. https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
2. https://vuejs.org/v2/guide/syntax.html#Raw-HTML
3. https://github.com/facebook/react/issues/12441
4. http://danlec.com/blog/xss-via-a-spoofed-react-element
5. https://medium.com/node-security/the-most-common-xss-vulnerability-in-react-js-applications-2bdffbcc1fa0
6. https://github.com/dotboris/vuejs-serverside-template-xss
7. https://frontarm.com/james-k-nelson/how-can-i-use-css-in-js-securely/
8. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#Do_not_ever_use_eval!

Přečtěte si více:

5 chyb, kterých byste se měli vyvarovat při údržbě projektu v PHP

PHP Vývoj. Komponenta Symfony Console - Tipy a triky

Proč potřebujeme Symfony Polyfill (... a proč bychom neměli)