2. SQL Injection

MANEL DAZ LLOBET SQL-Injection: Tcniques i solucions

El problema Tcniques datac

Solucions

Continguts

SQL-Injection: Tcniques i solucions

El problema

Tcniques datac Solucions

En aquest document es veuran els conceptes bsics de latac a sistemes web, anomenat SQL-Injection. No es tractaran totes les possibles variants daquest atac, per es donar un coneixement suficient per poder desenvolupar sistemes web que estigui protegits raonablement be daquest tipus datac.

Primer es mostrar el concepte dSQL-Injection, la vulnerabilitat que explota i diferents arquitectures de pgines web que poden ser atacades. Seguidament sexplicar algunes de les tcniques que fa servir aquest atac per accedir a informaci reservada i incls, per poder canviar la informaci o obtenir el control total del servidor. Finalment, es veuran tcniques i formes de programar per tal devitar aquest atac quan es desenvolupen aplicacions web

ndex

1.1 Introducci: Els llenguatges ....................................................... 1.1.1 SQL: Diferents Sistemes Gestors de Bases de Dades ......... 1.1.2 PHP, ASP ............................................................................. 1.2 El problema ............................................................................... 1.2.1 Concepte de SQL-Injection .................................................. 1.2.2 Tipus de SQL-Injection ......................................................... 1.2.2.1 SQL-Injection directe ....................................................... 1.2.2.1.1 Consultes 1.2.2.1.2 Execucions 1.2.2.2 SQL-Injection de segon ordre .......................................... 1.2.2.3 Blind SQL-Injection .......................................................... 1.2.2.4 Altres tipus dinjecci ....................................................... 1.3 Tcniques datac........................................................................ 1.3.1 GET i POST ......................................................................... 1.3.2 Us de les cometes ................................................................ 1.3.2.1 Magic_quotes_gpc .......................................................... 1.3.3 Us dels comentaris ............................................................... 1.3.4 Us de LIMIT 1.3.5 Us de UNION ....................................................................... 1.3.6 Us de subconsultes .............................................................. 1.4 Solucions ................................................................................... 1.4.1 Els missatges derror ............................................................ 1.4.2 La programaci .................................................................... 1.4.3 Validaci dentrada de dades ............................................... 1.4.4 Noms de columnes ............................................................... 1.4.5 Accs restringit a les bases de dades .................................. 1.4.6 Fer servir Stored Procedures ............................................... 1.4.7 Fer de hackers ..................................................................... 1.5 Conclusions ............................................................................... 1.6 Webgrafia ..................................................................................

Advertncia.

1

Lobjectiu daquest document s illustrar i ensenyar als alumnes com cal protegir un sistema web datacs del tipus SQL-Injection. Per tal daconseguir aquest objectiu s necessari veure com es produeixen aquests atacs. Cal recordar que amb la reforma del codi penal, S DELICTE EL FET DENTRAR A UN SISTEMA SENSE PERMS, encara que noms sigui per consultar informaci. Aquestes intrusions estan castigades amb multes i fins i tot amb pena de pres. Tamb es recorda que els servidors dInternet tenen la obligaci demmagatzemar les adreces IP dels seus clients, i que les forces de seguretat tenen mtodes per rastrejar aquestes IP fins al possible infractor. Tot seguit es reprodueix una entrevista a Chema Alonso realitzada per la revista dInternet RED SEGURIDAD que parla sobre aquest tema. Tamb es reprodueix una part dun reportatge de la mateixa revista sobre com el nou codi penal tracta les intrusions en sistemes, i opinions dexperts en seguretat informtica. Lenlla al reportatge complet s aquest: http://www.borrmart.es/articulo_redseguridad.php?id=2524

Advertncia.

2

Advertncia.

3

Introducci: els llenguatges.

1

Una gran part del desenvolupament daplicacions de software que es realitza al mon, correspon a pgines web, llocs web, blogs, intranets, etc. Aquest desenvolupament cada vegada s ms important, degut a les noves eines de desenvolupament web, a la universalitzaci de la xarxa Internet i a laugment de velocitat a aquesta xarxa. Llavors, per qu es realitzen aquests sistemes sense fer cap disseny previ i, sobre tot, sense posar la mxima atenci a la seguretat de les dades que emmagatzema? Precisament el fet de desenvolupar sistemes web sense posar massa atenci a la seguretat (sobre tot a lentrada de dades per part de lusuari) s el que permet a un usuari malintencionat realitzar atacs fent servir la tcnica de SQL-Injection. Aquesta tcnica s un subconjunt duna altre anomenada atacs dentrada de dades, i es basa en escriure parts de codi a les entrades del sistema on sespera una dada de lusuari, com un username, una adrea o un telfon. Si el sistema web atacat no est ben protegit, amb aquest atac es pot:

Conixer dades personals daltres usuaris del sistema Modificar dades personals daltres usuaris del sistema Eliminar dades personals daltres usuaris del sistema Obtenir drets dadministrador del sistema Obtenir el control del servidor on est allotjat el sistema web Veure codi de les parts internes del sistema web (vistes, stored procedures,

etc.) Executar comandes del sistema, que no tenen res a veure amb la web, per

consultar, modificar o eliminar fitxers del sistema de fitxers del servidor. Altres maldats subjectes a la imaginaci de latacant...

Com es pot veure, els perills que comporta un mal disseny i programaci dun sistema web sn prou importants com per posar atenci a la forma de desenvolupar-lo. Cal recordar una llei bsica de la seguretat, no noms informtica, sin general, que diu que:

O sigui, que ja es poden tenir antivirus, antispams, protecci per username i password o sistema descaner de retina per accedir a un sistema, que com tingui un punt feble, aquest ser latacat i per aquest, es podr entrar al sistema.


2

Latac de SQL-Injection consisteix en introduir sentncies de SQL a camps dentrada en els formularis de les pgines web. Si el sistema no est ben protegit, executar una instrucci SQL que no s la esperada pel sistema, donant aix resultats diferents als esperats (per esperats per latacant!). Per tal de poder fer servir aquesta tcnica, cal que es conegui el sistema gestor de bases de dades que est fent servir la pgina web atacada. Aix es aix per que cada sistema gestor de bases de dades te un llenguatge SQL1 amb certes particularitats, que cal conixer per poder explotar-les. Els sistemes gestors de bases de dades ms utilitzats en el desenvolupament de sistemes web sn SQL-Server, MySQL i Oracle. Per exemple, els comentaris fins a final de lnia (que s una eina molt poderosa a SQL-Injection) es fa de diferent manera a MySQL i a SQL-Server i Oracle:

MySQL: # SQL-Server: -- Oracle: --

Un altre aspecte que cal tenir en compte a lhora de prevenir latac de SQL-Injection, son les vistes i procediments emmagatzemats dels diferents SGBD. Per exemple, a MySQL hi ha una vista que retorna els noms de totes les taules de totes les bases de dades del servidor. Aquesta informaci en mans dun atacant amb SQL-Injection pot ser MOLT perillosa.

1 Per conixer el llenguatge SQL, es pot consultar els apunts Sistemes Gestors de Bases de Dades


3

Els sistemes web amb una mica dentitat, fan servir llenguatges de servidor, com sn PHP i ASP (i altres) per tal daccedir a la base de dades que tamb sol est al mateix servidor. Aquests llenguatges sn prou complexos com per, juntament amb els llenguatges de client (javascript i VBScript), combinats amb HTML amb o sense pgines destil (CSS), desenvolupar aplicacions de gesti complertes, via web. Els exemples ms tpics daquests sistemes sn:

Sistemes de venda per Internet: Carrets de la compra Teletreball Sistemes de gesti complerts que es fan servir a una intranet Sistemes de reserves (de bitllets de transports, dhotels, etc...) Banca per Internet

Aquests llenguatges sn els responsables ltims de laccs a la base de dades, aix que, si no sha fet abans, s en aquest punt on shauria de controlar que aquest accs es fes de forma correcta, sense permetre cap entrada de dades que no sigui vlida, i que pugui contenir una cadena de SQL injectat. Per tal de poder desenvolupar aplicacions web cal conixer algun daquests dos llenguatges de servidor. Les arquitectures ms tpiques daquests llenguatges sol ser:

HTML + Javascript + PHP + MySQL HTML + VBScript + ASP + SQL-server.

Tot i que es poden fer combinacions pel que fa al llenguatge de client (VBScript o Javascript), llenguatge de servidor (PHP o ASP) i SGBD (MySQL, SQL-Server, Oracle, MSAcces, i ms), les dues anteriors solen ser les que ms es fan servir.

El problema

4

El problema del que saprofiten els atacants amb la tcnica de SQL-Injection s la falta de comprovaci de les dades dentrada als formularis de les aplicacions web. Tamb es pot fer servir SQL-Injection als sistemes web que facin servir als seus formularis el mtode GET per enviar informaci al servidor, ja que aquest mtode fa visibles (i editables) les dades que passen entre client i servidor. Cal dir que la principal protecci contra latac de SQL-Injection s precisament, la validaci de les dades dentrada dels formularis.

El concepte principal dun atac de SQL-Injection s el de modificar una sentncia SQL mitjanant la injecci de codi SQL als camps dentrada dun formulari, o a la barra dadreces del navegador, que desprs avaluar el codi PHP de laplicaci web. Per exemple, tenim un formulari tpic de login a un sistema web, amb username i password:

I al bot Enviar (elsubmit del formulari) hi ha una crida a un fitxer PHP on es validar si el username i el password sn correctes, per tal de donar un missatge derror, o b, donar accs a lusuari. En aquest cas, el formulari enviar la informaci al fitxer PHP mitjanant el mtode GET

El problema

5

En fer clic al bot Enviar, es carrega la segent pgina: A aquesta pgina hi ha tota la informaci de lusuari Alicia Gil Rouras. A la barra de navegaci del navegador, es pot veure que el link generat per lanterior formulari ha estat aquest:

La primera errada GREU s fer servir el mtode GET per enviar dades secretes, com pot ser el password de lusuari. En aquest cas, noms mirant la barra de navegaci, es pot veure que el password daquest usuari s . Est clar que un hacker no sap, dentrada, quin s el password, per aquest sistema dona peu a dos atacs sobre la pgina; , o sigui, donat un usuari, anar provant passwords continguts a un diccionari (hi ha programes que automatitzen aquesta tasca) o sigui, que en el moment dintroduir la informaci per part de lusuari (sobre tot en espais pblics), hi hagi alg mirant la pantalla, i ho pugui veure. De totes maneres, aquests dos atacs no tenen res a veure amb SQL-injection, per dona una mostra de com de vulnerable pot arribar a ser una pgina web mal dissenyada i programada.

PertaldequeesvegimsclaramentcomactualainjeccidecodiSQL,esmostraadaltdelapgina,quinahaestatlainstrucciSQLgeneradapelsistema.

El problema

6

El que si que pot fer un hacker amb aquesta pgina, , s, primer de tot, fer click en el bot Enviar amb un

username i un password en blanc. Es mostrar la segent pgina:

Com es pot veure, la pgina dona un error de validaci. Per aix s tot el que necessita saber latacant per poder entrar al sistema: a la barra de navegaci es pot veure quins parmetres passa (fent servir el perills mtode GET) la pgina de login a la pgina PHP; aquests parmetres sn uname (que te pinta de ser lusername) i pas (que molt probablement ser el password) Tot el que ha de fer latacant s canviar ladrea que es mostra a la barra dadreces del navegador, de la segent manera:

Latacant ha posat lusername: orx=x i el mateix password, amb el que la pgina que retorna el PHP s:

Aquesta s la informaci PERSONAL dAlicia Gil Rouras!

El problema

7

Com es possible? Si ens fixem a la consulta SQL que genera el sistema es pot veure que el nom dusuari ha passat a ser or x = x igual que el password. Que significa aquesta frase? cadena en blanc, per que no doni error de cometes sense tancar Or x = x x sempre ser igual a x, amb el que aquesta condici sempre savaluar a CERT. I qualsevol_cosa or CERT = CERT Aix significa que MySQL rep una consulta que li esta dient: Dnam tota la informaci dels usuaris que el seu username sigui o CERT. Com que la part del where es compleix (qualsevol_cosa or CERT = CERT), es fa la part del select..from, i dona el primer usuari de la llista dusuaris! Si ens fixem en el que realment ha posat latacant, falta la primera i la darrera cometa de lanterior cadena: Select * from usuari where nom_usuari = orx=x and paraula_pas = orx=x La primera i darrera cometes, les posa la instrucci SQL que sexecuta al PHP. Cal dir que amb altres cadenes dinjecci de SQL, es pot arribar a treure la informaci de TOTS els usuaris de la base de dades, incls entrar al sistema com a administrador!

zuritaNota'x'or 'x' = 'x'x' or true#x' or true limit 1,1#x' or true limit 2,1#

El problema

8

La tcnica de SQL-Injection va ser catalogada i publicada per primer cop a desembre de 1995 per rain.forest.puppy a Phrack Magazine, una publicaci dedicada a temes dinternet, on analitzava les possibilitats dintroduir codi SQL a sistemes web programats en ASP amb un SGBD SQL-Server. Va fer servir aquesta tcnica per hackejar una web anomenada PacketStorm, i va publicar com ho havia fet. De totes maneres, aquesta tcnica va rebre el seu nom ms tard, a loctubre de 2003. Chip Andrews, va publicar a la web SQLSecutity.com un article anomenat SQL Injection FAQ, on a travs de sis preguntes, dona una visi general de qu s SQL-Injection, a qui afecta i com protegir-se. Altres documents importants i explicatius daquesta vulnerabilitat sn:

Web Application Disassembly with ODBC Error Messages David Litchfield de NGS Software (any 2001)

Advanced SQL Injection en Microsoft SQL Server i (more) Advanced SQL Injection Chrish Anley de NGS Software (any 2002)

Manipulating Microsoft SQL Server using SQL Injection Cesar Cerrudo de Application Security (any 2002)

Aquesta vulnerabilitat s la ms explotada en sistemes web, i tamb una de les ms estudiades i que ms variants te. Alguna daquestes variants sn les segents:

El problema

9

La tcnica de SQL-Injection directe es basa en injectar directament parts dinstruccions SQL a les entrades de les que disposi una pgina web. Lexemple del punt 1.2.1 s una tcnica de SQL-Injection directe. 1.2.2.1.1.- Consultes Mitjanant aquesta tcnica, es pot aconseguir injectar codi SQL a instruccions de tipus SELECT que executi una pgina ASP o PHP al servidor, com sha pogut veure al punt anterior. 1.2.2.1.2.- Execucions Tamb es pot aprofitar les instruccions de modificaci (INSERT, UPDATE O DELETE) per tal de modificar la informaci continguda a la base de dades. Daltre banda, si el servidor ho permet, es poden concatenar instruccions (el SELECT de la prpia pgina, mes una altre instrucci afegida per latacant) per tal de modificar la informaci. Per exemple, donada la segent instrucci duna certa pgina web:

Select saldo from usuari where nom_usuari = + $nom_usuari + ; Un atacant pot posar un nom dusuari com aquest:

;delete from usuari where nom_usuari like % Aix, la cadena SQL que finalment sexecutar al servidor ser:

Select saldo from usuari where nom_usuari = ;delete from usuari where nom_usuari like %;

Si el servidor executa les dues instruccions, tots el usuaris seran eliminats! Per aix no s tot. Si el SGBD disposa dstored procedures per accedir al sistema de fitxers, o per executar instruccions del sistema operatiu, el dany que pot ocasionar un atacant encara pot ser ms catastrfic.

El problema

10

Aquesta variant de latac es basa en no posar la injecci de SQL de forma immediata, sin que es basa en modificar certs fitxers que el SGBD pot fer servir. Per exemple, es pot modificar una cookie o un fitxer on es guardin dades que desprs intervindran a una consulta. Hi ha fins i tot una categoritzaci daquesta variant de latac, en quatre classes diferents. Per exemple, es pot pensar en una aplicaci web que demani les dades per registrar-se i que en un moment donat, recuperi totes les dades de lusuari, donat el seu nom. Suposem que lusuari (atacant) introdueix les segents dades:

El sistema ho accepta, i ho guarda a la base de dades. Posteriorment, lusuari es valida al sistema a travs del seu username i password correctes, i mostra totes les seves dades, a partir del seu nom, amb una instrucci com aquesta:

Select * from usuari where nom = + $nom + ; On el que hi ha guardat a la base de dades, al camp NOM s:

x' or nom_usuari like '% aix que la consulta resultant s:

Select * from usuari where nom = x' or nom_usuari like '%; Amb el que mostra realment, es la llista de totes les dades de tots els usuaris! Es pot pensar en guardar cadenes de injecci de SQL a altres llocs on una aplicaci web pugui llegir per tal de muntar una instrucci SQL.

El problema

11

Una altre modalitat daquest atac es basa en el comportament del sistema, en front a diferents entrades que latacant faci. Com que no es veu un resultat directe per pantalla de la informaci que busca latacant, aquest tipus datac sanomenta Blind SQL Injection: SQL injection a cegues. Per exemple, tenim que un usuari una vegada validat, pot demanar una llista de documents, i fent clic a un daquests documents, el sistema li mostra el contingut del mateix:

Aquesta s la llista de documents disponibles. Si lusuari fa clic en el primer document per exemple, la pgina que es carrega s la segent:

El problema

12

Com es pot veure a la barra dadreces, es crida a un document php, amb un parmetre anomenat id amb valor igual a 1. Que pot passar si es canvia aquest valor?

Si es posa un valor de -1 a aquest parmetre, el sistema mostra una pgina derror, dient que el document no existeix. Aix, el que tenim s que amb un valor vlid del parmetre, mostra un document, i amb un valor no vlid del parmetre mostra un error. Dons aix s tot el que li cal a un atacant per tal de extreure informaci de la base de dades. Per exemple, que mostra el sistema si es posa un valor per al parmetre com aquest? http://localhost/prova/mostrar_doc.php?id=1 and exists(select * from notes)

El problema

13

El sistema mostra un error, que diu que la taula injection.notes no existeix. Aix ens dona una altre informaci vlida per latacant, que s que la base de dades sanomena injection (ara, podria buscar un punt feble al sistema web per executar la instrucci DROP database injection !). En qualsevol cas, la taula notes no existeix, per que la condici sha avaluat a fals. Si per el contrari, latacant introdueix aquesta altra adrea: http://localhost/prova/mostrar_doc.php?id=1 and exists(select * from usuari)

Fixem-nos a ladrea que sha posat:

Latacant ha deixat un id que sap que existeix, i ha afegit una nova condici que demana al SGBD si existeix la taula usuari. Si la taula usuari efectivament, existeix, tota la condici ser CERTA, i es carregar el document amb id=1. Si la taula usuari no exists, la condici ser falsa i es carregaria la pgina amb lerror. Aix que la conclusi s que la taula usuari existeix. Dons canviant la condici de desprs de AND i automatitzant el procs, es podria extreure qualsevol informaci de qualsevol taula de la base de dades. s ms, hi ha eines que automatitzen aquest procs.

Existeixen altres tipus dinjecci de codi: XPath-injection, Blind XPath-injection: per extreure informaci de documents XML LDAP-injection Blind LDAP-Injection: per extreure informaci de larbre LDAP HTTP parameter contamination: consisteix en generar adreces http amb carcters que no sn acceptats pels servidors, i que sn reemplaats per altres carcters (que son precisament els que interessen a latacant) per saltar-se les mesures de seguretat dels servidors.

Tcniques de SQL-Injection

14

Al punt 1.2.1 ja sha vist un exemple de tcnica per realitzar un atac de SQL-Injection directe. En aquest punt es veuran diferents tcniques per accedir a diferents parts duna base de dades, fent servir instruccions de SQL. Aquest fet donar una idea de lo perills que s desenvolupar un sistema web sense tenir en compte aquest tipus datac.

El primer que cal dir en aquest punt s que fer servir el mtode GET per enviar parmetres a una pgina PHP (o ASP) al servidor te un risc MOLT ALT, per que el nom dels parmetres i el seu valor es veuen directament a la barra dadreces. Durant aquest document, ja shan vist varis exemples datacs que es basen en el mtode denviament GET. Per el mtode denviament POST tampoc s segur. Tot i que no es vegin els noms ni els valors dels parmetres tamb es pot fer injecci de codi als quadres dedici de dades dun formulari. Tot seguit es veuran una srie datacs de SQL-injection directe fent servir el mtode POST (sn vlids igual si es fes servir el mtode GET)


15

Latac ms tpic a SQL-Injection s muntar una cadena de injecci que faci servir les cometes () per tal de trencar la instrucci SQL que executa el servidor, i injectar el codi de latacant all. A lexemple del punt 1.2.1, sha vist que latacant injecta la cadena orx=x tant a lusername com al password de la barra dadreces. En cas de que el mtode no fos GET, sino POST, aquesta mateixa cadena es pot escriure als quadres dedici de la pgina de login:

I com es pot veure, el resultat s exactament el mateix que amb el mtode GET:


16

La instrucci SQL que sexecuta s la mateixa que sexecutava amb el mtode GET, al punt 1.2.1 La conclusi es que si no es prenen altres tipus de mesures, tant fa que es faci servir GET com POST. Latacant podr extreure informaci de la base de dades sense massa dificultat.

Els servidors PHP disposen dun parmetre de configuraci anomenat magic_quotes_gpc per tal dintentar evitar aquests tipus datacs. Si magic_quotes_gpc est activat, el servidor PHP afegeix un carcter \ abans de cada cometa i abans de cada backslash \. Per activar o desactivar aquest parmetre de configuraci, des de wamp server2 noms cal fer clic a la icona de wamp, i navegar pels mens: PHPConfiguracin de PHP magic quotes gpc clic

Un programador que conegui aquest problema de les cometes podria pensar en fer servir les magic_quotes_gpc3 activat solucionaria tots els seus problemes de SQL-injection amb les cometes. Sequivocaria.

2 Wamp Server s un entorn de desenvolupament que inclou el servidor web APACHE, el llenguatge PHP i el

SGBD MySQL. Altres entorns que incloguin PHP tamb han de tenir el parmetre de les magic quotes gpc a algun punt de la seva configuraci 3 A la prpia pgina de PHP, es desaconsella el seu s amb el missatge Esta opcin ha sido declarada

OBSOLETA desde PHP 5.3.0. Su uso est totalmente desaconsejado. per que no solucionen el problema de SQL-injection i generen altres problemes en la gesti de les dades a la base de dades.


17

Si be es cert que amb aquest parmetre activat, lanterior atac

genera la segent pgina:

Es pot veure que la pgina PHP fa servir el mtode POST per enviar la informaci.

Tamb es pot veure que les magic quotes han afegit un \ davant de cada cometa, i aix fa que la instrucci SQL generada no sigui correcta amb el que es genera un error.

Per que passaria si en lloc dintroduir cometes, latacant introdus %27, que s el codi ASCII corresponen a les cometes?

Per tal de poder fer servir aquest nou atac sense gaires complicacions a lhora descriure la cadena, farem servir qualsevol editor de text que tingui reemplaament de carcters, com per exemple, el bloc de notas4 de windows. Es reemplaaran les cometes pel seu codi ascii: %27

4 O la herramienta ms poderosa jams creada com diu Chema Alonso, en el seu blog de seguretat El lado del

mal.


18

Aix, a la pgina de login, noms cal posar aquesta cadena de text tant a username com a password:

amb el que laplicaci web, retorna...

...el mateix que sense el parmetre magic_quotes_gpc activat. La conclusi s que aquest parmetre de PHP no serveix a lhora de protegir-se contra un atac de cometes de SQL-Injection.


19

Els comentaris a SQL serveixen per posar un text explicatiu a certes parts duna instrucci, com a tots els llenguatges. Per per a un atacant de SQL-Injection, tamb tenen una altre utilitat molt poderosa.

A MySQL, el comentari fins a final de lnia s el carcter #. A altres SGBDs, el carcter pot variar.

Lus de comentaris a MySQL pot ser aquest:

Select * From usuaris Where saldo < 0; #usuaris morosos

El carcter # anulla tota la instrucci que es posi darrera dell.

Aix, que passaria si a la finestra de login de laplicaci web es posa un nom dusuari com aquest?

or 1#

Ni tan sols cal posar res a lentrada de password!


20

Si ens fixem en la instrucci SQL que ha executat MySQL es pot veure que lusuari s o be 1, que s cert, i desprs daix, tot el que vingui darrera, s un comentari, o sigui, que no importa. El camp paraula de pas, NO IMPORTA!

Aix, el que fa el sistema s tornar el primer usuari de la taula dusuaris. Els comentaris en aquest cas, li serveixen a latacant per anullar camps de validaci de dades a laplicaci web.

Fins al moment, latacant noms ha pogut extreure informaci del primer usuari de la taula dusuaris, lAlicia Gil Rouras.

Noms per aquest fet, ja seria imprescindible que el programador refs tot el lloc web per tal devitar aquests atacs, per que la informaci que latacant ha estat capa de veure s molt sensible.

Per latacant pot fer servir una altra tcnica per obtenir la informaci de TOTS els usuaris de la base de dades.

Aquesta altra tcnica s la clusula LIMIT de MySQL. El funcionament daquesta clusula s el segent:

Select * from usuaris limit 1,1 dona la informaci del primer usuari Select * from usuaris limit 2,1 dona la informaci del segon usuari Select * from usuaris limit 2,2 dona la informaci del segon i el tercer usuari El primer parmetre de LIMIT s a quina fila es comena, i el segon parmetre indica quantes files a partir daquesta es vol.

Aix, si latacant posa una injecci de SQL com aquesta:

or 1 limit 2,1#


21

El sistema web mostra una pgina com aquesta:

Noms pel fet de que ladministrador est a la taula dusuaris com el segon usuari (deu tenir un nom dusuari com admin o semblant), latacant ha pogut entrar com administrador. Ara, no seria gens complicat entrar com a administrador, fent una injecci SQL com admin#


22

Amb limit 3,1, el resultat s el segent:

La informaci dun altre usuari. I aix amb la resta.


23

Per ara, latacant sha limitat a fer atacs contra la taula dusuaris. Per fent servir la clusula UNION i les taules del sistema, podria esbrinar molta ms informaci de la base de dades. Per exemple, podria arribar a saber quines taules te la base de dades:

Posant aquesta injecci de SQL al camp de lusername, el sistema retornar el segent error:

Aquest error s degut nica i exclusivament, a que el nmero de camps de la taula usuari s diferent del nmero de camps del segon SELECT de la UNION.

zuritaNotatenen 2 selectsels camps han de ser iguals.


24

Lnic que latacant ha de fer s igualar els diferents nmeros de camps, afegint null al segon SELECT:

El resultat ara seria:

Ara ja no dona error, per no mostra cap resultat. Per qu? Dons per que el primer i el segon camp corresponen a username i password, que sn dades que no es mostren en aquesta pgina.


25

Per poder veure la informaci que li interessa, latacant canviaria el ordre dels nuls al segon SELECT de la UNION:

I el resultat seria:

En aquest cas, a la pgina que retorna el sistema es pot veure que a Nom, figura el nom duna base de dades, i a Adrea, el nom duna taula.


26

Si latacant conegus el nom de la base de dades que vol atacar (i ja hem vist anteriorment que el pot conixer), noms li caldria afegir-lo al la part WHERE del segon SELECT de la UNION:

I el sistema retornaria una pgina com aquesta:

On es pot veure que la base de dades es diu injection i que hi ha una taula anomenada document. Si es canvia de taula de sistema a lhora de fer el segon SELECT de la UNION, latacant pot arribar a veure, fins i tot, el codi de les vistes definides a qualsevol base de dades!


27

El resultat seria:

I com es pot veure, hi ha una vista anomenada v_llistat_morosos que te el codi que es mostra al camp telfon.

Combinant aquests atacs amb la clusula LIMIT, latacant pot accedir a qualsevol lloc de la base de dades, incls al codi de les vistes!


28

Finalment, per tal dillustrar un altre exemple de Blind SQL-Injection, es veur com un atacant, fent servir subconsultes, pot conixer informaci molt sensible de la base de dades:

En aquest cas, si latacant injecta una cadena SQL com aquesta:

El resultat que retorna el sistema web s:

Com es pot veure, al SQL que sexecuta no importa el nom dusuari, ja que desprs hi ha un OR, que, en cas de ser cert, tot el WHERE es far cert i es mostrar un usuari. Llavors, vol dir que 1


29

I si la injecci de SQL s aquesta altre:

el resultat s el segent:

En aquest cas, la diferncia s que es fa un COUNT dun camp de la taula. Si el camp existeix, es mostra informaci. Si no exists, es generaria un error:

Com en aquest cas, on latacant ha comprovat si a la taula usuari hi ha un camp anomenat password i el resultat s que el sistema retorna un error.


30

Una vegada vistes les mltiples tcniques de SQL-Injection per tal de burlar la seguretat de un sistema web, cal indicar que fer per protegir-se daquests atacs.

El principal antdot contra aquest mtode s tenir en compte mentre sest desenvolupant les aplicacions web, que es poden produir aquests tipus datacs.

Quan es desenvolupi una aplicaci web, (o intranet, o qualsevol aplicaci susceptible de ser atacada amb SQL_injection),

, i no deixar que el sistema mostri els errors, per que els errors de sistema poden donar molta informaci a un atacat.

Per exemple, si latacant fa una injecci de Blind SQL-injection com aquesta:

El resultat del sistema web s:

El missatge derror que genera MySQL diu: Table injection.noexisteix doesnt exist. Amb aquest missatge derror, latacant ja sap quin s el nom de la base de dades a la que pot atacar: injection

Cal evitar fer servir el mtode GET per passar informaci. No s que amb el mtode POST seviti latac, per no es posen les coses tan evidents com amb GET.

Com ja sha vist, no serveix de res fer servir la configuraci de PHP de magic_quotes_gpc, i entorpeix el procs de prova del sistema

No concatenar directament %_GET o %_POST a la cadena SQL que sha dexecutar, sin que caldria carregar aquests valors a variables i comprovar que no continguin substrings sospitoses.


31

A lhora de programar, cal validar sempre les entrades de dades de lusuari. s ms, cal validar qualsevol dada provinent de lexterior, ja sigui des de lusuari, com si es carrega dun fitxer extern, com pot ser, per exemple, una coockie (SQL_injection de segon nivell!)

Aquesta validaci consisteix en buscar carcters com #, cadenes com and o or o cadenes que continguin instruccions de SQL. Si es troba alguna cadena sospitosa a les entrades, sha de denegar laccs al sistema.

Als camps dentrada numrics, cal comprovar que la dada entrada s realment un nmero, i que aquest nmero est dintre del rang que sespera, per que una altre tcnica de SQL_injection s introduir un nmero tan gran que causi un overflow, i per tant, un error que pot proporcionar informaci a latacant.

Cal fer notar que si la injecci de SQL es fa sobre una entrada de text de tipus numrica, no cal que latacant introdueixi cometes, per que els nmeros no necessiten cometes. A latacant noms li caldria injectar una cadena com:

Per aix als camps numrics no basta amb comprovar que estigui lliure de cometes, sin que cal comprovar tamb que efectivament, lusuari hagi posat un nmero, i que els lmits del nmero proporcionat siguin correctes.

Finament, cal fer notar que a ms de tot aix, cal evitar que lusuari introdueixi la cadena %27, que s el codi ascii de les cometes!

Es possible que a la programaci duna aplicaci web, hi hagi una pgina que executi un SQL amb el que el nom duna columna lindiqui lusuari. Per exemple, en el cas de llistats ordenats per diferents camps:

Select * from usuaris order by . $_POST[nom_columna]; Aquest parmetre s susceptible de ser injectat amb un SQL. Per tant, sha de vigilar que acompleixi amb el que sespera del parmetre. Per exemple, que no tingui cap substring estranya (#,,union, etc).

Un altre mtode de seguretat es tancar el parmetre entre (), si el SGBD s SQL-Server o Oracle, i entre (`) si s MySQL


32

Com passa a tots els sistemes, quan ms privilegis tingui lusuari que accedeix, ms greu ser un atac fent servir aquest usuari. Per aix, a lhora de connectar a la base de dades per tal de fer consultes, cal que es faci amb un usuari (del SGBD) que noms tingui els permisos necessaris per obtenir la informaci que necessita, o per modificar la seva prpia informaci. Fent servir aquesta tcnica de protecci, es pot evitar que latacant, encara que hagi entrar al sistema suplantant a un usuari, noms podria afectar a aquell usuari, amb el que no podria accedir ni a dades daltres usuaris, ni molt menys al catleg (metadades, taules del sistema) del SGBD, com ja sha vist que podria fer-lo. Tamb es poden fer servir vistes per que lusuari obtingui les dades a les que te dret daccs, i denegar-li laccs a les taules reals.

Tot i que no s cap garantia de seguretat, si que posa les coses ms complicades a un atacant. En lloc de modificar directament la base de dades, es pot programar stored procedures que ho facin, tenint en compte un control de nmero de files modificades/eliminades, comprovaci de parmetres de la instrucci, etc. A ms, descobrir el nom i els parmetres de les stored procedures, si lusuari que les executa no te drets dadministrador, s bastant ms difcil que injectar un DELETE a una taula.

Per ltim, una bona manera de comprovar si una aplicaci web s vulnerable a atacs de SQL-Injection s, precisament, sotmetre-la a un atac de SQL-Injection! El desenvolupador del sistema web hauria dintentar hackejar-lo via atacs de SQL-Injection i comprovar si el sistema aguanta aquests atacs. En cas de que no ho faci, a ms darreglar la vulnerabilitat, caldria documentar-la i comprovar per qu sha produt aquella vulnerabilitat, de cara a projectes futurs.

Conclusions

33

Les conclusions a les que sarriba desprs de conixer els atacs de SQL-injection i les seves possibles solucions son:

1. . Per no per aquest motiu no sha de programar de manera que

es posin les coses difcils a un possible atacant!

2. . Encara hi ha temes datacs de SQL-Injection que no shan tractat en

aquest document (SQL-Injection amb consultes invertides, per exemple, o eines dautomatitzaci datacs Blind SQL-injection)

3. Validar TOTES

les entrades de dades, tant de longitud com de contingut, configurar els usuaris que han daccedir a la base de dades noms amb els permisos necessaris, i no entrar SEMPRE a la base de dades com a root, generar missatges derror propis, i no deixar que sigui el sistema (ni el llenguatge de programaci, ni el SGBD) qui mostri els missatges.

http://www.elladodelmal.com https://www.owasp.org http://foro.elhacker.net/tutoriales_documentacion/tutorial_de_inyeccion_sql_sq

l_injection-t98448.0.html http://www.nccgroup.com/Libraries/Document_Downloads/Second-

Order_Code_Injection_Attacks.sflb.ashx

2. SQL Injection

Documents

Transcript of 2. SQL Injection