Vlákno názorů k článku ČSOB podcenila zabezpečení svého webu od Jaromir - " Budete také stát před rozhodnutím, kdy vstupní data...
-
"
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? -
PeTe (neregistrovaný)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..
-
Mirek (neregistrovaný)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... -
gdg (neregistrovaný)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. -
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. -
Maaartin (neregistrovaný)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.
