Komentáře k článku

Co je Cross-site scripting jak mu předcházet

XSS neboli Cross-Site Scripting je jedna z nejstarších zranitelností webových aplikací. A protože jí stále mnoho webů, resp. webových aplikací trpí a většina uživatelů má JavaScript zapnutý, ukážeme si jednoduché příklady, jak zranitelnost vzniká a jak se jí bránit. Článek je věnován zejména těm, kdo o XSS zatím pořádně neslyšeli.

Zpět na článek

54 komentářů k článku Co je Cross-site scripting jak mu předcházet:

  1. danaketh

    RE: Co je Cross-site scripting jak mu předcházet
    Zrovna GET řeším tím, že z něj odstraním vše, o čem vím že nemůže nikdy obsahovat. Třeba v případě odkazu na článek vím, že nebude nikdy obsahovat špičaté závorky, apostrofy, uvozovky, lomítka, středníky… takže je v klidu smažu.

    Stejně tak by se mělo vždycky provádět ošetření na straně serveru, protože JavaScript lze snadno potlačit (no, zrovna tím NoScriptem). Ideálně všechno posílat přes POST a GET používat jen tam, kde přesně víme co z něj může přijít.

    1. Keson

      RE: Co je Cross-site scripting jak mu předcházet
      Obecně lepší přístup, než odstraňovat určité špatné znaky, je akceptovat pouze povolené.
      Na straně klienta se data kontrolovat mohou, na straně serveru musí. Jinak se nedá o bezpečnosti vůbec mluvit.
      Z hlediska bezpečnosti (korektnosti vstupu) je úplně jedno, jestli použijete POST, GET, nebo jinou metodu. GET má zřejmou (ne)výhodu, že se dá zazáložkovat.

      1. benzin

        RE: Co je Cross-site scripting jak mu předcházet
        Ano, pri pouzivani GET je URL adresa vzdy odpovidajici obsahu stranky a tak to ma na webu byt.

  2. dan

    str_replace
    Autor asi nikdy neslysel o htmlspecialchars()… a ze by se to melo volat minimalne kvuli spravnemu zapisovani < > " a & do html pri kazdem vypisu

      1. dan

        Re: str_replace
        Cetl a proto me zarazi ze autor nedokaze jednoduse napsat ze VSE CO SE VYPISUJE musi jit pres htmlspecialchars() *. A v pripade ze to je jeste hodnota do JS, tak napr. addslashes(), ktera vyresi ' a .

        Namisto toho resi ruzne replace blbosti jako ten nejvetsi amater co nahodou zjistil ze to mensitko a vetsitko bude asi nebezpecne a to jen diky tomu ze mu nejaka dalsi osoba ukazala specialni odkaz jak exploitnout jeho stranky. Takze se snazi resit JEDEN konkretni pripad, ne problem jako celek, ze pise kod jako prase.

        Bohuzel se s timto pristupem setkavam casto a namisto SLUSNEHO programovani ti pisalci resi ruznymi obezlickami konkretni problemy az nastanou. A uplne to same plati o SQL injection a taky o shellu, v pripade PHP je hruzny priklad i v komentarich zde http://cz.php.net/manual/en/function.rmdir.php :

        function removeDir( $dir ) {
        if (strtoupper(substr(PHP_OS, 0, 3)) == 'WIN') {
        exec( "rd /s $dir" );
        } else {
        exec( "rm -rf $dir" )
        }
        }

        Proc tam sakra neni escapeshellarg() ? Vsak az to nekomu smaze server tak ho tam priste da.. mozna, ze?

        Pak to skonci bohuzel s tim ze 95% autoru budou psat jak prasata a musi se zavest az takove zmeny jako magic-quotes-gpc aby se neposkodila povest programovaciho jazyka samotneho. Nastesti to je uz deprecated feature.. portovatelny kod ale s tim musi pocitat a jakykoliv zdrojak ktery obsahuje

        echo $_GET['promenna']

        me rika ze autor si problematiky neni znam. A pokud se to objevi v clanku o bezpecnosti, bezpecnosti PHP, tak je to k smichu. Pokud je magic-quotes-gpc defaultne ON, tak na tento kod z clanku:

        'Odeslaná hodnota je: <?php echo $_GET['test']; ?>';

        exploit z clanku:

        '; alert("XSS"); value = 'není tu nic

        fungovat nebude. magic-quotes-gpc mu ty apostrofy zmeni na ' jeste pred spustenim skriptu. Ale nikde zminka o tom ze by pan pouzival super nove php nebo nejake s upravenou (nedefaultni) konfiguraci neni.

        A to jeste ke vsemu dela na takove pozici, ach jo.

        *) Nemusi kdyz to je primo vysledek (interni) funkce vracejici cislo nebo pretypovani. Jinak ten kod muze byt explotnutelny kdyz se zmeni format vystupu uzivatelske funkce.

        1. Hoween

          Re: str_replace
          Chcete kvalitní články? Nečtěte Zdroják. Bastličů, kteří píší články a armáda jiných bastličů jim v komentářích děkuje, tady bohužel přibývá. A když se člověk proti článku ohradí, tak se na něj všichni, často včetně šéfredaktora, sesypou.

          Ale je nutné na to upozornit a absolutně s vámi souhlasím. Bezpečnost aplikace začíná od jejího celkového návrhu, nikoli dolepováním patchů řešících konkrétní problémy. Vezměte si analogii Win vs. Linux. Zatímco Linux má bezpečnost řešenou od začátku, a je s ním mnohem méně problémů, u Win se na bezpečnost kašle a lepí se konkrétní chyby, které někdo najde. Že je správně ten první případ, víme oba. Proč to neví redaktoři a tohle pustí ven, je věc druhá.

          1. Miroslav Juhos

            Re: str_replace
            Zřejmě se na vás všichni sesypou kvůli onomu výstřednímu způsobu jakým svoje názory podáváte.

            Koneckonců, budete-li chtít přispět článkem, který bude demonstrovat vaše představy o kvalitě článků na Zdrojáku a který nastaví laťku i ostatním článkům, dá se předpokládat, že pan šéfredaktor se bránit nebude.

          2. SFS

            Re: str_replace
            Jak ma podle vas Linux resenou bezpecnost v porovnani s Windows, aby bylo mozno napsat, ze je by-design imunni vuci programatorskym chybam napr. v kernelu ?

            1. Hoween

              Re: str_replace
              Linux má bezpečnost řešenou tak, že za celou dobu jeho existence na něj vzniklo cca 30 virů. Windows mají bezpečnost řešenou tak, že na ně existuje virů víc než 200 tisíc.

              Co do toho pletete nějaký by-design a kernel? Jde o koncepci návrhu.

              1. SFS

                Re: str_replace
                Zkuste BeOS – pro nej nejsou viry vubec zadne ;-) Nejde o kvantitu – tech 200 tisic viru pro Windows opakovane vyuziva stejne techniky (az na par objevnych vyjimek). Takze zranitelnost vedouci k napsani byt jedineho viru (a vy jich zminujete pro Linux hned tricet ;-) muze snadno vyustit v ty tisice, pokud to bude pro danou platformu zajimave vyvijet.

            2. dan

              Re: str_replace
              Odpoved konkretne na vasi otazku je "protoze je opensource" :)

              Ale autor prispevku vyse mel na mysli to:

              – ze linux nikdy nemel nechraneny rezim
              (jako win az po ME)

              – ze linux neposkytuje roota pro beznou praci usera po instalaci
              (zatimco ve win ma uzivatel nejdrive admin prava, kterych se musi aktivne zbavit)

              – ze linux vzdy pouzival pristupova prava (minimalne rwx), a ACL snad umi vsechny FS
              (zatimco ve win casto mate fat, fat32, … vse bez pristupovych prav)

              – linux je napsan portovatelne a jeho ruzne varianty (i v ramci jedne architektury – staci prekompilovat s jinou urovni optimalizace) zpusobuji ze vyuzit nejaky remote/local buffer overflow je o nekolik radu tezsi.
              (naproti tomu ve windows mate jednu a tu samou binarku pro kazdeho.. to se pak exploituje ;)

              A urcite se najde spousta dalsich vlastnosti PROC tomu tak je.

              Rekl bych ze existuji stastni uzivatele Linuxu a nestastni Windowsaci co nam to zavidi a vyvolavaji flamewar :)

              PS. Windows je lepsi – ale bohuzel jen marketingove/obchodne. Co se tyce technickych kvalit, tak tam opravdu zaostava. A to jsou dva nesrovnatelne aspekty, takze to prosim neplest.

              1. SFS

                Re: str_replace
                – Mluvme o systemu nad NT architekturou a nikoliv win9x.
                – NTFS je jako nativni uz od prvnich verzi a nabizi vse, co potrebujete.
                – Zkuste si nekdy nainstalovat XP – budete prekvapen, ze hned pri instalaci vytvorite krome roota i non-privileged uzivatele a pod nim vam take system nabidne defaultne se prihlasit. Ze se pak kazdy hlasi pod adminem je vec jina – problem se spatne napsanymi aplikacemi je bohuzel dost rozdireny – ale v Linuxu je to nanestesti casto totez – napr. KINO z distribuce Mandrivy 2009.0 se odmitne dohodnout s DV kamerou pres 1394 – ze nelze otevrit /dev/raw1394 – proc ? Zarizeni nefunuje/nejde nainicializovat, jiny problem ? Zoufaly uzivatel po hodine badani zjisti, ze autor aplikace jaksi zapomel osetrit access denied k /dev/raw1394, aplikace reaguje hlaskou "unable to open..", takze sudo chmod vec resi ;-)

                Btw pouzivam Windows (ktere znam, troufam si rici, lepe nez lecktery vyvojar od Microsoftu), pouzivam Linux pro cross-platform development (stejne jako MacOSX) a nevidim nejaky zasadni rozdil (minimalne v navrhu systemu – a ten byl v puvodnim prispevku zminovan).

                1. dan

                  Re: str_replace
                  – existovali i jina win, nez se nezjistilo ze nejsou pouzitelna v moderni sitove dobe. Ale pokud zacneme u NT.. myslite ty NT, kde mel administrator prazdne heslo ? :) (win2000). Nj, byla to srandovni doba kdyz jsme museli userum na kolejni siti vysvetlovat ze to heslo tam je fakt potreba.

                  – existoval i FAT.. a nebyt tech velkych disku a omezujiciho limitu 4G na soubor tak se zrejme porad pouziva. Pozadavek na NTFS totiz Windows pro svuj beh nemaji, porad tvrdite ze je to tak spravne? Proc si myslite ze XP na ntfs ty prava vyuzivaji pokud xpckam na FAT32 evidentne neschazi?.

                  – ano o tom mluvim: ucet vytvoreny pruvodcem pri/po instalaci ma doopravdy administratorska prava, lisi se jen nazvem/loginem a tim ze se objevi na welcome obrazovce (nevim proc si mylne myslite ze ty prava nemaji – zdani klame)

                  – ohledne /dev/raw1394: je to problem distribuce a nastaveni udev rules a skupinovych prav. Resil jsem podobny problem s jinym hotplug hw – stacilo nahlasit a oprava byla na svete: http://bugs.gentoo.org/208578 . Kde lze podobne precizne nastavit prava ve windowsech k zarizenim? Bud je maji vsichni anebo je ma jen root a pak uzivatele pouzivaji admin ucet

                  – v navrhu systemu rozdil neni? Defaultni nastaveni nepatri do navrhu?

                  1. n0

                    Re: str_replace
                    k tomu heslu: jak to souvisí s debatou kolem návrhu win/nix?

                    A k tomu FATku bych dodal, že existují stanice, které nejsou připojeny k netu (a nemají USB) :)) a jsou používány jen jedním uživatelem, zato inteligentním? Potřebuje NTFS když si na tom bude přehrávat mp3jky < jak 4GB? :]

                    BTW ty trosky tam dostane přes CD-ROM ;p

                  2. blek džek

                    Re: str_replace
                    Godwinův zákon: Pravděpodobnost, že v diskusi na Rootu se téma stočí k boji Linux vs. Windows, se s růstem délky diskuse blíží jedničce.
                    :-))

                2. Anonym

                  Re: str_replace
                  takze sudo chmod vec resi ;-)

                  ne neresi
                  1. mandriva nepouziva sudo
                  2. chmod neresi (respektive vyresi to na chvili)
                  3. na chvili dokud se nespusti msec, ktery to vrati dle svych zaznamu zpet.

                  takze chmod + rekonfigurace prislusneho zaznamu v msec configu :-D

                  4. a to je duvod mimo jine take divod proc se blbe pisi viry a podobna havet pro linux.

                  na nic se tam nemuzete spolehnout klidne i v kernelu to muze byt vsecko jinak :-)

                  treba bsd kernel + debian gnu + LFS apps – to ze to snad nikdo nevidel neznamena ze to nekdo neprovozuje :-)

                  1. Anonym

                    Re: str_replace
                    Jenže vy se na to díváte ze špatného pohledu – to, co jste napsal, platí bezezbytku pro autory dejme tomu multiplatformního konfiguračního softwaru, kteří to, že jim to nechodí na třetině počítačů, musí řešit jako problém. Autora virů tohle ale naprosto nezajímá, on má 66 % počítačů, které nakazit může, což je pro něj dobrá zpráva. Navíc si myslím, že pokud by jednou Linux měl nějaký významnější podíl, bude to spíš tak, že jedna distribuce bude mít 30 % a druhá 20, než že sto distribucí bude mít procento (kdy by se dalo mluvit o diverzitě).

          3. Kuchař

            Re: str_replace
            Nevím proč, ale připomínáte mi toho kuchaře co teď běží na Primě, jak všechny vždycky pěkně zjebe :-)

        2. Jan PejšaAutor příspěvku

          Re: str_replace
          Nebudu odpovídat na všechno, ale na něco přece jenom.

          Článek je určen pro začátečníky a chtěl jsem ukázat "kde přesně XSS může vzniknout" a "jak se mu obecně bránit". Proto jsem také použil jednoduché funkce na "nahrazování řetězců".

          Proč článek pro začátečníky či pro ty, kteří o XSS sice slyšeli, ale neví jak se bránit? Protože stále mnoho webů či webových aplikací trpí touto "banalitou". Ošetření je totiž, jak všichni víme, velmi jednoduché.

          To že je XSS stále aktuální zranitelností (a již po mnoho let) dokazují například tyto odkazy:
          * http://www.owasp.org/index.php/OWASP_Top_Ten_Project (2004, 2007)
          * http://cwe.mitre.org/top25/ (2009)

          K Magic Quotes asi jen toto – ano, mohl jsem zmínit že je považuji za vypnuté, nechtěl jsem ale dělat popis nastavení PHPka. Navíc: "This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged." (viz. http://cz2.php.net/magic_quotes)

          1. Hoween

            Re: str_replace
            Jistě. Naservírujeme začátečníkovi XY způsobů jak patchnout to či ono, když nemá žádný teoretický základ a naučíme ho tak prasit své aplikace (jak je tomu u většiny PHP programátorů zvykem). První věc, kterou měl váš článek, nebo nedejbože seriál článků začít, je právě to, že popíšete konfiguraci PHP a jak které volby mohou ovlivňovat zabezpečení. To, že vy považujete magic_quotes za vypnuté (ano, já si je také nechávám všude vypnout), ještě neznamená, že na ostatních hostinzích jsou také vypnuté.

              1. Hoween

                Re: str_replace
                Pro mě to problém není, pro autora to zřejmě problém je.

                Znovu opakuji, že celému článku měl předcházet popis konfiguračních možností PHP, které takové věci mohou ovlivňovat.

                1. Martin

                  Re: str_replace
                  O čem je článek? O PHP nebo o XSS? PHP byl zvolen jako demonstrační jazyk. Mě zaujalo, jaké jsou techniky XSS, ne jak se v PHP řeší. Autorovi + Vám -!

                  1. Hoween

                    Re: str_replace
                    Článek je evidentně o XSS v PHP. Kdyby nebylo zvoleno PHP jako nástroj, a řešilo se čistě XSS, neřekl bych půl slova. Ale takhle je to XSS včetně PHP, a to PHP je tam hodně, hodně špatné.

                    To sem vážně chodí samé nuly, co nad každým článkem slintají blahem a nevidí ty hromady chyb?

              2. jar

                Re: str_replace
                Často je na hostingu starší verze PHP, často nemáme vliv na to, jestli magic je nebo není, takže:

                <?php
                function gpc_addslashes($str) { return (get_magic_quotes_gpc() ? $str : addslashes($str)); }>
                ?>

                Zdroj: http://php.vrana.cz/obrana-proti-sql-injection.php

                K escapování šířenji: http://php.vrana.cz/escapovani.php

                http://php.vrana.cz/ vůbec celkově stojí za pečlivou pozornost.

                Jinak za článek díky. Jako upozornění na problém je rozhodně přínosný.

                1. Hoween

                  Re: str_replace
                  Nic proti, ale argumenty typu "často je …".
                  Vždycky mám možnost volby, a vždycky mám možnost se s hostingem dohodnout. Pokud je web na staré verzi PHP, domluvím si migraci na něco novějšího. Pokud je nevyhovující konfigurace, domluvím si její změnu (nebo to rovnou přes .htaccess udělám sám). Pokud mi hostér z nějakého důvodu nechce vyhovět, jdu jinam. Vždycky zvažuju, jestli mám nevhodnou konfiguraci webhostera obcházet podobnými obezličkami, nebo jestli je jednodušší se zařídit jinak. Když mě totiž situace dotlačí do jedné obezličky, můžu jich za chvíli mít celou knihovnu. Jen proto, že někdo má špatně nastavené PHP.

                  Ad. přínosnost článku – Vy jste doteď o XSS, HTML injection apod. nevěděl? A to vážně programujete?

        3. Ped

          Re: str_replace
          Ale to neni clanek o tom jak zabranit XSS v PHP, je to obecne o principech XSS utoku a o tom jak se jim branit. V PHP existuje prijemna funkce htmlspecialchars, ale v jinem jazyku jeho ekvivalent byt nemusi a pak muze ke slovu prijit i str_replace.
          To same plati o magic-quotes-gpc, nema vyznam to resit v clanku kde o PHP ani poradne nejde, a je tam ciste jen pro ilustraci.

          Ze to podle toho nejaky lepic kodu naboucha do sve "aplikace" a bude si myslet jak na XSS vyzral je jiny problem, ale proti tomu obrany neni, lepici kodu se v prvni rade nikdy k "programovani" nemeli dostat.

          1. Hoween

            Re: str_replace
            Bohužel, podobné články jim v tom lepení hodně zvyšují sebevědomí.

            Chybí jakákoli výuka teorie, všichni hned "programují" a pak je to hodně vidět.

  3. David Grudl

    Chyba v escapování pro JavaScript
    Popis escapování pro JavaScript obsahuje faktickou chybu. Naprosto stačí ochránit uvozovky, není potřeba, přesněji řečeno je kontraproduktivní, nahrazovat znaky < a >. Dále by mělo být zmíněno, že k ochraně uvozovek se používá jiný postup, než je používaný ve zbytku článku (tj. nenahrazuje se za entity, ale přidává se lomítko). Nejlépe asi použít json_encode(), s tím, že tato funkce sama vloží uvozovky, tj. uvozovky pak nebudou součástí JavaScriptové šablony.

    1. Jan PejšaAutor příspěvku

      Re: Chyba v escapování pro JavaScript

      Přesně tohle jsem ještě včera večer řešil s Martinem Hassmanem – bohužel jsme se neshodli. (a teď koukám že z článku nakonec vypadl příklad):


      var value = 'Odeslaná hodnota je: <?php echo str_replace("'", "'", $_get['test']); ?>';

      který je ještě potřeba rozšířit na následující (aby byla ochrana řádná):


      <?php echo str_replace("</script", "</scr' + 'ipt", str_replace("'", "'", $_GET['test'])); ?>

      tato ochrana je tu kvůli tomuto uživatelskému vstupu: </script><script>alert(„XSS“)</script>

      1. David Grudl

        Re: Chyba v escapování pro JavaScript
        Tam naprosto stačí nahradit / za /.

        Rozšíření "řádné" není, co třeba </script><script>alert("XSS")</script>

        1. David Grudl

          Re: Chyba v escapování pro JavaScript
          Redakční systém mi trošku upravil obsah, mělo tam být </ SCRipt> …

        2. Jan PejšaAutor příspěvku

          Re: Chyba v escapování pro JavaScript
          myslel jsem tím, aby uživatel ve výsledku dostal to co zadal – tj. žádná změna

          řetězec "/" se totiž od řetězce "/" liší

          1. Jakub Vrána

            Re: Chyba v escapování pro JavaScript
            Nikoliv, je to ten stejný řetězec. JavaScript totiž znaky za kromě vyjmenovaných výjimek interpretuje jako ten samý znak.

            A formálně vzato je blok JavaScriptu ukončen posloupností </, takže kdyby se nepoužilo zpětné lomítko, bylo by lepší nahradit všechny '</' za '<' + '/'.

  4. David Grudl

    Ošetření znaku &
    Ještě mě upozornil Jakub Vrána, což jsem úplně přehlédl, neb takový bug bych nečekal, v článku chybí ošetření znaku &, namísto zbytečného ošetřování >

    1. Jan PejšaAutor příspěvku

      Re: Ošetření znaku &
      Konečně na tu nejzávažnější chybu někdo přišel! A abych to objasnil i případným dalším čtenářům diskuse: náhrada znaku & za jeho HTML entitu je stejně důležitá jako náhrada "zobáků".

      Příklad, který ukazuje, co jde s neošetřeným ampersandem dělat: http://examples.pejsa.info/ampersand.html

      1. Hoween

        Re: Ošetření znaku &
        Konečně někdo přišel na to, co tvrdím od začátku? Že je ten článek k ničemu? Chcete mi tvrdit, že kdyby na to nikdo nepřišel, tak tam tu chybu prostě necháte ostatním čtenářům.

        Nu vot, eto novinařina.

    2. Jan PejšaAutor příspěvku

      Re: Ošetření znaku &
      …NEnahrazování znaku & za HTML entitu není nebezpečné (jinými slovy je bezpečné, může se vynechat)

      na žádný uvedený příklad (samozřejmě vždy s navrhovanou opravou) se nedá zaútočit pomocí ampersandu

      chyba to sice je, ale jen v použitelnosti, protože uživatel na základě různých vstupů může dostat stejný výstup

      1. Jakub Vrána

        Re: Ošetření znaku &
        Chyba není v tom, že dva různé vstupy vrátí stejný výstup. Chyba spočívá v tom, že se uživateli zobrazí něco jiného než zadal.

        E-mailem jsem reagoval pouze na implementaci funkce zobraz (nezmiňoval jsi ji, ale já jsem se o ní včera bavil s Davidem Grudlem, tak jsem tak nějak předpokládal, že jsi na konverzaci navázal). Při samotném výpisu do HTML se za určitých okolností může jednat i o bezpečnostní chybu – vznikne totiž nevalidní dokument, takže pokud se pošle s typem application/xhtml+xml, tak se např. ve Firefoxu a Opeře vůbec nezobrazí. Tvůj článek sice pracuje s HTML, ale vzhledem k rozšířenosti XHTML by na to měl pamatovat.

  5. Standa

    RE: Co je Cross-site scripting jak mu předcházet
    Tady se jasně ukazuje, jak je programování webových aplikací na pytel. Místo abych se soustředil na problém, řeším jak odescapovat vstupy v javascriptu.

    1. Jan PejšaAutor příspěvku

      RE: Co je Cross-site scripting jak mu předcházet
      > programování webových aplikací je na pytel

      nesouhlasím: záleží na tom, jestli k tomu člověk používá nějaký pokročilý framework s GUI prvky či nikoliv

    2. Hoween

      RE: Co je Cross-site scripting jak mu předcházet
      Programování webových aplikací není na pytel. Na pytel je, že dneska všichni rovnou "programují" a lepí, místo aby začali od nějakého návrhu a teorie.

    3. karf

      RE: Co je Cross-site scripting jak mu předcházet
      Ošetřovaní vstupů a výstupů snad není specifikem webových aplikací :)

  6. Ash

    Jak bastlit pseudoochranu uživatelských vstupů.
    Jak bastlit pseudoochranu uživatelských vstupů. Chápu že to je pro začátečníky, ale nebylo by lepší jasně oddělit demonstrační část "toto lidé dělají a takto to může dopadnout", a část kde se ukáže jak se to dělá pořádně? Nějak se to smíchalo a sice začátečníkovi ukážete, v čem může být problém, ale už ne to, jak tomu jednoduše předcházet :(

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=2922