Impacte de la injecció SQL
La injecció SQL (SQLi) permet a un atacant interferir amb les consultes que una aplicació fa a la seva base de dades [S1]. L'impacte principal inclou l'accés no autoritzat a dades sensibles, com ara contrasenyes d'usuari, dades de targetes de crèdit i informació personal [S1].
Més enllà del robatori de dades, els atacants sovint poden modificar o suprimir registres de bases de dades, la qual cosa comporta canvis persistents en el comportament de l'aplicació o pèrdua de dades [S1]. En casos d'alta gravetat, SQLi es pot escalar per comprometre la infraestructura de fons, activar atacs de denegació de servei o proporcionar una porta posterior persistent als sistemes de l'organització [S1][S2].
Causa principal: maneig d'entrada no segur
La causa principal de la injecció SQL és la neutralització inadequada d'elements especials utilitzats en una ordre SQL [S2]. Això passa quan una aplicació construeix consultes SQL concatenant l'entrada influïda externament directament a la cadena de consulta [S1][S2].
Com que l'entrada no està correctament aïllada de l'estructura de la consulta, l'intèrpret de la base de dades pot executar parts de l'entrada de l'usuari com a codi SQL en lloc de tractar-la com a dades literals [S2]. Aquesta vulnerabilitat es pot manifestar en diverses parts d'una consulta, com ara sentències SELECT, valors INSERT o sentències UPDATE [S1].
Solucions i mitigacions concretes
Utilitzeu consultes parametritzades
La forma més eficaç d'evitar la injecció SQL és l'ús de consultes parametritzades, també conegudes com a declaracions preparades [S1]. En lloc de concatenar cadenes, els desenvolupadors haurien d'utilitzar mecanismes estructurats que facin complir la separació de dades i codi [S2].
Principi del mínim privilegi
Les aplicacions s'han de connectar a la base de dades utilitzant els privilegis més baixos necessaris per a les seves tasques [S2]. Un compte d'aplicació web no hauria de tenir privilegis administratius i s'hauria de restringir a les taules o operacions específiques necessàries per a la seva funció [S2].
Validació i codificació d'entrada
Tot i que no és un reemplaçament de la parametrització, la validació d'entrada proporciona una defensa en profunditat [S2]. Les aplicacions haurien d'utilitzar una estratègia d'acceptació coneguda i bona, validant que l'entrada coincideixi amb els tipus, longituds i formats esperats [S2].
Com ho prova FixVibe
FixVibe ja cobreix la injecció SQL a través del mòdul d'escàner active.sqli tancat. Les exploracions actives només s'executen després de la verificació i l'acreditació de la propietat del domini. La comprovació rastreja els punts finals GET del mateix origen amb paràmetres de consulta, estableix una resposta de referència, cerca anomalies booleanes específiques d'SQL i només informa d'una troballa després de la confirmació del temps en diverses longituds de retard. Les exploracions del dipòsit també ajuden a detectar la causa arrel abans mitjançant code.web-app-risk-checklist-backfill, que marca les trucades SQL en brut creades amb la interpolació de plantilles.