Oficiální představení SQL Serveru 2008 bez finální verze

By ma zaujimalo, kto hovori, ze SQL server (2005) nie je bezpecny, stabilny a rychly. Pretoze ja o ziadnych bezpecnostnych problemoch neviem, stabilita je podla mna uz teraz velmi velmi dobra. A rychlost je podla mna viac menej vzdy otazkou navrhnu databazy ako vykonom enginu. Aj ked zrychleniam sa urcite nebranim.

Jeste nikdy jsem takto nereagoval na nejakou novinku nebo clanek, ale tohle mi neda Proboha vymazte z te novinky ty nesmysly s sql injection a komentare pana Sedlaka. Je to opravdu sila !

Jen tak na okraj. SQL-injection je opravdu chyba programatora. Na druhou stranu je to i chyba SQL databazi obecne (by design). Obecne by se dalo povazovat za zvyseni bezpecnosti (zpetne nekompatibilni), kdyby API nedovolilo mit zadne hodnoty nastavene v query stringu (exception), ale opravdu by se museli nastavit zvlast. Neni to na 100%, ale vetsinu lidi by to odradilo od spojovani retezcu v dotazech. Ale verim, ze jsou i lide schopni napsat "select from " + tableName + " where "... na takove nepomuze nic.

To neznáte Microsoft, ten určitě vymyslí nějaký převratný (účinný jen ve specifických případech a v těch ostatních nefunkční, zato mimořádně otravný) způsob, jak SQL injekci "zabránit". Vzpomeňte jen SP4 na SQL2000, který nevratně znemožnil trasovat dotazy, jejichž součástí je string "password". Úžasná a velice "praktická" fíčura, která zajisté mimořádně zvýšila bezpečnost databáze

Visual Studio 2008 už bylo uvolněno v ostré verzi, takže si ho samozřejmě můžeme nejen otestovat, ale i plně používat (není to žádný RC, uvolněno bylo 19.11.2007 - to už by mohl redaktor zaznamenat!). http://msdn2.microsoft.com/en-us/vstudio/default.aspx

SQL Injection nemá s bezpečností MS SQL nic společného, ale souvisí to s aplikací, která používá MS SQL. MS SQL správně provádí SQL příkazy, které volá aplikace. Když aplikace nepoužívá uložené procedury ale přímo SQL příkazy, nemá databáze moc příležitostí provést kontrolu. Ale to je problém všech databází, nejen MS SQL Serveru

Pan redaktor to samozřejmě zaznamenal. MSDN ale není přístupný jen tak někomu a o dostupnosti Express edicí jsem psal například v posledním Computeru.

pokud to nekde s vyvojem na MS technologiich mysli vazne, tak verte tomu, ze ma pristup k MSDN...

No, vážně... :) Kdo si tím vydělává atp., určitě přístup samozřejmě má. Stále je ale větší procento uživatelů, kteří si produkt kupují a "frčí" na Express edicích.

Co keby ste neodbocoval a konecne nam tu napisal, v com konkretne je SQL injection chybou databazy? Je nas tu vela, ktorych by to zaujimalo

programator by takovy blabol nenapsal

jj, musim se sebou souhlasit

urizlo mi to titulek, napsal jsem tam "sql-injection neni problem bezpecnosti databaze, ale prasacky napsanych aplikaci"

I když nejsem ty, tak s tebou musím souhlasit taky. Databáze sql-injection vyhodnocují naprosto správně. Jenom díky "programátorům" s trochu jinými údaji

Dle mého skromného názoru nepatří vývojové nástroje do rukou nikomu, kdo nedokáže napsat restriktivní parser pro vstupní data. Vždyť to není tak složité...

pokud by nepouzival primitivni spojovani retezcu pri tvorbe dotazu, tak by kvuli SQL-injection nemusel ani kontrolovat vstupni data

je to taaak...

Tím si nejsem tak úplně jistý. Nejde jen o SQL dotazy, tohle je úplně obecný princip. Data zvenčí prostě nejsou důvěryhodná, jakmile neprojdou restriktivním filtrem, šup s nimi do koše.

Ano samozrejme s vami souhlasim. Server-side validace musi byt, ale pokud mate server-side v silne typovanem jazyce tak to ani moc jinak nejde (samozrejme jeste budete mit dalsi specifickou validaci - emaily, rozsahy hodnot apod.). Ja jsem chtel jen rict, ze pokud clovek pouziva SQL databazi jak ma, tak SQL-injekce nehrozi, protoze nedochazi k zadnemu spojovani retezcu. Prave u tvorby query takovym zverskym zpusobem hrozi, ze pri "spravnych" vstupnich datech vznikne uplne jiny dotaz.

Pokud SQL dokáže sql-injection pomocí prasácky napsané aplikace propustit, nese na tom nemalý podíl viny a je to jeho problém.

Toto myslite uplne vazne ? Zoberme si to jedno po druhom :

1) Vola sa dany produkt SQL Server ? Co to naznacuje ? Ze spusta SQL prikazy.

2) Aky je rozdiel medzi spravnym a nespravnym (rozumej SQL injection) SQL prikazom ? Hm, ziadny.

SQL Injection NIKDY nie je chybou databazy, robi svoju robotu. Ano, databaza moze toto ulahcit podporou parametrizovanych query, nikdy ale databaza nenesie vinu na tom ak niekto urobi chybu v kode aplikacie (a SQL injection je chyba v kode aplikacie).

Pane, neviem kto vas pustil do redakcie, ale vazne by ste sa mali zamysliet nad vasim dalsim prispievanim k temam, ktorym nerozumiete. Ako moze databaza v pripade spojovania query rozpoznat, ze ide napriklad v tomto pripade o SQL injection :

1) Povodne query : select * from users where username = '{parameter1}' and password = '{parameter2}'

2) Parametre pri SQL injection : {parameter1} = cokolvek, {parameter2} = ' or 1=1 or '' = '

Vysledne query : select * from users where username = 'cokolvek' and password = '' or 1=1 or '' = ''

Fakt mi vysvetlite, ako moze takuto vec databaza odchytit (napoveda - nemoze). Jedina moznost pre vyriesenie tohoto problemu je parametrizovane query, a to podla mojich znalosti vacsina databaz ponuka dlhsiu dobu (a kde to nie je, tak to v drvivej vacsine implementuje framework na pristup k DB - u Javy JDBC, u PHP napr. PDO alebo rozne ine DB frameworky atd).

Všemožné databázové systémy využívám dost intenzivně několik let, vím o čem je řeč. SQL-injection je ale problém SQL databáze, protože je stavěná tak, že je možné toto provézt. Například u Oraclu je podobná situace vyloučená, jsou však ale jiné problémy, samozřejmě...

Opet nemate pravdu, i Oracle lze napadnout pomoci sql-injection. Nejen ze nerozumite databazim, ale nemate ani zakladni znalosti bezpecnosti.

Tak to by mě zajímalo, nemáte o tom nějaké bližší info?

1) Funguje na SQL Servri prikaz SELECT * FROM users where username = 'abc' or 1=1 ? Ano.

2) Funguje na Oracli prikaz SELECT * FROM users where username = 'abc' or 1=1 ? Ano.

3) Funguje na PostgreSQL prikaz SELECT * FROM users where username = 'abc' or 1=1 ? Ano.

4) Funguje na MySQL prikaz SELECT * FROM users where username = 'abc' or 1=1 ? Ano.

5) Funguje na DB2 prikaz SELECT * FROM users where username = 'abc' or 1=1 ? Ano.

.... a takto mozem pokracovat pre kazdu SQL databazu. Zabranit SQL injection mozte iba osetrenim vstupov alebo pouzitim parametrizovanych query. Databaza nema moznost rozpoznat SQL injection, ide totiz o uplne validny prikaz.

klasika ... misto priznani chyby (koneckoncu nikdo nemuze vedet vsechno), mlzeni a opakovani lzi dokola ... nakonec to skonci zakaznim diskuse jako onehda s hledanim "vlajky" :)

Nojo jenze takhle se proste Oracle nepouziva:

SELECT * FROM users where username = :username;

Pokud nevite co znamena tohle, tak nema cenu se o nicem bavit.

SELECT * FROM users where username = @username; --MSSQL syntaxe

Parametry samozřejmě fungují i v T-SQL na MS. Ale nic programátora nenutí je používat, bez rozdílu DB.

Len mi prosim napiste technicke riesenie, ako moze akykolvek tvorca databazy zakazat pouzit nasledovny SQL prikaz :

SELECT * FROM users WHERE username = 'ABCD'

SQL, ktore vzniklo kvoli SQL injection sa od normalneho SQL prikazu v nicom neodlisuje. A dokonca podme dalej - ako rozozna SQL server, ci tento prikaz je vysledkom SQL injection alebo len vysledkom chyby programatora ?:

SELECT * FROM users WHERE username = 'ABCD' or password = 'EFGH'

Pritom v oboch prikladoch som pouzil uplne rovnake zakladny SQL prikaz :

SELECT * FROM users WHERE username = '$username'

Ano, existuju technicke moznosti na to, aby utok typu SQL injection nemohol nastat. Ale to nic nemeni na tom, ze SQL databaza NEMA ziadnu moznost overovat, ci ide o SQL injection alebo nie.

tak to bychom za autonehody meli vinit auta, protoze jsou staveny na to, aby slo zatocit treba doleva, i kdyz tam nekdo stoji ... vlastne je to problem toho auta, ze nezablokovalo ridici otocit volantem, kdyz uz tam je jine auto, ze? a ze jen tupe plni rozkazy, ktere mu nekdo dal .. aaaaaha :)

No když se to bere takto, tak máte pravdu :)

Pane, viete vobec co je SQL injection ? SQL injection ma s SQL databazou spolocne akurat to, ze vy ako programator spustite nad databazou query. SQL server NEMA ziadnu sancu rozoznat SQL injection - je to totiz legitimny SQL prikaz. Na ziadnom databazovom servri vam nic nebrani spustit prikaz SELECT * FROM users WHERE username = 'xxx' OR 1=1 or '' = ''. Ako by to akakolvek databaza rozpoznala ? Nijak. Nema sancu !!!

Na SQL injection existuju 2 riesenia :

1) vstupny filter pre data - vzdy ale moze nastat situacia, ked nieco neporiesite

2) parametrizovane query - najlepsie riesenie.

Nic vas ale nikdy nebude nutit pouzit akekolvek vyssie uvedene riesenie, a teda SQL injection bude existovat pokym budu programatori, ktori na toto nebezpecie kaslu.

A zaver - SQL injection nikdy nie je chybou databazy, ale chybou aplikacie. Databaza vam to moze ulahcit (umoznenim pouzit parametrizovanych SQL prikazov), zabranit pripadnemu spusteniu SQL prikazu s SQL injection ale nemoze - ide totiz o uplne legitimny SQL prikaz.

ještě bych za 3. doplnil stored procedury

pane Sedlak, napiste mi typicky pripad sql-injection problemu a jeho ochranu. Zadne povidani. Chtel bych videt jednoduchy priklad.

Po microsoftsku to může fungovat asi takto: pokud bude query parametr typu char, varchar obsahovat něco, co vypadá jako kus příkazu, SQL server takový dotaz odmítne s výjimkou. Protože přeci toto je jedna z cest, kudy lze provést injekci, pokud by náhodou ten parametr byl v proceduře použit k textovému složení příkazu. Komu se to nelíbí, ať si p... připíše něco do registru, nebo přidá nový parametr k connection. Tohle už tu bylo v ASP.net, kde v novějších verzích najednou přibylo metání výjimek, pokud POST pole obsahovaly něco, co vypadalo jako HTML kód.

prosim o serioznost

Já seriozní jsem, ovšem zda MS... MS to tehdy uvedl jako "ochranu před XSS". Kdyby to chtěl někdo opravdu řešit přes tyhle výjimky, měl by s tím víc práce, než ošetřovat přímo konkrétní hodnoty ve chvíli, kdy s nimi pracuje. Takže výsledek byl jen ten, že aplikace, zejména publikační systémy, pod novým .net přestaly fungovat, každý si do configu připsal parametr který tu šaškárnu zrušil, jelikož to dalo nejméně práce, a bylo zase vše jak při starém. Jestli MS plánuje "ochranu před SQL injection", bude to imho zrovna takhle nějak.

Paneboze co to placate za hovadiny ... chlape bezte si dat studenou sprchu ..

boha, kdyby blbost nadnasela, tak vy tu budete poletovat jako andelicek ... nechcete priste radeji psat o necem, o cem alespon mate paru? .

omg, jestli jste tohle myslel skutecne vazne, tak nejspis nemate zrovna velke povedomi o databazich a sql injection, a asi byste si tedy mel pro priste zvolit nejake vhodnejsi tema... anebo slovy klasika "uz mi nepiste a pokud mozno nepiste vubec"...

To ze redaktor napsal takovyto nesmysl jeste neznamena ze musi hned prestat psat. To je jako kdyz je nekde nejaka chyba nebo hrubka a hned jsou vsichni nejchytrejsi a neomylni. Slusny clovek napise, ze autor nema pravdu.. i tak ale jeho clanky budu cist dal. Tato diskuze je plna radoby expertu na bezpecnost a hlavne slusnych a vzdelanych lidi, to je jasne.

tak pokud vám tady někdo předsouvá něco co evidentně není pravda tak se to holt musí uvést na rpavou míru...navíc tohle není o rádoby expertech ale o lidech kteří alespoň trochu programují a rozumí základům bezpečnosti...na to nemusíte být senior programátor :)

To myslite vazne ? Podle tehle vasi "M$ logiky" kdyz prijde lama k terminalu na kterem lama admin nechal otevrenou root-session a da rm -fr / tak za to nejspis mohou tvurci OSu ze ?

Hned po precteni jsem se kouknul kdo ten blabol napsal .... "sql-injecton" problem bezpecnosti SQL serveru ?!!