Ang pag-atake ng SQL Injection ay nagpapakita ng matinding panganib sa mga web application na nakasalalay sa backend ng database upang makabuo ng dynamic na nilalaman. Sa ganitong uri ng pag-atake, ang mga hacker ay gumagamit ng isang web application sa pagtatangkang ipasok ang kanilang sariling mga SQL command sa mga ibinigay ng database. Para sa isang halimbawa, tingnan ang artikulo SQL Injection Attacks sa Mga Database. Sa artikulong ito, tinitingnan namin ang ilang mga paraan na maaari mong subukan ang iyong mga web application upang matukoy kung sila ay mahina laban sa pag-atake ng SQL Injection.
Automated SQL Injection Scanning
Ang isang posibilidad ay gumagamit ng isang awtomatikong web application kahinaan scanner, tulad ng HP's WebInspect, IBM AppScan o Hurricane Cenzic. Ang mga tool na ito ay nag-aalok ng madali, awtomatikong paraan upang pag-aralan ang iyong mga aplikasyon sa web para sa mga potensyal na kahinaan sa SQL Injection. Gayunpaman, ang mga ito ay masyadong mahal, tumatakbo sa hanggang sa $ 25,000 bawat upuan.
Mga Manu-manong SQL Injection Test
Ano ang isang mahirap na nag-develop ng application na gagawin? Maaari mong aktwal na magpatakbo ng ilang mga pangunahing pagsusuri upang suriin ang iyong mga aplikasyon sa web para sa mga kahinaan sa SQL Injection gamit ang walang higit pa sa isang web browser. Una, isang salita ng pag-iingat: ang mga pagsubok na inilalarawan ko lamang ang hitsura para sa pangunahing mga SQL Injection flaws. Hindi nila makita ang mga advanced na diskarte at medyo nakakapagod na gamitin. Kung maaari mong bayaran ito, pumunta sa isang awtomatikong scanner. Gayunpaman, kung hindi mo kayang mahawakan ang tag ng presyo, ang pagsusuri sa manu-manong ay isang mahusay na unang hakbang.
Ang pinakamadaling paraan upang pag-aralan kung ang isang application ay maaaring masugatan ay mag-eksperimento sa mga di-nakapipinsalang atake ng iniksyon na hindi talaga makapinsala sa iyong database kung magtagumpay sila ngunit magbibigay sa iyo ng katibayan na kailangan mong itama ang isang problema. Halimbawa, ipagpalagay na mayroon kang simpleng application sa web na tumitingin sa isang indibidwal sa isang database at nagbibigay ng impormasyon sa pakikipag-ugnay bilang isang resulta. Maaaring gamitin ng pahinang iyon ang sumusunod na format ng URL:
Maaari naming ipalagay na ang pahinang ito ay gumaganap ng paghahanap ng database, gamit ang query na katulad ng sumusunod:
PUMILI NG telepono FROM directory WHERE lastname = 'chapple' at firstname = 'mike'Mag-eksperimento tayo dito nang kaunti. Sa aming palagay sa itaas, maaari naming gumawa ng isang simpleng pagbabago sa URL na sumusuri para sa pag-atake ng SQL injection:
http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1Kung ang web application ay hindi maayos na protektado laban sa SQL iniksyon, ito lamang ang mga plugs na pekeng unang pangalan sa SQL pahayag na ito executes laban sa database, na nagreresulta sa:
PUMILI NG telepono FROM directory WHERE lastname = 'chapple' at firstname = 'mike' AT (piliin ang count (*) mula sa pekeng)> 0 OR '1' = '1'Mapapansin mo na ang syntax sa itaas ay isang maliit na naiiba kaysa sa orihinal na URL. Kinuha ko ang kalayaan sa pag-convert ng variable na naka-encode ng URL para sa kanilang katumbas na ASCII upang mas madaling sundin ang halimbawa. Halimbawa, ang% 3d ay ang pag-encode ng URL para sa '=' character. Nagdagdag din ako ng ilang linya ng break para sa mga katulad na layunin.
Pagsuri ng Mga Resulta
Dumating ang pagsubok kapag sinubukan mong i-load ang webpage gamit ang URL na nakalista sa itaas. Kung ang web application ay mahusay na kumilos, ito ay alisin ang mga solong quotes mula sa input bago ipasa ang query sa database. Ito ay magreresulta lamang sa isang kakaibang lookup para sa isang tao na may unang pangalan na kasama ang isang bungkos ng SQL! Makakakita ka ng isang mensahe ng error mula sa application na katulad ng nasa ibaba:
Error: Walang nakitang user na may pangalan na mike + AT + (piliin + count (*) + mula sa pekeng) +% 3e0 + OR + 1% 3d1 Chapple!Sa kabilang banda, kung ang application ay mahina laban sa SQL injection, ito ay ipasa ang pahayag nang direkta sa database, na nagreresulta sa isa sa dalawang posibilidad. Una, kung pinagana ang detalyadong mga error ng mga mensahe ng error (na hindi mo dapat!), Makakakita ka ng ganito:
Microsoft OLE DB Provider para sa ODBC Driver error '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Di-wastong object name na 'pekeng'. /directory.asp, linya 13Sa kabilang banda, kung ang iyong web server ay hindi nagpapakita ng detalyadong mga mensahe ng error, makakakuha ka ng mas pangkaraniwang error, tulad ng:
Error sa Panloob na Server Nakakita ang server ng isang panloob na error o maling pag-configure at hindi makumpleto ang iyong kahilingan. Mangyaring makipag-ugnay sa tagapangasiwa ng server upang ipaalam ang oras na naganap ang error at anumang bagay na maaaring ginawa mo na maaaring naging sanhi ng error. Ang karagdagang impormasyon tungkol sa error na ito ay maaaring makuha sa log ng error ng server.Kung natanggap mo ang alinman sa isa sa dalawang mga error sa itaas, ang iyong application ay maaaring mahina sa pag-iniksyon ng SQL injection! Ang ilang mga hakbang na maaari mong gawin upang maprotektahan ang iyong mga application laban sa pag-atake ng SQL Injection ay kasama ang:
- Ipatupad ang checking parameter sa lahat ng mga application. Halimbawa, kung hinihiling mo ang isang tao na magpasok ng isang numero ng customer, siguraduhin na ang input ay numeric bago isagawa ang query .
- Limitahan ang mga pahintulot ng account na nagsasagawa ng mga query sa SQL . Ang panuntunan ng hindi bababa sa pribilehiyo ay nalalapat. Kung ang account na ginamit upang maipatupad ang query ay walang pahintulot upang maisagawa ito, hindi ito magtagumpay!
- Gumamit ng mga nakaimbak na pamamaraan (o katulad na mga diskarte) upang maiwasan ang mga gumagamit mula sa direktang pakikipag-ugnay sa SQL code.