SQLaj injekto-atakoj prezentas grandajn riskojn al TTT-aplikoj, kiuj dependas de datumbazo backend por generi dinamikan enhavon. En ĉi tiu tipo de atako, hackers manipulas TTT-aplikon en provo por injekti siajn proprajn SQL-komandojn en tiujn elsenditajn de la datumbazo. Por ekzemplo, vidu la artikolon SQL Injection Attacks en Databases. En ĉi tiu artikolo, ni rigardas plurajn manierojn, kiujn vi povas provi viajn retpaĝojn por determini ĉu ili estas vundeblaj al SQL-Injektaj atakoj.
Aŭtomata SQL-Injekta Skanado
Unu ebleco uzas aŭtomatigitan TTT-vulnerabilecan skanilon, kiel ekzemple HP's WebInspect, IBM's AppScan aŭ Cenzic's Hailstorm. Ĉi tiuj iloj ĉiuj ofertas facilajn kaj aŭtomatajn manierojn analizi viajn retpaĝajn aplikojn por potencaj SQL-injekto-vulnerabilitoj. Tamen ili estas sufiĉe multekostaj, kurante ĝis $ 25,000 per sidloko.
Manlibroj de SQL-Injektaj Provoj
Kio estas malriĉa aplika programisto por fari? Vi povas efektive kuri iujn bazajn provojn por taksi viajn retajn aplikojn por SQL-injekto-vulnerabilecoj uzante nenion pli ol retumilon. Unue, vorto de singardeco: la provoj, kiujn mi priskribas, nur serĉas bazajn SQL-Injektajn difektojn. Ili ne detektos antaŭajn teknikojn kaj estas iom tedaj por uzi. Se vi povas pagi ĝin, iru kun aŭtomata skanilo. Tamen, se vi ne povas manipuli tiun prezon-etikedon, manlibro-testado estas bonega unua paŝo.
La plej facila maniero por taksi ĉu apliko estas vundebla estas eksperimenti kun senkulpaj injektoj, kiuj ne malutilos vian datumaron, se ili sukcesos, sed donos al vi provojn, ke vi bezonas korekti problemon. Ekzemple supozas, ke vi havas simplan TTT-aplikaĵon, kiu aspektas individua en datumbazo kaj provizas kontaktan informon kiel rezulto. Tiu paĝo povus uzi la jenan URL-formaton:
Ni povas supozi, ke ĉi tiu paĝo realigas serĉon de datumbazo, per simila serĉo al la sekva:
Elektu telefonon FROM dosierujo Kie lastname = 'chapple' kaj unua nomo = 'mike'Ni eksperimentos per tio iomete. Kun nia supozita supre, ni povas fari simplan ŝanĝon al la URL, kiu provas por SQL-inksaj atakoj:
http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1Se la retejo aplike ne protektis kontraŭ SQL-injekto, ĝi simple kontaktas ĉi tiun falsan unuan nomon en la SQL-komunikaĵon, kiu ekzekutas kontraŭ la datumbazo, rezultigante:
Elektu telefonon FROM dosierujo Kie lastname = 'chapple' kaj firstname = 'mike' AND (elektita grafo (*) de falsa)> 0 OR '1' = '1'Vi rimarkos, ke la sintakso supre estas iom malsama ol tio en la originala URL. Mi prenis la liberecon de igi la URL-kodita variablo por iliaj ASCII ekvivalentoj por faciligi sekvi la ekzemplon. Ekzemple,% 3d estas la URL-kodigo por la '=' karaktero. Mi ankaŭ aldonis kelkajn liniojn por similaj celoj.
Takso de la Rezultoj
La provo venas kiam vi provas ŝarĝi la retpaĝon kun la URL listigita supre. Se la retejo estas bone kondutita, ĝi elŝaltos la unuajn citaĵojn de la enigo antaŭ ol pasi la konsulton al la datumbazo. Ĉi tio simple rezultos strangan serĉadon por iu kun unua nomo, kiu inkluzivas grupon de SQL! Vi vidos eraran mesaĝon de la aplikaĵo al la sekva:
Eraro: Neniu uzanto trovis kun nomo mike + AND + (elektu + grafo (*) + de + fake) +% 3e0 + OR + 1% 3d1 Chapple!Aliflanke, se la apliko estas vundebla al SQL-injekto, ĝi pasos la deklaron rekte al la datumbazo, rezultigante unu el du eblecoj. Unue, se via servilo havas detalajn erarajn mesaĝojn ebligitaj (kiujn vi ne devus!), Vi vidos ion kiel ĉi:
Microsoft OLE DB Provider por ODBC Drivers-eraro '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQLa Servilo] Nevalida objekto 'falsa'. / direkto.asp, linio 13Aliflanke, se via servilo ne montras detalajn mesaĝojn, vi ricevos pli generitan eraron, kiel ekzemple:
Interna Servilo Eraro La servilo renkontis internan eraron aŭ kontraŭkonformon kaj ne povis kompletigi vian peton. Bonvolu kontakti la servantan administranton por informi pri la tempo, kiam okazis la eraro kaj pri io ajn, kion vi eble faris, kio eble kaŭzis la eraron. Pli da informoj pri ĉi tiu eraro eble povas esti disponeblaj en la servila eraro.Se vi ricevas unu el la du eraroj supre, via apliko estas vundebla al SQL-injekta atako! Kelkaj paŝoj, kiujn vi povas fari por protekti viajn aplikojn kontraŭ SQL-Injektoj, inkluzivas:
- Implementu parametron kontrolanta ĉiujn aplikojn. Ekzemple, se vi petas iun eniri klientan numeron, certigu, ke la enigo estas nombra antaŭ ekzekuti la konsulton .
- Limigi la permesojn de la konto, kiu ekzekutas SQL-demandojn . La regulo de almenaŭ privilegio aplikas. Se la konto uzita por ekzekuti la konsulton ne rajtas ekzekuti ĝin, ĝi ne sukcesos!
- Uzu stokitajn procedojn (aŭ similajn teknikojn) por malhelpi uzantojn rekte interagi kun SQL-kodo.