"
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?
Vlákno názorů k článku
ČSOB podcenila zabezpečení svého webu
aura:35
uživatel si přál zůstat v anonymitě
24. 4. 2008 8:49
Re: SQL Injection
Na výstupu - pro případ, že se někdo vloupal do DB a "upravil" údaje. Na vstupu samozřejmě taky, ale jde o to, nespoléhat se na to, že v DB už jsou data čistá.
aura:35
24. 4. 2008 9:10
Re: SQL Injection
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.
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.
PeTe (neregistrovaný)
24. 4. 2008 10:03
Re: SQL Injection
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..
aura:35
24. 4. 2008 12:23
Vstup a nebo výstup.
"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.
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.
Maaartin (neregistrovaný)
24. 4. 2008 16:49
Re: Vstup a nebo výstup.
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.
Zbyva pak osetreni html - bud na vstupu nebo na vystupu.
Tom (neregistrovaný)
25. 4. 2008 17:53
Ochrana na výstupu ... Re: SQL Injection
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.
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.
Mirek (neregistrovaný)
24. 4. 2008 10:09
Re: SQL Injection
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...
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ý)
24. 4. 2008 10:14
Re: SQL Injection
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.
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.
