Testing For SQL Injection Vulnerabilities

Serangan SQL Injection nyebabake resiko banget tumrap aplikasi web sing gumantung marang backend database kanggo ngasilake konten dinamis. Ing jinis serangan iki, peretas ngandhut aplikasi web minangka upaya nyuntikake perintah SQL dhewe menyang sing diterbitake dening basis data. Kanggo conto, ndeleng artikel SQL Injection Attacks on Database. Ing artikel iki, kita goleki sawetara cara sampeyan bisa nyoba aplikasi web kanggo nemtokake manawa dheweke rawan karo serangan SQL Injection.

Otomatis Injeksi SQL Inovatif

Siji kemungkinan nggunakake pemindai kerentanan aplikasi otomatis, kayata WebInspect HP, AppScan IBM utawa Cenzic's Hailstorm. Alat kasebut kabeh menehi cara sing gampang, otomatis kanggo nganalisa aplikasi web kanggo kerentanan SQL Injeksi potensial. Nanging, padha cukup larang, mlaku nganti $ 25.000 saben kursi.

Manual SQL Injection Tests

Apa pangembang aplikasi sing mlarat? Sampeyan bener bisa mbukak sawetara dhasar kanggo ngevaluasi aplikasi web sampeyan kanggo kerentanan SQL Injection nggunakake ora luwih saka browser web. Kawitan, tembung sing ati-ati: tes-tes sing aku jelasake mung ndelok cacat SQL Injeksi dhasar. Wong-wong bakal ora nemokake tèknik sing luwih maju lan bisa digunakake. Yen sampeyan bisa mbayar, pindhah karo pemindai otomatis. Nanging, yen sampeyan ora bisa nangani tag rega kasebut, testing manual minangka langkah pisanan sing apik.

Cara sing paling gampang kanggo ngira-ngira apa aplikasi sing rawan iku kanggo ngethekake serangan injeksi sing ora bener sing ora bakal ngrusak basis data manawa bisa sukses nanging bakal menehi bukti sing kudu mbenerake masalah. Contone, umpamane sampeyan duwe aplikasi web prasaja sing katon ing individu ing basis data lan menehi informasi kontak minangka asil. Kaca sing digunakake bisa nggunakake format URL ing ngisor iki:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Kita bisa nganggep sing kaca iki nggoleki basis data, nggunakake query sing padha karo:

PILIH telpon FROM directory WHERE lastname = 'chapple' lan firstname = 'mike'

Ayo eksperimen karo dicokot iki. Kanthi asumsi kita ing ndhuwur, kita bisa nggawe owah-owahan prasaja kanggo URL sing nyoba kanggo serangan injeksi SQL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

Yen aplikasi web durung dilindungi kanthi bener saka injeksi SQL, mung nglebokake jeneng pisanan palsu kasebut marang pernyataan SQL sing nglakokaké dhokumèn dhéwé, sing ngasilaké:

PILIH telpon FROM directory WHERE lastname = 'chapple' lan firstname = 'mike' AND (pilih count (*) saka palsu)> 0 OR '1' = '1'

Sampeyan bakal sok dong mirsani yen sintaksis ing ndhuwur iku beda sethithik tinimbang ing URL asli. Aku njupuk kebebasan ngowahi variabel sing dikodekan URL kanggo padha ASCII supaya luwih gampang ngetutake conto. Contone,% 3d iku encoding URL kanggo karakter '='. Aku uga nambahake sawetara garis kanggo tujuan sing padha.

Nliti Hasil

Ujian kasebut nalika sampeyan nyoba ngunggah kaca web kanthi URL sing ana ing ndhuwur. Yen aplikasi web bisa mlaku-mlaku, bakal ngilangi tanda kutip siji saka input sadurunge mlebu query menyang basis data. Iki mung bakal ngasilake panemu aneh kanggo wong sing jeneng pisanan sing kalebu sekelompok SQL! Sampeyan bakal weruh pesen kesalahan saka aplikasi sing padha karo ing ngisor iki:

Kesalahan: Ora ana pangguna sing ditemokake kanthi jeneng mike + AND + (pilih + count (*) + saka + palsu) +% 3e0 + UTAWA + 1% 3d1 Chapple!

Saliyane, yen aplikasi bisa ngrugekke injeksi SQL, bakal dilaporake langsung menyang basis data, sing bakal mrodhuksi salah siji saka rong kemungkinan. Pisanan, yen server sampeyan wis ngowahi pesen kesalahan sing luwih rinci (sing mesthine ora!), Sampeyan bakal weruh kaya iki:

Microsoft OLE DB Provider kanggo ODBC Drivers error '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Jeneng obyek ora valid 'palsu'. /directory.asp, baris 13

Ing sisih liyane, yen server web sampeyan ora nampilake pesen kesalahan sing luwih rinci, sampeyan bakal entuk kasalahan sing luwih umum, kayata:

Kesalahan Server Internal Server ditangani kesalahan internal utawa misconfiguration lan ora bisa ngrampungake panjaluk sampeyan. Hubungi administrator server kanggo ngandhani wektu ana kesalahan lan tindakan apa wae sing bisa sampeyan tindakake sing uga nyebabake kesalahan. Informasi luwih akeh babagan kesalahan iki bisa kasedhiya ing log kesalahan server.

Yen sampeyan nampa salah siji saka loro kasalahan ing ndhuwur, aplikasi sampeyan bisa ngrugekna serangan injeksi SQL! Sawetara langkah sing bisa dilakoni kanggo nglindhungi aplikasi saka serangan SQL Injection kalebu:

• Nglakokne tandha parameter ing kabeh aplikasi. Contone, yen sampeyan njaluk wong kanggo ngetik nomer customer, priksa manawa input iku numerik sadurunge ngeksekusi query .
• Batasi ijin akun sing nglakokne query SQL . Aturan paling ora bisa ditrapake. Yen akun sing dipigunakaké kanggo nglakokaké pitakonan ora nduwèni idin kanggo nglakokaké, ora bakal kasil!
• Gunakake prosedur sing disimpen (utawa teknik sing padha) kanggo nyegah kedhaftar langsung saka interaksi karo kode SQL.