Aki tesztelni szeretné, itt talál egy md5 hash generátort.

SELECT SELECT SELECT FROM FROM FROM WHERE WHERE LIKE LIKE

Ez így ebben a formában még hibát dob, de ha szépen jelöljük az identifiereket, akkor már lefut:

SELECT [SELECT] [SELECT] FROM [FROM] [FROM] WHERE [WHERE] LIKE [LIKE]

Persze kell alá egy tábla is, esetleg némi adat is:

CREATE TABLE [FROM]
([SELECT] varchar(20),
[WHERE] int,
[LIKE] int)

INSERT INTO [FROM] VALUES('szegyellem magamat', 1, 1)

Így már világos, hogy a SELECT nevű oszlopnak adtunk egy aliast, ami pont a SELECT megint, hasonlóan tettünk a FROM tábla nevével is, a többi meg gyerekjáték innentől kezdve. Szeretném kihangsúlyozni, hogy ez NEM best practice, vagy bármilyen formában követendő példa, hacsak nem akarunk a pokolra jutni közönségszavazat alapján. Inkább rá is teszem a humor cimkét erre a postra.

Magyar(nak tűnő) szöveg:
(1) -Halló, a fia iskolájából telefonálok. Van egy kis számítógépes problémánk.
(2) – Ó, csak nem elrontott valamit?
- Tulajdonképpen igen.
(3) – Tényleg Robert’); DROP TABLE Students; — a fia neve?
- Ó igen, kis Bobby Tables-nek hívjuk itthon.
(4) – Nos, elveszítettük a diákjaink idei adatait. Most remélem örül.
- És remélem, hogy megtanulták, hogy megvizsgálják az adatbázis inputokat.

Aki esetleg nem tudná, hogy mi az az SQL injection, annak pár sorban:

Az SQL injection az SQL szerver leglátványosabb és leggyakoribb sebezhetősége, ami arra épít, hogy a fejlesztők jobban szeretnek stringet építeni, és azt lefuttatni, mint egy tárolt eljárást vagy paraméterezett queryt írni. Nem nagyon magyarázom most el, hogy mi is ez, csak egy mondatban: egy lekérdezésben vannak kipontozott részek, és ha az ember azt írhat a kipontozott helyekre (weboldal beviteli mezőjébe tipikusan), amit akar, akkor a lekérdezés azt fogja csinálni, amit az ember akart. Na jó, egy kicsi, buta példa, ami azért érzékelteti a lehetőségeket:

-- ez van a kódban
'select * from users where username=''' + $username + ''' and password = ''' + $password + '''
if @@rowcount = 1 ' --sikeresnek tekintjük a belépést
-- így használja az átlaguser: username: béla, password: jelszo
select * from users where username='bela' and password = 'jelszo'
if @@rowcount = 1 -- örülünk
-- így használja a kis gonosz támadó: username: admin '' /*, password: tökmindegy'' */ print ''
select * from users where username='admin' /*' and password = 'tökmindegy' */ print ''
if @@rowcount = 1 -- és egy lesz, és admin lett a kis gonosz
-- így használja a nagyon gonosz támadó:
select * from users where username='' ; exec sp_msforeachtable 'delete from ?' and password = 'tökmindegy' */
if @@rowcount = 1 -- és egy lesz, és az adatbázis eléggé kiürül

Remélem senki nem fogja azzal tölteni az idejét a jövőben, hogy weboldalakat próbál kinyírni ezen minta alapján. De a sajátokra érdemes ránézni.

Természetesen lehet védekezni az SQL injection ellen is, DBA oldalon a legtriviálisabb a least privilege, azaz csak annyi jogot adjunk az SQL usernek, amennyi tényleg muszáj (nemrégiben találkoztam azzal, hogy egy csomó ember éles üzemben webalkalmazásból sa-ként csatlakozik – ott elég jól lehet tarolni egy SQL injectionnel – átkonfigurálom az egész szervert). A nehéz azonban az a védekezésben, hogy az igazi ellenfél nem a számítógép…

Aztán visszajöttem, megnéztem a részletes leírást, amiből megtudtam, hogy ez egy április elsejei tréfa. Először nem is értettem, hogy hogy lehet ilyenkor áprilisi tréfázni, aztán rájöttem, hogy már majd’ egy hete április van… Hát a kollégáim kegyetlenül kiröhögtek. Egymás után többször…