sql injection testing tutorial example
SQL Injection Exemples i maneres de prevenir atacs SQL Injection en aplicacions web
Durant la prova d’un lloc web o d’un sistema, l’objectiu del comprovador és assegurar-se que el producte provat estigui el més protegit possible.
Les proves de seguretat se solen realitzar amb aquest propòsit. Per realitzar aquest tipus de proves, inicialment, hem de tenir en compte quins atacs tenen més probabilitats de produir-se. La injecció SQL és un d’aquests atacs.
SQL Injection es considera un dels atacs més habituals, ja que pot comportar conseqüències greus i perjudicials per al vostre sistema i per a les vostres dades sensibles.
Què aprendreu:
- Què és la injecció SQL?
- Riscos de la injecció SQL
- L’essència d’aquest atac
- Eina recomanada
- Proves de seguretat d'aplicacions web contra injecció SQL
- Parts vulnerables d’aquest atac
- Automatització de proves d'injecció SQL
- Comparació amb altres atacs
- Conclusió
- Lectura recomanada
Què és la injecció SQL?
Algunes de les entrades de l'usuari poden utilitzar-se en el marc Instruccions SQL que després executa l'aplicació a la base de dades. És possible que una aplicació NO gestioni correctament les entrades donades per l'usuari.
Si aquest és el cas, un usuari maliciós podria proporcionar entrades inesperades a l'aplicació que després s'utilitzen per emmarcar i executar sentències SQL a la base de dades. Això s’anomena injecció SQL. Les conseqüències d’aquesta acció poden ser alarmants.
Com el seu propi nom indica, el propòsit de l'atac SQL Injection és injectar el codi SQL malintencionat.
Tots els camps d’un lloc web són com una porta a la base de dades. Al formulari d’inici de sessió, l’usuari introdueix les dades d’inici de sessió, al camp de cerca l’usuari introdueix un text de cerca, al formulari d’emmagatzematge de dades, l’usuari introdueix les dades per desar-les. Totes aquestes dades indicades van a la base de dades.
En lloc de dades correctes, si s’introdueix algun codi maliciós, hi ha possibilitats que es produeixin danys greus a la base de dades i a tot el sistema.
La injecció SQL es realitza amb el llenguatge de programació SQL. SQL (Structured Query Language) s’utilitza per gestionar les dades de la base de dades. Per tant, durant aquest atac, aquest codi de llenguatge de programació s’utilitza com a injecció malintencionada.
Aquest és un dels atacs més populars, ja que les bases de dades s’utilitzen per a gairebé totes les tecnologies.
Moltes aplicacions utilitzen algun tipus de base de dades. Una aplicació en prova pot tenir una interfície d'usuari que accepti l'entrada d'usuari que s'utilitza per realitzar les tasques següents:
# 1) Mostra a l'usuari les dades emmagatzemades rellevants, p. Ex. l'aplicació comprova les credencials de l'usuari mitjançant la informació d'inici de sessió introduïda per l'usuari i només exposa a l'usuari la funcionalitat i les dades rellevants
# 2) Deseu les dades introduïdes per l'usuari a la base de dades, per exemple. un cop l’usuari emplena un formulari i l’envia, l’aplicació continua guardant les dades a la base de dades; aquestes dades es posen a disposició de l'usuari en la mateixa sessió i en sessions posteriors
Riscos de la injecció SQL
Actualment, s’utilitza una base de dades per a gairebé tots els sistemes i llocs web, ja que les dades s’han d’emmagatzemar en algun lloc.
A mesura que s’emmagatzemen dades sensibles a la base de dades, la seguretat del sistema comporta més riscos. Si es robarien les dades d'un lloc web o d'un bloc personal, no hi haurà molts danys en comparació amb les dades que es robarien al sistema bancari.
L’objectiu principal d’aquest atac és piratejar la base de dades del sistema, per tant les conseqüències d’aquest atac poden ser realment perjudicials.
Les coses següents poden resultar de SQL Injection
- Hacking del compte d'una altra persona.
- Robar i copiar dades sensibles del lloc web o del sistema.
- Canvi de les dades sensibles del sistema.
- Supressió de dades sensibles del sistema.
- L'usuari podria iniciar sessió a l'aplicació com un altre usuari, fins i tot com a administrador.
- L'usuari podria veure informació privada pertanyent a altres usuaris, p. detalls de perfils d’altres usuaris, detalls de transaccions, etc.
- L'usuari podria canviar la informació de configuració de l'aplicació i les dades dels altres usuaris.
- L'usuari podria modificar l'estructura de la base de dades; fins i tot esborrar taules de la base de dades d'aplicacions.
- L'usuari podria prendre el control del servidor de base de dades i executar-hi ordres a voluntat.
Els riscos esmentats anteriorment es poden considerar greus, ja que restaurar una base de dades o les seves dades pot costar molt. La vostra empresa pot costar reputació i diners per restaurar les dades i el sistema perduts. Per tant, és molt recomanable protegir el vostre sistema contra aquest tipus d’atac i considerar les proves de seguretat com una bona inversió en la reputació del vostre producte i empresa.
Com a provador, voldria comentar, que provar contra possibles atacs és una bona pràctica encara que sigui Proves de seguretat no estava previst. D'aquesta manera, podeu protegir i provar el producte contra casos inesperats i usuaris maliciosos.
L’essència d’aquest atac
Com es va esmentar anteriorment, l'essència d'aquest atac és piratejar la base de dades amb un propòsit maliciós.
Per realitzar aquesta prova de seguretat, inicialment, heu de trobar les parts del sistema vulnerables i, a continuació, enviar codi SQL maliciós a la base de dades. Si aquest atac és possible per a un sistema, s'enviarà el codi SQL maliciós adequat i es podran dur a terme accions perjudicials a la base de dades.
Tots els camps d’un lloc web són com una porta a la base de dades. Qualsevol dada o entrada que normalment introduïm en qualsevol camp del sistema o del lloc web va a la consulta de la base de dades. Per tant, en lloc de dades correctes, si escrivim algun codi maliciós, es pot executar a la consulta de la base de dades i produir conseqüències perjudicials.
Eina recomanada
# 1) Kiuwan
Cerqueu i corregiu fàcilment vulnerabilitats com la injecció SQL al vostre codi en totes les etapes del SDLC. Kiuwan compleix els estàndards de seguretat més estrictes, inclosos OWASP, CWE, SANS 25, HIPPA i molt més.
Integreu Kiuwan al vostre IDE per obtenir comentaris instantanis durant el desenvolupament. Kiuwan admet tots els llenguatges de programació principals i s’integra amb les principals eines DevOps.
=> Escaneja el codi gratis
Per realitzar aquest atac, hem de canviar l'acte i el propòsit d'una consulta de base de dades adequada. Un dels mètodes possibles per realitzar-la és fer que la consulta sigui sempre certa i, després, inseriu el vostre codi maliciós. Canviar la consulta de base de dades a sempre cert es pot realitzar amb un codi senzill com 'o 1 = 1; -.
Els comprovadors han de tenir en compte que, tot i comprovar si es pot fer o no canviar la consulta a sempre vertadera, s’haurien de provar cometes diferents, simples i dobles. Per tant, si hem provat codi com 'o 1 = 1; -, també hauríem de provar el codi amb cometes dobles 'o 1 = 1; -.
Per exemple, considerem que tenim una consulta, que busca la paraula introduïda a la taula de base de dades:
seleccioneu * de les notes nt on nt.subject = 'cerca_paraula';
Per tant, en lloc de la paraula de cerca, si introduïm una consulta SQL Injection 'o 1 = 1; -, la consulta es farà sempre certa.
seleccioneu * de les notes nt on nt.subject = '' o 1 = 1; -
En aquest cas, el paràmetre 'subjecte' es tanca amb el pressupost i llavors tenim el codi o 1 = 1, cosa que fa que una consulta sigui sempre certa. Amb el signe '-' comentem la resta del codi de consulta, que no s'executarà. És una de les maneres més fàcils i populars de començar a controlar la consulta.
També es poden fer servir altres codis per fer que la consulta sigui sempre certa, com ara:
- 'O' abc '=' abc '; -
- 'O' '=' '; -
La part més important aquí és que després de la coma, podem introduir qualsevol codi maliciós que ens agradaria que s'executés.
Per exemple, pot ser 'o 1 = 1; deixar anar notes de taula; -
Si aquesta injecció és possible, es pot escriure qualsevol altre codi maliciós. En aquest cas, només dependrà del coneixement i la intenció de l’usuari maliciós. Com comprovar la injecció SQL?
Es pot comprovar aquesta vulnerabilitat amb molta facilitat. De vegades, n’hi ha prou amb escriure ‘o“ iniciar la sessió als camps provats. Si retorna qualsevol missatge inesperat o extraordinari, podem estar segurs que la injecció SQL és possible per a aquest camp.
Per exemple , si obteniu un missatge d'error com a 'Error intern del servidor' com a resultat de la cerca, podem estar segurs que aquest atac és possible en aquesta part del sistema.
Altres resultats que poden notificar possibles atacs són:
- S'ha carregat la pàgina en blanc.
- No hi ha missatges d'error ni d'èxit: la funcionalitat i la pàgina no reaccionen a l'entrada.
- Missatge d'èxit del codi maliciós.
Vegem com funciona això a la pràctica.
Per exemple, Comprovem si una finestra d’inici de sessió adequada és vulnerable a SQL Injection. Amb aquest propòsit, al camp de l'adreça de correu electrònic o de la contrasenya, només escrivim signe tal com es mostra a continuació.
Si aquesta entrada retorna un resultat com el missatge d'error 'Error intern del servidor' o qualsevol altre resultat inadequat, gairebé podem estar segurs que aquest atac és possible per a aquest camp.
Una cosa molt complicada Codi d'injecció SQL també es pot provar. M’agradaria esmentar que a la meva carrera professional no he trobat cap cas quan hi hagués un missatge ‘Error intern del servidor’ com a resultat del signe, però de vegades els camps no reaccionaven per obtenir un codi SQL més complicat.
Per tant, la comprovació de la injecció SQL amb una única cita «és una manera bastant fiable de comprovar si aquest atac és possible o no.
Si la cometa senzilla no retorna cap resultat inadequat, podem intentar introduir cometes dobles i comprovar-ne els resultats.
A més, el codi SQL per canviar la consulta a sempre cert es pot considerar com una manera de comprovar si aquest atac és possible o no. Tanca el paràmetre i canvia la consulta a 'veritable'. Per tant, si no es valida, aquesta entrada també pot retornar qualsevol resultat inesperat i informar al mateix, que aquest atac és possible en aquest cas.
També podeu cercar possibles atacs SQL des de l’enllaç del lloc web. Suposem que tenim l’enllaç d’un lloc web com a http://www.testing.com/books=1 . En aquest cas, 'llibres' és un paràmetre i '1' és el seu valor. Si a l’enllaç proporcionat escriuríem ‘signa en lloc d’1, comprovaríem si hi ha una possible injecció.
Per tant, enllaç http://www.testing.com/books= serà com una prova si l’atac SQL és possible per al lloc web http://www.testing.com o no.
En aquest cas, si hi ha enllaç http://www.testing.com/books= retorna un missatge d'error com ara 'Error intern del servidor' o una pàgina en blanc o qualsevol altre missatge d'error inesperat, també podem estar segurs que la injecció SQL és possible per a aquest lloc web. Més endavant, podem provar d’enviar codi SQL més complicat a través de l’enllaç del lloc web.
Per comprovar si aquest atac és possible a través de l'enllaç del lloc web o no, també es pot enviar un codi com ara 'o 1 = 1; -
Com a provador de programari experimentat, voldria recordar que no només el missatge d'error inesperat es pot considerar com una vulnerabilitat de la injecció SQL. Molts verificadors només comproven possibles atacs d'acord amb els missatges d'error.
No obstant això, cal recordar que cap missatge d'error de validació ni cap missatge d'èxit per a codi maliciós també pot ser un senyal, que aquest atac és possible.
Proves de seguretat d'aplicacions web contra injecció SQL
Les proves de seguretat d’aplicacions web s’expliquen amb exemples senzills:
Com que les conseqüències de permetre aquesta tècnica de vulnerabilitat poden ser greus, es dedueix que aquest atac s'hauria de provar durant les proves de seguretat d'una aplicació. Ara, amb una visió general d'aquesta tècnica, entenem alguns exemples pràctics d'injecció SQL.
Important: Aquesta prova d'injecció SQL només s'ha de provar a l'entorn de prova.
Si l'aplicació té una pàgina d'inici de sessió, és possible que l'aplicació utilitzi SQL dinàmic, com ara la sentència següent. S'espera que aquesta declaració retorni com a mínim una sola fila amb les dades d'usuari de la taula Usuaris com a resultat establert quan hi hagi una fila amb el nom d'usuari i la contrasenya introduïts a la sentència SQL.
SELECCIÓ * D’Usuaris WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & ' ';'
Si el provador introduïa John com a strUserName (al quadre de text del nom d’usuari) i Smith com a strPassword (al quadre de text per a la contrasenya), la sentència SQL anterior es convertiria en:
SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;
Si el provador introduïa John’– com a strUserName i no strPassword, la sentència SQL es convertiria en:
SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;
Tingueu en compte que la part de la sentència SQL després de John es converteix en un comentari. Si hi hagués algun usuari amb el nom d'usuari de John a la taula Usuaris, l'aplicació podria permetre al provador iniciar la sessió com a usuari John. El provador ara podia veure la informació privada de l'usuari John.
Què passa si el verificador no sap el nom de cap usuari existent de l'aplicació? En aquest cas, el provador podria provar noms d’usuari comuns com a administrador, administrador i sysadmin. Si cap d’aquests usuaris no existeix a la base de dades, el comprovador podria introduir John ’o‘ x ’=’ x com a strUserName i Smith ’o‘ x ’=’ x com a strPassword. Això provocaria que la sentència SQL esdevingués com la següent.
SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;
Com que la condició 'x' = 'x' sempre és certa, el conjunt de resultats estaria format per totes les files de la taula Usuaris. L'aplicació podria permetre al provador iniciar la sessió com a primer usuari a la taula Usuaris.
Important: el comprovador ha de sol·licitar a l'administrador de la base de dades o al desenvolupador que copiï la taula en qüestió abans d'intentar els atacs següents.
Si el provador entraria en John ’; Taula DROP users_details; ’- com a strUserName i qualsevol cosa com a strPassword, la sentència SQL esdevindria com la següent.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';
Aquesta afirmació pot fer que la taula 'usuaris_detalls' se suprimeixi permanentment de la base de dades.
Tot i que els exemples anteriors tracten d'utilitzar la tècnica d'injecció SQL només a la pàgina d'inici de sessió, el provador hauria de provar aquesta tècnica a totes les pàgines de l'aplicació que acceptin l'entrada de l'usuari en format textual, per exemple. pàgines de cerca, pàgines de comentaris, etc.
La injecció SQL pot ser possible en aplicacions que utilitzen SSL. Fins i tot un tallafoc podria no ser capaç de protegir l’aplicació contra aquesta tècnica.
He intentat explicar aquesta tècnica d'atac de forma senzilla. M'agradaria reiterar que aquest atac només s'ha de provar en un entorn de prova i no en l'entorn de desenvolupament, l'entorn de producció o qualsevol altre entorn.
combinació recursiva sort c ++
En lloc de provar manualment si l'aplicació és vulnerable a l'atac SQL o no, es podria utilitzar un Escàner de vulnerabilitats web que comprova aquesta vulnerabilitat.
Lectura relacionada: Proves de seguretat de l'aplicació web . Consulteu això per obtenir més detalls sobre les diferents vulnerabilitats web.
Parts vulnerables d’aquest atac
Abans d’iniciar el procés de proves, tots els provadors sincers haurien de saber més o menys quines parts serien més vulnerables a aquest atac.
També és una bona pràctica planificar quin camp del sistema s’ha de provar exactament i en quin ordre. A la meva carrera de proves, he après, que no és una bona idea provar camps contra atacs SQL aleatòriament, ja que alguns camps es poden perdre.
Com que aquest atac es realitza a la base de dades, totes les parts del sistema d’entrada de dades, els camps d’entrada i els enllaços a llocs web són vulnerables.
Les parts vulnerables inclouen:
- Camps d'inici de sessió
- Cerqueu camps
- Camps de comentaris
- Qualsevol altre camp d’entrada i desat de dades
- Enllaços del lloc web
És important notar que, mentre es prova aquest atac, no n'hi ha prou amb comprovar només un o uns quants camps. És bastant habitual que un camp es pugui protegir contra la injecció SQL, però que un altre no. Per tant, és important no oblidar-se de provar tots els camps del lloc web.
Automatització de proves d'injecció SQL
Com que alguns sistemes o llocs web provats poden ser força complicats i contenen dades sensibles, provar manualment pot ser molt difícil i també requereix molt de temps. Per tant, provar aquest atac amb eines especials pot ser de vegades útil.
Una d'aquestes eines d'injecció SQL és SOAP UI . Si tenim proves de regressió automatitzades a nivell d'API, també podem canviar la comprovació d'aquest atac mitjançant aquesta eina. A l'eina SOAP UI, ja hi ha plantilles de codi preparades per contrastar aquest atac. Aquestes plantilles també es poden complementar amb el vostre propi codi escrit.
És una eina bastant fiable.
Tot i això, ja s’hauria d’automatitzar una prova a nivell d’API, cosa que no és tan fàcil. Una altra forma possible de provar automàticament és mitjançant diversos connectors del navegador.
Cal esmentar que, encara que les eines automatitzades us estalvien temps, no sempre es consideren molt fiables. Si provem un sistema bancari o qualsevol lloc web amb dades molt sensibles, es recomana provar-lo manualment. On podeu veure els resultats exactes i analitzar-los. A més, en aquest cas, podem estar segurs, que no s’ha saltat res.
Comparació amb altres atacs
SQL Injection es pot considerar com un dels atacs més greus, ja que influeix a la base de dades i pot causar greus danys a les vostres dades i a tot el sistema.
Segur que pot tenir conseqüències més greus que una injecció Javascript o injecció HTML, ja que totes dues es realitzen al costat del client. Per a la comparació, amb aquest atac, podeu tenir accés a tota la base de dades.
Cal esmentar que, per provar aquest atac, heu de tenir un bon coneixement del llenguatge de programació SQL i, en general, heu de saber com funcionen les consultes de bases de dades. A més, mentre realitzeu aquest atac per injecció, haureu de ser més acurat i atent, ja que es pot deixar qualsevol inexactitud com a vulnerabilitats SQL.
Conclusió
Espero que hagueu tingut una idea clara de què és una injecció SQL i com hem de prevenir aquests atacs.
No obstant això, es recomana provar contra aquest tipus d'atac cada vegada que es prova un sistema o lloc web amb una base de dades. Qualsevol vulnerabilitat del sistema o de la base de dades esquerra pot costar la reputació d’una empresa i molts recursos per restaurar tot el sistema.
Com que provar aquesta injecció ajuda a trobar-ne el màxim importants vulnerabilitats de seguretat , també es recomana invertir en els vostres coneixements i eines de prova.
Si hi ha previstes proves de seguretat, les proves contra injecció SQL haurien de ser planificades com una de les primeres parts de prova.
Us heu trobat amb alguna injecció SQL típica? No dubteu a compartir les vostres experiències a la secció de comentaris següent.
Lectura recomanada
- Tutorial sobre injecció d'HTML: tipus i prevenció amb exemples
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Tutorials Eclipse en profunditat per a principiants
- Tutorial de proves destructives i proves no destructives
- Prova de descàrrega de llibres electrònics
- Proves funcionals contra proves no funcionals
- Tutorial de proves SOA: metodologia de proves per a un model d’arquitectura SOA
- Prova de parelles o Tutorial de proves de tots els parells amb eines i exemples