A03:2021 – Injecció

Les injeccions són un tipus de vulnerabilitat consistent en fer un enviament de dades no fiables mitjançant una petició o consulta a un intèrpret, per part d'un atacant, causant una disrupció en el flux d'execució o el comportament previst inicialment per a l'aplicació. 

D'aquesta manera, es poden arribar a realitzar accions que van des de l'extracció d'informació addicional sobre el sistema atacat, fins al robatori d'una sessió d'usuari o fins i tot l'execució remota d'ordres i la presa de control posterior del propi servidor web on es allotja l'aplicació.

Les injeccions s'han catalogat com les més crítiques i constants al llarg de les successives edicions dels OWASP Top 10, ja que poden arribar a derivar en el control absolut de la màquina objectiu. De fet, han estat al número u de la llista durant totes les edicions fins a la del 2021, on va baixar a la tercera posició.

Tipus d'injeccions

Com depèn en gran mesura, de l'intèrpret utilitzat, del llenguatge emprat o del sistema d'emmagatzematge emprat al backend del servidor, hi ha també un important nombre d'injeccions diferents que es poden donar, com són:

Inyecciones SQL (SQLi - Injeccions SQL) 

Permet la manipulació no desitjada de les dades existents a bases de dades no relacionals, modificant o alterant la informació de les dades, o bé permetent l'evasió dels sistemes d'autenticació i/o autoritzacions existents. 

Contràriament a allò que gent no experta sol opinar, aquest tipus d'injeccions no són una “cosa dels 90”. Avui dia se segueixen emprant injeccions de tipus SQL (Structured Query Language), emprats en consultes o modificacions de bases de dades relacionals. Un exemple clar ha estat fins i tot moltes vegades, com s'ha demostrat en una de les vulnerabilitats detectades al sistema TSA (Transportation Security Administration), que ha permès ignorar la seguretat de 77 aerolínies que feien servir un sistema determinat per arribar a tenir privilegis d'administració amb una de les injeccions més trivials. 

Injeccions NoSQL (NoSQLi -NoSQL injections)

Amb l'aparició de les bases de dades no relacionals, com MongoDB (on les dades queden emmagatzemades a BSON, un format de dades similar a JSON), CouchDB, o Redis, el tipus d'injecció canvia per ajustar-se a aquest tipus d'informació, però el resultat pot ser igual de devastador. 

Injeccions d'ordres (CI-Command Injections)

En aquest cas, el que s'injecten són ordres no desitjades en el sistema operatiu subjacent. 

Inyecciones LDAP (LDAPi - Ligthweight Directory Access Protocol injections)

En aquest cas, l‟explotació de la injecció ve donada per la manipulació no desitjada de consultes LDAP o Protocol Lleuger d‟Accés a Directoris, per accedir o manipular recursos de xarxa o l‟autenticació d‟usuaris que emprin aquest tipus de protocol en l‟aplicació web. 

Inyecciones XML (XMLi - injecció XML, XXE - injecció XML eXternal Entity)

En aquest cas es manipulen les peticions XML realitzades al servidor per incloure entitats no controlades, fins i tot entitats externes carregades des de la pròpia màquina atacant (en el cas de XXE), per poder llegir fitxers interns o fins i tot fer execució remota d'ordres. 

Injeccions XPath

En aquest cas s'abusarà de la manipulació de consultes XPath (llenguatge XML Path), per a l'accés o la modificació de dades, o atributs en documents XML. 

Ús de seqüència en llocs creuats (XSS - CrossSite Scripting)

En aquest tipus d'injeccions, inicialment es consideren injeccions al costat “client”, per afectar principalment la relació entra les aplicacions web i el que passa al navegador dels usuaris. 

Però aquest fet, que inicialment podria considerar-se com a no especialment rellevant, no ho és tal, si es considera que una XSS de caràcter reflectit pot portar a atacs de robatori didentitat o robatori de sessions dusuari o, en el cas dels XSS emmagatzemats , portar a comprometre una infraestructura completa i no només el defacement o la desfiguració de l'aplicatiu web. 

A més, en combinació amb un altre tipus d'atacs (l'esmentat SQLi, o altres com SSRF-Server-Side Request Forgery, CSRF o XSRF-Cross-Site Request Forgery…) poden ser especialment perillosos. 

Destaquen per la utilització de JavaScript (o llenguatges de scripting similars emprats al client, com vbscript, encara que menys freqüent avui dia) i HTML (HTMLi o HTML Injection). 

Injeccions de Plantilles del costat servidor (SSTI - Server-Side Template Injection)

Amb l'aparició de nous frameworks a servidors web com PHP, Spring a Java, Flask/Django a Python, Express (Node.js), als backends tradicionals, van sorgir certs motors populars de processament de plantilles al servidor web, com Jinja o Jinja2 (Python), Twig (PHP), Pug/Jade (Node.js), EJS (JavaScript), Freemarker (Java), etc. 

I amb ells, nous tipus d'injecció abusant d'aquestes plantilles existents, on, mitjançant la seva adequada manipulació i injecció d'ordres específiques, un atacant podria arribar a interactuar amb tot l'entorn del servidor, inclosos els fitxers o els serveis existents, o fins i tot el mateix sistema operatiu. 

Injecció ORM (injecció de mapeo relacional-objecte)

Si bé l'ús d'una capa d'abstracció emprant Orientació a Objectes és molt desitjable per evitar precisament tipus d'injecció SQL o NoSQL, evitant la construcció i la manipulació directa de cadenes SQL, una mala implementació d'ORM pot portar al descobriment d'informació de la base de dades subjacents, mitjançant l'ús de consultes dinàmiques manipulant la lògica d'aquest tipus d'objectes, de manera anàloga a com es faria amb un SQLi. 

En aquest sentit s'han descobert diverses formes d'injecció en ORMs populars com SQLAlchemy (per a Python) o Hibernate (per a Java). 

Injeccions de codi (Code Injection)

L'abús d'aquest tipus d'injeccions depèn exclusivament del tipus de llenguatge emprat per a l'execució dinàmica de codi a l'aplicació web. Per exemple, PHP (amb funcions com eval()) o Python. 

Injeccions de format de cadena (Format String Injection)

Aquí la injecció vindria donada en les funcions de format de cadena emprades per a la manipulació de dades dentrada dusuari, que permetrien la divulgació dinformació no desitjada al costat servidor, o lexecució fins i tot de codi arbitrari. 

Injeccions d'expressions regulars (Regex Injection)

L'explotació d'aquest tipus d'injeccions ve generalment donada per la laxitud en la implementació de certes expressions regulars emprades al sistema, permetent la seva manipulació per realitzar atacs d'obtenció d'informació addicional, evasió de filtres, o fins i tot atacs de denegació de servei (DoS ).

Injeccions de capçalera HTTP (HTTP Header Injection)

La injecció en aquest cas ve donada a la pròpia capçalera HTTP de les peticions enviades al servidor, permetent un altre tipus d'atacs com l'enverinament de memòria cau (Cache Poisoning) o la manipulació de cookies emprades a la sessió de l'aplicació. 

De fet, és habitual emprar un altre tipus d'injeccions esmentades dins també de les capçaleres. 

Per què passen les injeccions?

La majoria de les injeccions tenen lloc per un motiu comú, independentment del llenguatge emprat al backend, de la infraestructura desplegada o de la configuració del servidor, que motivaran l'elecció de l'ús d'uns tipus d'injecció o d'altres. 

El motiu principal és la manca de controls per a la validació de les dades d'entrada de l'usuari, així com també a la sortida (o el processament entre capes), de la informació cap al servidor.

Cal no oblidar que les peticions inicials poden ser interceptades després de passar els filtres al costat client, i manipulades per afectar igualment el servidor, sempre que no s'hagin establert controls i validacions especialment en aquest costat.

Tampoc no s'han de concebre aquest tipus d'atacs com a atacs que afecten únicament aplicacions web, i moltes d'aquestes injeccions descrites possibles (especialment SQLi) en arquitectures client-servidor no web (fins i tot on el client i el servidor es troben a la mateixa màquina) .

Mesures de mitigació

Com a recomanacions principals, es donen les següents:

• S'ha d'establir una política de confiança zero en tot allò que respecta als inputs que una aplicació pot rebre, establint una sanitització adequada, de manera que s'escapin caràcters no desitjats (evitant en la mesura del possible l'ús de llistes negres i substituir-les per les funcionalitats de seguretat quant a fuga de caràcters dependents de les tecnologies emprades). 

• Es recomana addicionalment l'ús de consultes parametritzades en cas d'accés a servidors de bases de dades, seguint les recomanacions de seguretat de cada proveïdor de bases de dades, així com de la tecnologia emprada. 

• S'han de fer les degudes abstraccions de bases de dades per evitar la construcció directa de consultes SQL mitjançant un ús correcte d'ORM (Object-Relational Mapping). 

• S'han d'implementar, amb independència de l'esmentat anteriorment, un control d'accés correcte, limitant els permisos al servidor, tant del servei web en execució, com a l'accés a la base de dades, o als directoris específics on s'està executant la aplicació, de manera que es limiti severament l'accés a altres àrees del servidor. 

D'aquesta manera, mitjançant un establiment del principi de mínim privilegi, es restringiran al màxim els passos posteriors d'un possible atacant, en cas d'haver obtingut èxit a l'explotació de qualsevol d'aquests atacs. 

• Recórrer a capes de protecció addicionals, com són l'execució d'un Web Application Firewall (WAF), amb unes regles ben definides per aturar aquest tipus d'atacs, o bloquejar possibles automatitzacions en intents d'injecció. 

Això sí, sense confiar única i cegament en aquest tipus de sistemes, que també poden ser evadits.