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

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?

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.

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ě

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

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.

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 :)

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)))).

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)));
}

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.

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

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

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

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

Buhvi, kolik je tam toho dalsiho.

strip_tags, htmlentities, addslashes ...

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.

Stačí htmlspecialchars()

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

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.

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... :-)

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...

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.

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...

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..

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)

tiez mi pride ze clanok bol zaujimavy, dakujem autorovi

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 :-( )

Smutná nemoc českých novin... :(((

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.

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

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. :-(