Názory k článku
ČSOB podcenila zabezpečení svého webu

Podle

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

je dobré filtrovat

< > " ' % ; ) ( & + -

< začátek scriptu
> konec scriptu
" a ' řetězce
% "maskování" - záměna znaků
; ukončení příkazu
() začátek a konec funkce
& "maskování" - entity

proč ale + a - ? To má nějakou speciální funkci v Microsoftích produktech?

"
Budete také stát před rozhodnutím, kdy vstupní data filtrovat a opravovat. Můžete to totiž činit již na vstupu nebo na výstupu. Důležité to je i v případě ukládání do databáze, kde lze doporučit variantu filtrace na výstupu - můžete tak totiž předejít i situaci, kdy se někdo vloupá do vašeho SQL serveru a pozmění všechny vaše články.
"

"doporučit variantu filtrace na výstupu"?

Snad na VSTUPU a zároveň, kromě chyb uvedených v článku, tak odfiltrovat i všechny SQL injections, aby se někdo nedostal do databáze.

Kdy výjde článek o SQL Injections?

Tak primárně musí být ochrana dat na vstupu, aby se nikdo nemohl vlopat!

Jestli pak chce někdo ochranu na výstupu, tak samozřejmě může, ale bude mu to nanic, pokud nebude mít ochranu na vstupu a někdo se mu tam přes SQL Injections dostane, vloží do SQL kód své aplikace, která mu nahraje na disk root-kit a pak plně ovládne stroj.

Těch "výstupních" míst je totiž tolik, že všechna je filtrovat je skoro nemožné, a vždy člověku něco ujede, a útočník vám vloží pak něco do nějaké blbosti typu anketa...

A pak už má stroj plně pod kontrolou a dělá si co chce.

Kdepak, a vůbec na co bude dobrá ochrana na výstupu, když databáze bude plná balastu od útočníka?

Mi to připadá jako naprosto scestná myšlenka.

nahodou je to dobra myslenka.. musis zabezpecit data, ktera miri do databaze pred sql injection, ale v databazi pak budes mit klidne i nebezpecne html injection. ale to ti nevadi, kdyz o tom vis. a az teprve pri vystupu budes vsechny data z databaze osetrovat jako nebezpecna. jasne ze se snazis i aby se ti utocnik nemohl dostat do databaze, ale utocnikem muze byt nekdy i byvaly, nebo treba jen nastvany, tvuj vlastni administrator, ktery ma k heslum pristup. ostatne, utok vlastnich zamestnancu je mnohem castejsi, nez ze se nekdo dostane do databaze uplne z venku..

"musis zabezpecit data, ktera miri do databaze"

A to jsem přece psal, a ten kdo na mě reagoval, že je třeba zabezpečit JEN výstup, což je samo o sobě, bez zabezpečení vstupu, nanic.

Jestli se nepletu, tak na osetreni SQL injection staci dusledne pouzivani PreparedStatement-s s parametry, proste nikdy nestrkat vstupni string nikam kde by se mohl chapat jako SQL. Je to rychlejsi nez bastlit query pokazdy znovu jako string, takze to povazuju za samozrejmost.

Zbyva pak osetreni html - bud na vstupu nebo na vystupu.

Nebude to mít vliv na výkonnost systému?

Přeci jen většina systému mnohokrát více data zobrazuje než je prvně pořizuje. Sice se leccos dá nacacheovat, ale zda vše a ve všech aplikacích, to je docela otázka.

Hmm, me ten tvuj odstavec pripada dost scestny. :-)

V pripade XSS je dulezity vystup. Tzn. spravne vypisovat do stranky udaje pres nejakou "upravujici funkci".

DB se vzdy osetruje nasledujicim: Spravne nastaveni prav (minimalizace prav pro daneho uzivatele, zasadne ne root, atp.) a vstupni data.

Uvazuj, ze v kazdem z pripadu osetrujes trochu jine veci, osetrovanim dat pri vkladani do db data utrpi a stejne tak ti muze na vstupu neco proklouznout (kdo nekdy delal "vetsi aplikaci" ten pochopi)...

A balast? Jaky? Html tagy? At jsi jsou. Me to neohrozi...

Stava se, ze nekolik aplikaci sdili stejnou databazi. Vstup z databaze je potom take nutne testovat uplne stejne jako od potencionalniho utocnika.

Kontrola vystupu neni tak uplne od veci. Je to vlastne kontrola vstupu do uzivatelskeho prohlizece nebo nejake sablonovaci knihovny, kde muze dojit take k injection. Povedlo se mi jednou dostat k jinak dobre zabezpecene databazi pres XPath.

Ano s tymto suhlasim. Tiez si myslim ze vo vacsine pripadov je lepsie pouzivat whitelisty ako blacklisty. (Cize povolit len to co je urcite bezpecne, a nie zakazovat zname bezpecnostne hrozby).

No v praxi sa obcas stava, ze to proste nejde. :-(

To je pravda, tak člověk aspoň zakáže špičaté závorky a pár věcí.

Stejně ale, kde to jde jednoduše zavést, že to není z programátorského hlediska složité, tak proč to neudělat.

LOL :), jak se na to dívám

http://ha.ckers.org/xss.html

tak to vidím jednoduše na reg. výraz. Člověk by musel zakázat tolik věcí, a stejně to nebude zdaleka vše. Ten reg. bude rozhodně jednodušší.

Ze zapisniku pentestera ..

var {5:y,2:q,1:z,4:u,3:r,0:w}=”velart”}[0][z+w+r+q](r+q+z+u+y)(123)

([0][’eval’])([{$:’alert(0)’}.$][0])

eval(/alert(1)/[-1])

0..eval(location.hash) ... URL obsahuje kod, ktery se vykona, napr. o #0={};alert(1)

Já pořád, proč mi to nefunguje a on to FF3b5 nebere. Ani Opera. IE6 ano. IE7 tu nemám, tak nevim.

IE7 to taky (velmi pravděpodobně) nebere. V IE6 to spolehlivě projde.

V to je prave to kouzlo. Jsou prohlizece, kde "neco" projde. Mam tu takovou sbirku. Tak pozor, az se budete chlubit dirou, tak uvadejte i browser. ;-)

Vetsinou je to IE5 a IE6 - napriklad takove nepouzivane figle pres css, a i tady jsou rozdily mezi dilci verzi. Takze kdyz uz testujete web, tak bacha i na toto...

Díra nemá s prohlížečem nic společného. Díra tam prostě je, protože dané weby nefiltrují kritické znaky při výstupu - pravděpodobně proto, že si myslí, že menšítko a většítko přece někdo potřebuje hledat.

Prohlížeč je jenom nástroj, který to umožňuje demonstrovat pro ty, kdo k tomu nemají jiné pomůcky. A vůbec nejde o to "ve kterém" prohlížeči to projde nebo neprojde. Chybný filtering tam prostě vůbec nemá být.

Asi si nerozumime.

Chtel jsem tim jen rict, ze
1/ jeden (nejnovejsi) browser nestaci.
2/ kdyz reportuju chybu, tak pripisu i browser a verzi, jinak se casto dockam odpovedi: "me to nic nedela"

Se skodlivosti samozrejme souhlasim.

Reseni je povolit skriptovani jen ze situ, kterym duveruji a ktere opravdu potrebuji. Vetsinou se skripty stejne pouzivaji jen na zobrazovani reklamy. Napriklad pluginem do firefoxu NoScript - tam si muzu selektivne povolit skripty z csob.cz, ale zakazat z pooh.cz.

Tak to jsi teda úplně mimo, tohle je po dlouhé době konečně něco zajímavého, kde nejsou chyby.

jestli neni chyba zamena HTTP POST za HTTP PUT, tak si dam este jeden obed.

Buhvi, kolik je tam toho dalsiho.

Tak v tom se nevyznám, řekni kde, ať to opraví.

Mě se článek líbí, protože je to konečně zase něco odborného a ne ty obvyklé slátaniny.

Asi v polovine clanku:
"U formulářových prvků se nenechte zmást rozdílem mezi HTTP GET a HTTP PUT. Je uplně jedno, kudy se informace z formuláře předávají (parametry URI vs. součást HTTP komunikace). Není vůbec problém si vlastní upravený formulář připravit na lokálním disku a pracovat s ním."

Metody POST a PUT jsou dost odlisne; autor mel pravdepodobne na mysli POST (pouziva se pro odesilani formularovych dat etc.), nebot PUT se na webovych strankach prakticky nevyuziva.

RFC 2616 (HTTP/1.1) dokonce primo hovori o rozdilu mezi POST a PUT (sekce 9.6, odstavec 3).


Jinak clanek dobry, uvidime, jak bude (bude-li vubec) CSOB reagovat

Měl, moje chyba. A to jsem se to večer po deváte snažil přečíst několikrát a stejně mi to uteklo.

Já tedy nevím, ale to jste to moc nevylepšíl, teď tam pro změnu máte HTTP POST a HTTP PUT, oproti zřejmě zamýšlenému HTTP POST a HTTP GET :)

... je to zkratka odbornik, jak ma byt ...

Taky jsi to mohl rovnou vložit

"
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
If the server desires that the request be applied to a different URI,
it MUST send a 301 (Moved Permanently) response; the user agent MAY
then make its own decision regarding whether or not to redirect the
request.
"

Ja mam presne opacny nazor - clanok je velmi dobry, ale zle zvoleny nazov. (Ak ho budem niekedy v buducnosti hladat, koli nejakym informaciam, urcite ho podla nadpisu v mojej historii precitanych clankov preskocim :-( )

tiez mi pride ze clanok bol zaujimavy, dakujem autorovi

Hmm, fakt to trochu zavani tim, ze autor nejdriv napsal pojednani o XSS a pak hledal diry a nasledne zvolil titulek.

Ale to nic nesnizuje na faktu, ze je treba v tomhle delat osvetu a vedet o XSS je nutnost nejen pro programatora, ale i cloveka, starajiciho se o danou sluzbu po produktove strance!
Prave takovy ten pristup "aha, vy jste zmenil logo, pekne a co?", je dost "oblibeny" a deprimujici.

A jako uvodni obecny clanek to bylo velmi dobre - dobra osnova i obsah. Nektere body bych mozna vic zduraznil a par veci pridal... :-)

Vzhledem k tomu, že autor díru o které je řeč reportoval už včera na svém blogu, tak je ten postup přesně opačný.

Objevena chyba, oznámena ČSOB, zveřejněna,

Aleš Miklík poprosil o článek, já namítal že článek jenom o jednom děravém webu je málo,

nakonec z toho vznikl tenhle dlouhý článek o principech a ochraně.

Následně jsem se ještě po dopsání šel podívat na pár dalších webů, vznikl poslední odstavec s praktickými příklady.

Titulek a perex je dílem redakce, nemám s ním problém a odsouhlasil jsem jej.

Tohle je podle mého dost dobrý článek od člověka, který ví o čem píše.

náhodou, narozdíl od různých zpráviček, glos a článků o "webu 2.0" je tohle jeden z mála dobrých článků na lupě

XSS se nedostane ani do ASP, ani do PHP, ani do žádné skriptovacího jazyka na straně serveru. XSS je čistě klientská strana, serverové věci to ovlivnit neumí. Takže lze jenom těžko uvažovat o nějakých nenávistných článcích.

Doporučuji www.google.com, tam stačí najít URI se soubory .asp. Bude to asi překvapení, ale ASP se stále běžně používá. A není důvod ho nepoužívat. Ne každý má důvod měnit existující redakční systémy na .NET

A co takto spomenut niektory z HTML filtrov(PHP tried) specializovanych priamo na tento ucel?
Napr.: HTMLPurifier(http://htmlpurifier.org/), kses, ...

Stačí htmlspecialchars()

strip_tags, htmlentities, addslashes ...

Neboli addslashes při vstupu do DB (ale na základě get_magic_quotes_gpc()!) a htmlspecialchars při výstupu.

ako vzdy, nic nove, nic zaujimave, ale budiz. samozrejme ako vzdy trosku pomylene. podla autora je chranit sa pred xss lahke a potom da linky na x stranok, ktore ponukaju varianty desiatok kombinacii, ktore z lahkeho robia nocnu moru. velmi zaujimavy pristup. kazdopadne, uzivatel sa moze branit velmi efektivne a vobec nie, ako napisal autor, vobec. ale uz som si zvykol ze rad robi bubu na kazdu stranu, aby to vyvolalo zaujem o jeho clanok. uzivatelia firefoxu mozu (a mali by) pouizvat vyborny noscript od autora Giorgio Maone. ostatne prehliadace podobne rozsirenie nemaju a asi tak skoro mat nebudu. co sa tyka ochrany na strane serveru, existuje hned niekolko rieseni, na technologiu php je to fantasticky php-ids. viac sa samozrejme mozete docitat na centrale webovej bezpecnosti OWASP kde najdete aj mnozstvo inych informacii o dalsich bezpecnostnych chybach a samozrejme mnozstvo softveru, ktory mozete pouzit na testovanie.

Hrozně nerad bych řekl něco hloupého, ale pokud je podle autora tak jednoduché vstupy proti injekcím a cross-site scriptingu ošetřit, čím to, že už dávno neexistuje nějaká všeobecně známá JEDNA super-univerzální funkce, kterou by všichni používali? Tak nějak laicky se mi zdá, že kdyby skutečně existovalo nějaké naprosto neprůstřelné řešení, už dávno by všichni měli na svých webech definovanou příslušnou funkci
function OsetriVstup()
která by prostě sama od sebe vzala $_POST, $_GET, $_REQUEST atd. a nějak to "pořešila".

V diskuzi také několikrát zaznělo, že je třeba provádět ošetření jak na vstupu, tak na výstupu (z databáze), pro případ, že někdo DB nabořil. Jenže se obávám, že by pak sotva šlo udělat redakční systém, který by adminům umožnil například do nějakých zpráviček/aktualit vložit odkazy nebo IFRAME.

Domnívám se, že přístup "Nikdy nikomu nevěř" nelze používat; ti, komu nelze věřit, jsou návštěvníci webu z řad běžných surfařů, ale někomu člověk věřit musí. Jinak by každá firma musela mít na každého programátora dva další kontrolory, kteří by kontrolovali, jaký kód programátor na web nahrává, každý admin databáze by musel mít nad sebou dva kontrolory, kteří by kontrolovali jeho zásahy... A nad těmi kontrolory by museli být další kontroloři, kteří by hlídali, zda náhodou někdo ty dva "dolní kontrolory" nepodplatil, aby tam nepropašovali něco škodlivého. Tohle už je paranoia.

No muzete mit zajistene, co chcete, ale podavat trestni oznameni v pripade, ze utok prisel z nejake zajimave africke ci asijske zeme asi nema moc smysl. Predpokladam, ze kdokoliv soudny, kdyz by Vam chcel skodit, pujde urcite pres statni hranice, nejlip jeste vice skoky pres exoticke zeme.

Data budou fuc, web zemneny, firma ma z ostudy kabat a utocnik je prakticky nedohledatelny. Myslite, ze T.O. ma pak cenu?

Pokud staci prosty text bez HTML, takove funkce jsou standardne snad ve vsech HTML-generujicich jazycich (a pokdu ne, neni problem je napsat, treba regularnimy vyrazy). Problem nastane v okamziku, kdy "hodne" HTML musi zustat nedotceno, zatimco "zle" HTML s moznym XSS musi byt zruseno, pozrano, prevedono na entity ci jinak osetreno. To uz problem je, obzvlast kdyz musi vstup zpracovat i takove hruzy jako HTML generovane z MS Office.

BTW: Onu funkce na osetreni vstupu v prvnim pripade neni problem udelat, napr. v onom PHP staci tohle (pisu to z pameti, tak doufam, ze je to dobre):

foreach($_REQUEST as $name => $value)
{
$_REQUEST[$name]=htmlspecialchars(strip_tags(stripslashes($value)));
}

No jo, jako obvykle. Všichni jsou chytří jako rádio, ale ve skutečnosti nikdo nepřemýšlí nad tím, co píše.
Ten článek je sám o sobě dobrý. To, že obsahuje chyby nic nemění na tom, že autor webu ČSOB je packal, který nevěnuje bezpečnosti žádnou pozornost. A také to nemění nic na tom, že bezpečnost tu je pro všechny pouze prázdný pojem.
Ale teď k meritu věci (bohužel mírně nudnému meritu):
Jsou jisté bezpečnostní zásady, které je vhodné ctít.
(1) Všechny funkčnosti, které má stránka provádět, definujte jako povolené a zakažte vše ostatní (tedy postupujte dle zásady Deny all, allow only functions to be provided). Je lepší obsloužit pětset povolených věcí (vyjímek), než vymýšlet kontroly na celý vesmír možných hackerských kousků.
(2) Vstupní data kontrolujte kolikrát to půjde (ve formuláři, na vstupu do aplikace, před zápisem do databáze... Čím víc kontrol uděláte, tím větší množství útoků můžete zastínit.
(3) Databázi obsluhujte co nejvíc parametricky (pokud to jazyk a databáze umí). Nemusíte si potom lámat hlavu s kontrolou vstupních řetězců a používat různá udělátka od tvůrců enginu.
(4) Kontrolujte nejen vstup, ale i výstup. Věci, které evidentně do HTML stremu nepatří odfiltrujte. Aplikaci navrhněte tak, aby nebezpečné věci (skripty, CSS) šly ze snadno kontrolovatelných zdrojů.
(5) Zakažte HTML v uživatelsky definovaných datových polích.

To je tak asi všechno, co mne napadá.
Tak, a teď mi můžete začít nadávat :o)), jaký jsem břídil :o)))).

Jsi bridil ;-) Spokojeny? ;-)

Posledni dobou zacinam mit pocit, ze programatori obecne vymreli a existuji uz jen lepici kodu. Sam se za programatora nepovazuju ale co obcas vidim ve vsemoznych aplikacich ...

Nejde zdaleka jen o web, vstupy se obecne temer neosetrujou takze nemusi jit ani o umyslne naboreni, aplikaci sejme casto vpohode i uzivatel, ktery tam proste neco cpy&paste.

BTW: Vyjadreni bank k bezpecnosti je vzdycky stejne. Onehda sem pri loginu zjistil, ze jejich certifikat expiroval. Zavolal sem tam, a nejaka kravka si nechala vsechno vysvetlit, a ve finale mi rekla "tak zmacknete OK". Na treti pokus sem dostal asi nekoho znalejsiho, chvili ze me delal debila, ale vysledek se kupodivu dostavil, za 1/2 hodky byl certifikat vymenen. Pro zajemce o "bezpecnou" banku, slo o Komercku.

veľmi šikovná vec http://www.securitycompass.com/exploitme.shtml
viac info tu:
http://blackhole.sk/exploit-me-nastroje-na-testovanie-bezpecnosti-webov-xss-sql-inject