Testimi për SIDA-të e Injection

Sulmet SQL Injection paraqesin rreziqe të jashtëzakonshme për aplikacionet në internet që varen nga një bazë e dhënash për të gjeneruar përmbajtje dinamike. Në këtë lloj sulmi, hakerët manipulojnë një aplikim në internet në një përpjekje për të injektuar komandat e tyre SQL në ato të lëshuara nga baza e të dhënave. Për shembull, shih artikullin Sulmet SQL Injection në bazat e të dhënave. Në këtë artikull, ne hedhim një vështrim në disa mënyra për të provuar aplikacionet tuaja të internetit për të përcaktuar nëse ata janë të prekshëm ndaj sulmeve SQL Injection.

Skanimi automatik i injektimit SQL

Një mundësi është përdorimi i skanimit të automatizuar të cenueshmërisë së aplikacionit të uebit, siç është HP WebInspect, AppScan i IBM ose Hailstorm i Cenzic. Këto mjete ofrojnë mënyra të thjeshta dhe të automatizuara për të analizuar aplikacionet tuaja të uebit për dobësitë e mundshme SQL Injection. Megjithatë, ata janë mjaft të shtrenjtë, duke konkurruar deri në 25,000 dollarë për një vend.

Manual SQL Testet e Injection

Çfarë është zhvilluesi i aplikacionit të dobët për të bërë? Ju në fakt mund të ekzekutoni disa teste bazë për të vlerësuar aplikacionet tuaja të uebit për dobësitë e SQL Injection duke përdorur asgjë më shumë se një shfletues web. Së pari, një fjalë e kujdes: testet që unë përshkruaj vetëm shikoni për gabimet themelore SQL Injection. Ata nuk do të zbulojnë teknika të avancuara dhe janë disi të lodhshme për t'u përdorur. Nëse mund ta përballoni atë, shkoni me një skaner të automatizuar. Megjithatë, nëse nuk mund ta përballosh këtë çmim, testimi manual është një hap i parë.

Mënyra më e lehtë për të vlerësuar nëse një aplikim është i prekshëm është të eksperimentoni me sulme të padëmshme të injektimit që në të vërtetë nuk do të dëmtojnë bazën tuaj të të dhënave nëse ata kanë sukses, por do t'ju japin prova që ju duhet të korrigjoni një problem. Për shembull, supozoni që keni pasur një aplikim të thjeshtë në internet që duket një individ në një bazë të dhënash dhe si rezultat i informacionit kontaktues. Kjo faqe mund të përdorë formatin e mëposhtëm URL:

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

Mund të supozojmë se kjo faqe kryen një kërkim në bazën e të dhënave, duke përdorur një pyetje të ngjashme me sa vijon:

SELECT telefon NGA directory KU THENI emri i fundit = 'chapple' dhe firstname = 'mike'

Le të eksperimentojmë me këtë pak. Me supozimin tonë më sipër, ne mund të bëjmë një ndryshim të thjeshtë në URL që teston për sulmet SQL injeksion:

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

Nëse aplikacioni i uebit nuk është mbrojtur siç duhet nga injektimi i SQL-it, thjesht fut këtë emër të rremë në deklaratën SQL që ekzekutohet kundër bazës së të dhënave, duke rezultuar në:

SELECT TELEFONI NGA DHJETOR ku mbishkrimi = 'chapple' dhe firstname = 'mike' AND (zgjidhni count (*) nga fake)> 0 OR '1' = '1'

Do të vëreni se sintaku i mësipërm është pak më i ndryshëm nga ai në URL-në origjinale. Kam marrë lirinë për të konvertuar variablin e koduar URL për ekuivalentët e tyre ASCII për ta bërë më të lehtë ndjekjen e shembullit. Për shembull,% 3d është kodimi URL për karakterin '='. Unë gjithashtu shtova disa ndërprerje të linjave për qëllime të ngjashme.

Vlerësimi i Rezultateve

Testi vjen kur ju përpiqeni të ngarkoni faqen me URL të listuar më sipër. Nëse aplikacioni i internetit është i sjellshëm, do të heqë kuotat e vetme nga hyrja përpara se të kalojë pyetjen në bazën e të dhënave. Kjo thjesht do të rezultojë në një lookup të çuditshëm për dikë me një emër të parë që përfshin një bandë e SQL! Do të shihni një mesazh gabimi nga aplikacioni i ngjashëm me atë më poshtë:

Gabim: Nuk u gjet asnjë përdorues me emrin mike + DHE + (zgjidhni + count (*) + nga + rreme) +% 3e0 + OR + 1% 3d1 Chapple!

Nga ana tjetër, nëse aplikacioni është i ndjeshëm ndaj injektimit SQL, ai do të kalojë deklaratën direkt në bazën e të dhënave, duke rezultuar në një nga dy mundësitë. Së pari, nëse serveri juaj ka mesazhe të detajuara të gabimeve të aktivizuara (të cilat nuk duhet!), Do të shihni diçka si kjo:

Microsoft OLE DB Provider për gabimet e shoferëve ODBC '80040e37' [Microsoft] [Driver ODBC SQL Server] [SQL Server] Emri i pavlefshëm i objektit 'i rremë'. /directory.asp, rreshti 13

Nga ana tjetër, nëse serveri juaj i internetit nuk shfaq mesazhe të detajuara të gabimeve, do të merrni një gabim më të përgjithshëm, siç janë:

Gabim i brendshëm i serverit Serveri hasi një gabim të brendshëm ose keqkonfigurim dhe nuk ishte në gjendje të plotësonte kërkesën tënde. Ju lutemi kontaktoni administratorin e serverit për të informuar për kohën kur ka ndodhur gabimi dhe për ndonjë gjë që mund të keni bërë që mund të ketë shkaktuar gabimin. Më shumë informacion rreth këtij gabimi mund të jetë i disponueshëm në logun e gabimeve të serverit.

Nëse merrni njërën prej dy gabimeve të mësipërme, aplikacioni juaj është i prekshëm ndaj sulmit SQL injection! Disa hapa që ju mund të bëni për të mbrojtur aplikacionet tuaja kundër sulmeve SQL Injection përfshijnë:

• Zbatimi i kontrollit të parametrave në të gjitha aplikacionet. Për shembull, nëse kërkon nga dikush që të futë një numër të klientit, sigurohuni që të dhënat të jenë numerike përpara se të ekzekutoni pyetjen .
• Kufizo lejet e llogarisë që ekzekuton pyetjet SQL . Zbatohet rregulli i privilegjit më të vogël. Nëse llogaria që përdoret për ekzekutimin e pyetjes nuk ka leje për ta ekzekutuar atë, nuk do të ketë sukses!
• Përdorni procedurat e ruajtura (ose teknika të ngjashme) për të parandaluar përdoruesit që të bashkëveprojnë drejtpërdrejt me kodin SQL.