9 Tipus populars d’atac per injecció d’aplicacions web

El problema de les aplicacions web és que estan exposades obertament a milers de milions d’usuaris d’internet, molts dels quals voldrien incomplir les seves mesures de seguretat, per qualsevol motiu..


En els primers temps d’Internet, un dels mètodes d’atac més comuns era la força bruta simple i bàsica. Els robots normalment realitzaven aquests atacs -o persones amb molt temps lliure- que intentaven milers de combinacions de noms d’usuari i contrasenyes fins a trobar un que permetria accedir a l’aplicació objectiu..

Els atacs de força bruta ja no són una amenaça, gràcies a les polítiques de contrasenya, intents limitats d’inici de sessió i captcha. Però als ciberdelinqüents els agrada descobrir noves gestes i fer-les servir per realitzar nous tipus d’atacs. Fa molt de temps van descobrir que els camps de text en aplicacions o pàgines web es podrien explotar introduint-hi o injectant-hi un text inesperat que obligaria l’aplicació a fer alguna cosa que no se suposa. D’aquesta manera, van entrar en escena els anomenats atacs d’injecció.

Els atacs d’injecció es poden utilitzar no només per iniciar sessió en una aplicació sense conèixer nom d’usuari i contrasenya, sinó també per exposar informació privada, confidencial o sensible, o fins i tot per segrestar un servidor complet. És per això que aquests atacs no només són una amenaça per a les aplicacions web, sinó també per als usuaris les dades de les quals es troben en aquestes aplicacions i, en el pitjor dels casos, per a altres aplicacions i serveis connectats..

Injecció de codi

La injecció de codi és un dels tipus més habituals d’atacs per injecció. Si els atacants coneixen el llenguatge de programació, el marc, la base de dades o el sistema operatiu utilitzat per una aplicació web, poden injectar codi mitjançant camps d’entrada de text per obligar el servidor web a fer el que vulguin..

Aquests tipus d’atacs per injecció són possibles en aplicacions que no tenen validació de dades d’entrada. Si un camp d’entrada de text permet als usuaris introduir tot el que vulguin, l’aplicació és potencialment explotable. Per evitar aquests atacs, l’aplicació ha de restringir-se tant com pot permetre als usuaris d’entrada.

Per exemple, ha de limitar la quantitat de dades esperades, comprovar el format de les dades abans d’acceptar-les i restringir el conjunt de caràcters permesos.

La vulnerabilitat de la injecció de codi pot ser fàcil de trobar, només provant l’entrada de text d’una aplicació web amb diferents tipus de contingut. Quan es troben, les vulnerabilitats són moderadament difícils d’explotar. Però quan un atacant aconsegueix explotar una d’aquestes vulnerabilitats, l’impacte podria incloure pèrdua de confidencialitat, integritat, disponibilitat o funcionalitat de l’aplicació..

Injecció SQL

De manera similar a la injecció de codi, aquest atac insereix un script SQL –el llenguatge utilitzat per la majoria de bases de dades per realitzar operacions de consulta– en un camp d’introducció de text. El guió s’envia a l’aplicació, que l’executa directament a la seva base de dades. Com a resultat, l’atacant podria passar per una pantalla d’inici de sessió o fer coses més perilloses, com llegir dades sensibles directament de la base de dades, modificar o destruir dades de la base de dades, o executar operacions d’administració a la base de dades..

Les aplicacions PHP i ASP són propenses a atacs d’injecció de SQL a causa de les seves interfícies funcionals més antigues. Les aplicacions J2EE i ASP.Net solen estar més protegides contra aquests atacs. Quan es detecta una vulnerabilitat d’injecció SQL –i es poden trobar fàcilment–, la habilitat i la imaginació de l’atacant només es limitaran a la magnitud dels atacs possibles. Per tant, l’impacte d’un atac d’injecció SQL és sens dubte alt.

Injecció de comandaments

Aquests atacs també són possibles, principalment a causa d’una validació d’entrada insuficient. Difereixen dels atacs d’injecció de codi, ja que l’atacant insereix ordres del sistema en lloc de codis de programació o guions. Per tant, el pirata informàtic no necessita conèixer el llenguatge de programació en què es basa l’aplicació ni el llenguatge que utilitza la base de dades. Però necessiten conèixer el sistema operatiu que utilitza el servidor d’allotjament.

Les ordres del sistema inserides són executades pel sistema operatiu amfitrió amb els privilegis de l’aplicació, que podrien permetre exposar el contingut dels fitxers arbitraris residents al servidor, per mostrar l’estructura de directori d’un servidor, per canviar contrasenyes d’usuari, entre altres coses..

Un sistema sysadmin pot prevenir aquests atacs, limitant el nivell d’accés al sistema de les aplicacions web que s’executen en un servidor.

Escriptura de llocs creuats

Sempre que una aplicació insereix entrada d’un usuari dins de la sortida que genera, sense validar-la ni codificar-la, dóna l’oportunitat a un atacant d’enviar codi maliciós a un usuari final diferent. Els atacs d’escriptura entre llocs (XSS) aprofiten aquestes oportunitats per injectar scripts maliciosos a llocs web de confiança, que s’envien finalment a altres usuaris de l’aplicació, que esdevenen víctimes de l’atacant..

El navegador de les víctimes executarà el guió maliciós sense saber que no s’hauria de confiar. Per tant, el navegador li permetrà accedir a fitxes de sessió, a cookies oa informació sensible emmagatzemada pel navegador. Si es programa correctament, els scripts podrien fins i tot reescriure el contingut d’un fitxer HTML.

Els atacs XSS es poden dividir generalment en dues categories diferents: emmagatzemats i reflectits.

Dins emmagatzemat Atacs XSS, el script maliciós resideix permanentment al servidor de destinació, en un fòrum de missatges, en una base de dades, en un registre de visitants, etc. La víctima ho aconsegueix quan el seu navegador sol·licita la informació emmagatzemada. Dins reflectit Atacs XSS, el script maliciós es reflecteix en una resposta que inclou l’entrada enviada al servidor. Podria ser un missatge d’error o un resultat de cerca, per exemple.

Injecció de XPath

Aquest tipus d’atac és possible quan una aplicació web utilitza informació proporcionada per un usuari per crear una consulta XPath per a dades XML. La forma en què funciona aquest atac és similar a la de la injecció SQL: els atacants envien informació malformada a l’aplicació per esbrinar com s’estructura les dades XML i, després, tornen a atacar per accedir a aquestes dades..

XPath és un llenguatge estàndard amb el qual, com SQL, podeu especificar els atributs que voleu trobar. Per realitzar una consulta sobre dades XML, les aplicacions web utilitzen l’entrada de l’usuari per configurar un patró que han de coincidir les dades. En enviar una entrada malformada, el patró pot convertir-se en una operació que l’atacant vol aplicar a les dades.

A diferència del que passa amb SQL, a XPath no hi ha versions diferents. Això significa que la injecció de XPath es pot fer en qualsevol aplicació web que utilitzi dades XML, independentment de la implementació. Això també significa que l’atac es pot automatitzar; per tant, a diferència de la injecció SQL, pot disparar contra un nombre arbitrari d’objectius.

Injecció de comandaments de correu

Aquest mètode d’atac es pot utilitzar per explotar servidors i aplicacions de correu electrònic que creen instruccions IMAP o SMTP amb una entrada d’usuari validada incorrectament. De vegades, els servidors IMAP i SMTP no tenen una protecció forta contra atacs, com seria el cas de la majoria de servidors web i, per tant, poden ser més explotables. Entrant a través d’un servidor de correu, els atacants podrien evadir restriccions com captchas, un nombre limitat de peticions, etc..

Per explotar un servidor SMTP, els atacants necessiten un compte de correu electrònic vàlid per enviar missatges amb ordres injectades. Si el servidor és vulnerable, respondrà a les peticions dels atacants, permetent-los, per exemple, substituir les restriccions del servidor i utilitzar els seus serveis per enviar correu brossa..

La injecció IMAP es pot fer principalment en aplicacions de correu web, aprofitant la funcionalitat de lectura de missatges. En aquests casos, l’atac es pot realitzar simplement introduint, a la barra d’adreces d’un navegador web, una URL amb les ordres injectades..

Injecció de CRLF

La inserció de caràcters de retorn de línia i de flux de línia –combinació coneguda com CRLF– als camps d’entrada de forma web representa un mètode d’atac anomenat injecció de CRLF. Aquests caràcters invisibles indiquen el final d’una línia o el final d’una ordre en molts protocols d’internet tradicionals, com HTTP, MIME o NNTP..

Per exemple, la inserció d’un CRLF en una sol·licitud HTTP, seguida d’alguns codis HTML determinats, podria enviar pàgines web personalitzades als visitants d’un lloc web.

Aquest atac es pot realitzar en aplicacions web vulnerables que no apliquen el filtratge adequat a l’entrada de l’usuari. Aquesta vulnerabilitat obre les portes a altres tipus d’atacs d’injecció, com XSS i injecció de codi, i també es podria derivar en segrestar un lloc web..

Injecció de capçalera de l’amfitrió

En els servidors que allotgen molts llocs web o aplicacions web, la capçalera de l’amfitrió esdevé necessària per determinar quina de les pàgines web o aplicacions web residents –aquestes, conegudes com a amfitrió virtual– ha de processar una sol·licitud entrant. El valor de la capçalera indica al servidor a quin dels host virtuals enviar una sol·licitud. Quan el servidor rep una capçalera d’amfitrió no vàlida, normalment la passa al primer host virtual de la llista. Això constitueix una vulnerabilitat que els atacants poden utilitzar per enviar capçaleres d’amfitrió arbitràries al primer host virtual d’un servidor.

La manipulació de la capçalera de l’amfitrió es relaciona habitualment amb aplicacions PHP, tot i que també es pot fer amb altres tecnologies de desenvolupament web. Els atacs de capçalera de l’amfitrió funcionen com a habilitadors per a altres tipus d’atacs, com ara la intoxicació per cache web. Les seves conseqüències poden incloure l’execució d’operacions sensibles per part dels atacants, per exemple, els restabliments de contrasenyes.

Injecció de LDAP

LDAP és un protocol dissenyat per facilitar la cerca de recursos (dispositius, fitxers, altres usuaris) en una xarxa. És molt útil per a les intranets, i quan s’utilitza com a part d’un sistema d’inici de sessió únic, es pot utilitzar per emmagatzemar noms d’usuari i contrasenyes. Les consultes LDAP impliquen l’ús de caràcters especials de control que afectin el seu control. Els atacants poden canviar el comportament previst d’una consulta LDAP si poden inserir-hi caràcters de control.

Un cop més, el problema d’arrel que permet atacs d’injecció LDAP és l’entrada de l’usuari validada de manera incorrecta. Si el text que envia un usuari a una aplicació s’utilitza com a part d’una consulta LDAP sense desinfectar-la, la consulta podria acabar recuperant una llista de tots els usuaris i mostrant-la a un atacant, només utilitzant un asterisc (*) a la dreta. col·locar dins d’una cadena d’entrada.

Prevenir atacs d’injecció

Com vam veure en aquest article, tots els atacs d’injecció es dirigeixen a servidors i aplicacions amb accés obert a qualsevol usuari d’Internet. La responsabilitat per evitar aquests atacs es distribueix entre els desenvolupadors d’aplicacions i els administradors de servidors.

Els desenvolupadors d’aplicacions han de conèixer els riscos que comporta la validació incorrecta de l’entrada dels usuaris i aprendre les bones pràctiques per desinfectar l’entrada dels usuaris amb finalitats de prevenció de riscos. Els administradors del servidor han de controlar periòdicament els seus sistemes per detectar vulnerabilitats i corregir-los tan aviat com sigui possible. Hi ha moltes opcions per realitzar aquestes auditories, tant a demanda com automàticament.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map