Els atacs d'injecció de SQL suposen un gran risc per a aplicacions web que depenen d'un backend de la base de dades per generar contingut dinàmic. En aquest tipus d'atac, els hackers manipulen una aplicació web en un intent d'injectar els seus propis comandaments SQL en els emesos per la base de dades. Per obtenir un exemple, vegeu l'article SQL Injection Attacks on Databases. En aquest article, fem una ullada a diverses maneres en què podeu provar les vostres aplicacions web per determinar si són vulnerables als atacs d'injecció de SQL.
Escaneig automàtic d'injecció de SQL
Una possibilitat és utilitzar un escàner de vulnerabilitat d'aplicacions web automatitzat, com ara WebInspect d'HP, AppScan d'IBM o Hailstorm de Cenzic. Totes aquestes eines ofereixen maneres fàcils i automatitzades d'analitzar les vostres aplicacions web per a possibles vulnerabilitats d'injecció de SQL. No obstant això, són bastant cars, amb un màxim de 25.000 dòlars per seient.
Proves manuals d'injecció de SQL
Què ha de fer un desenvolupador d'aplicacions? Realment podeu executar algunes proves bàsiques per avaluar les vostres aplicacions web per a les vulnerabilitats d'injecció de SQL que utilitzen res més que un navegador web. En primer lloc, una paraula de precaució: les proves que descriu només busquen errors bàsics d'injecció de SQL. No detectaran tècniques avançades i són una mica tedioses d'utilitzar. Si ho podeu permetre, aneu amb un escàner automatitzat. Tanmateix, si no podeu gestionar aquest preu, les proves manuals són un gran primer pas.
La forma més senzilla d'avaluar si una aplicació és vulnerable és experimentar amb atacs d'injecció innocus que no perjudiquin la vostra base de dades si ho aconsegueixen, però us proporcionaran proves que cal corregir un problema. Per exemple, suposem que tenia una aplicació web senzilla que busca un individu en una base de dades i, per tant, proporciona informació de contacte. Aquesta pàgina podria utilitzar el següent format d'URL:
Podem suposar que aquesta pàgina realitza una cerca de bases de dades, mitjançant una consulta similar a la següent:
SELECCIONEU el telèfon FROM directory WHERE lastname = 'chapple' and firstname = 'mike'Anem a experimentar amb això una mica. Amb el nostre supòsit anterior, podem fer un canvi senzill a l'URL que proveeix els atacs d'injecció de SQL:
http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+de+fake)+%3e0+OR+'1'%3d'1Si l'aplicació web no ha estat protegida correctament contra la injecció de SQL, només connecta aquest nom fals a la instrucció SQL que executa contra la base de dades, el que resulta en:
SELECCIONEU EL telèfon DES DE EL directori ONDE Lastname = 'chapple' i firstname = 'mike' AND (seleccioneu el recompte (*) de la falsificació)> 0 O '1' = '1'Notaràs que la sintaxi anterior és una mica diferent a la de l'URL original. Em vaig prendre la llibertat de convertir la variable codificada per URL pels seus equivalents ASCII per facilitar el seguiment de l'exemple. Per exemple,% 3d és la codificació d'URL per al caràcter '='. També he afegit alguns salts de línia amb propòsits similars.
Avaluació dels resultats
La prova apareix quan intenteu carregar la pàgina web amb l'URL que es mostra més amunt. Si l'aplicació web es comporta bé, esborraran les cometes individuals de l'entrada abans de passar la consulta a la base de dades. Això simplement donarà lloc a una cerca estranya per algú amb un primer nom que inclogui un munt de SQL! Veureu un missatge d'error de l'aplicació similar al següent:
Error: no s'ha trobat cap usuari amb el nom mike + AND + (seleccioneu + compte (*) + de + fals) +% 3e0 + O + 1% 3d1 Chapple!D'altra banda, si l'aplicació és vulnerable a la injecció SQL, passarà directament la declaració a la base de dades, resultant en una de dues possibilitats. En primer lloc, si el vostre servidor té activats els missatges d'error detallats (que no heu de fer!), Veureu una cosa així:
Proveïdor OLE DB de Microsoft per a controladors ODBC error '80040e37' [Microsoft] [Controlador ODBC SQL Server] [SQL Server] Nom d'objecte invàlid 'fals'. /directori.asp, línia 13D'altra banda, si el vostre servidor web no mostra missatges d'error detallats, obtindreu un error més genèric, com ara:
Error del servidor intern El servidor ha trobat un error intern o una configuració incorrecta i no ha pogut completar la vostra sol·licitud. Poseu-vos en contacte amb l'administrador del servidor per informar de la data en què va passar l'error i de qualsevol cosa que hagués pogut fer que hagués causat l'error. És possible que hi hagi més informació sobre aquest error en el registre d'errors del servidor.Si rebeu algun dels dos errors anteriors, la vostra aplicació és vulnerable a l'atac d'injecció SQL. Alguns passos que podeu dur a terme per protegir les vostres aplicacions contra els atacs d'injecció de SQL inclouen:
- Implementar la comprovació de paràmetres a totes les aplicacions. Per exemple, si demana a algú que introdueixi un número de client, assegureu-vos que l'entrada sigui numèrica abans d' executar la consulta .
- Limiteu els permisos del compte que executa consultes SQL . S'aplica la regla de menys privilegi. Si el compte que s'utilitza per executar la consulta no té permís per executar-la, no tindrà èxit.
- Utilitzeu procediments emmagatzemats (o tècniques similars) per evitar que els usuaris interactuïn directament amb el codi SQL.