Password Reset Poisoning: el risc ocult en la recuperació de comptes

La seguretat de la identitat digital s'ha convertit en el nou perímetre de defensa per a qualsevol organització. En aquest context, la funcionalitat de recuperació de contrasenya és un dels fluxos més sensibles de qualsevol aplicació web. Quan un usuari oblida la seva clau, el mecanisme de reseteig actua com un pont crític per recuperar l'accés. No obstant això, si aquest pont està mal construït, es converteix en la via més curta per a un atacant per aconseguir un Account Takeover (ATO), saltant-se fins i tot les contrasenyes més complexes.

L'engany del Password Reset Poisoning

El Password Reset Poisoning és una tècnica d'atac on un malintencionat manipula un lloc web vulnerable perquè generi un enllaç de recuperació de contrasenya que apunta a un domini sota el seu control. A diferència d'altres mètodes d'atac, aquí no es necessita crear una pàgina de phishing convincent ni distribuir programari malicios. L'aplicació legítima és la que fa la feina per l'atacant, enviant un correu electrònic oficial que el víctima confiarà instinctivement.

Aquest procés es basa en una vulnerabilitat d'injecció en l'encapçalament Host. Moltes aplicacions web utilitzen l'encapçalament Host de la sol·licitud HTTP per construir l'URL absoluta que s'inclou en el correu de reseteig. Si el servidor no valida aquest encapçalament contra una llista de domínis autoritzats, l'atacant pot modificar-lo per redirigir el flux de dades cap al seu propi servidor.

Mecànica tècnica de l'atac

Per entendre com es produeix aquest incident, cal analitzar el flux de comunicació entre el client i el servidor. En una situació normal, quan un usuari sol·licita un canvi de contrasenya, el servidor genera un token secret, el guarda a la base de dades i envia un correu amb un enllaç tipus https://empresa.com/reset?token=abc123xyz. L'usuari fa clic, el servidor valida el token i permet el canvi.

En un escenari de Password Reset Poisoning, l'atacant intercepta la sol·licitud de reseteig i canvia l'encapçalament Host per un domini propi, per exemple atacant.com. Si l'aplicació és vulnerable, el servidor generarà l'enllaç utilitzant aquest valor manipulat. El correu que rebrà la víctima serà totalment legítim, enviat des dels servidors de l'empresa, però l'enllaç dirà https://atacant.com/reset?token=abc123xyz.

Quan la víctima fa clic a l'enllaç, el token secret és enviat directament al servidor de l'atacant a través de la sol·licitud HTTP. Un cop obtingut aquest token, l'atacant només ha de combinar-lo amb l'URL original de l'empresa per canviar la contrasenya de l'usuari i assumir el control total del compte.

Per què fallen els sistemes de seguretat

La raó principal d'aquesta vulnerabilitat és la confiança excessiva en dades no verificades. Molts desenvolupadors assumeixen que l'encapçalament Host és una font de veritat immutable, quan en realitat és un camp que pot ser modificat fàcilment per qualsevol client HTTP. Aquest error de lògica és especialment comú en entorns on s'utilitzen servidors proxy o balancejadors de càrrega que no estan correctament configurats.

A més, l'atac pot explotar altres encapçalaments similars, com l'X-Forwarded-Host, que s'utilitzen per transmetre l'adreça original del client a través de proxies. Si l'aplicació prioritza aquests encapçalaments sobre la configuració interna del servidor, la porta queda oberta per a la manipulació. Pots trobar detalls més profunds sobre com s'explota aquest vector en la guia de Portswigger.

Estratègies de detecció i mitigació

La detecció d'aquest tipus de falls requereix proves de penetració específiques. Els equips de seguretat han de provar si l'aplicació accepta encapçalaments Host arbitraris durant el procés de recuperació de contrasenya. Una manera segura de fer-ho és utilitzar eines de proxy per interceptar la sol·licitud i canviar el domini, observant si el correu electrònic resultant reflecteix aquest canvi.

Per corregir aquesta vulnerabilitat, les empreses han de seguir aquestes directrius tècniques:

L'única manera efectiva de prevenir el Password Reset Poisoning és deixar de confiar en l'encapçalament Host per generar URLs. Les aplicacions han de basar-se en una llista blanca de domínis configurada a nivell de servidor o utilitzar una variable d'entorn fixa per a la base de l'URL.

Aquest enfocament elimina la dependència de la sol·licitud del client. Si el servidor té configurat que el domini oficial és empresa.com, qualsevol intent de canviar l'encapçalament Host serà ignorat en la construcció de l'enllaç de reseteig. Per a més detalls sobre la implementació de mecanismes segurs, és recomanable consultar la documentació de Jsmon.

L'impacte en la confiança de l'usuari

El perill més gran d'aquest atac no és només la pèrdua de dades, sinó la destrucció de la confiança. Quan un usuari rep un correu electrònic oficial d'una empresa i, en fer-hi clic, el seu compte és compromès, la percepció de seguretat de la marca s'enfonsa. No hi ha hagut un error de l'usuari (com anar a una web falsa), sinó un error de l'infraestructura de l'empresa.

Aquest tipus de vulnerabilitats demostra que la seguretat no és només una qüestió de tenir un firewall potent, sinó de revisar cada pas de la lògica de negoci. Un mecanisme de reseteig mal implementat és, sovint, el camí més curt per a un atac d'Account Takeover (ATO), saltant-se totes les capes de protecció perimetral.

Implicacions per a l'ecosistema empresarial de Catalunya i Espanya

Per a les empreses catalanes, especialment en el vibrant hub tecnològic de Barcelona, aquest tipus de vulnerabilitats té una rellevància crítica. Amb l'augment de les startups de fintech i healthtech a la regió, la gestió de la identitat es torna un actiu estratègic. La implementació de l'AI Act a la Unió Europea també empeny les empreses a adoptar estàndards de seguretat més rigorosos, ja que molts dels sistemes d'IA s'integren amb fluxos d'autenticació web que podrien ser vulnerables a aquests atacs.

En el mercat espanyol, on la transformació digital ha accelerat la migració de serveis a la núvol, moltes Pimes han adoptat solucions de programari personalitzades sense passar per auditories de seguretat profundes. El Password Reset Poisoning és un exemple clar de com una configuració incorrecta en un servidor proxy o un balancejador de càrrega pot exposar milers d'usuaris. Les empreses locals han de moure's cap a una cultura de DevSecOps, on la validació d'encapçalaments i la gestió de llistes blanques no siguin detalls secundaris, sinó requisits obligatoris de desenvolupament.

L'ecosistema d'empresa a Catalunya té l'oportunitat de liderar la implementació de patrons de disseny segurs, integrant proves de penetració automatitzades que detectin aquests errors abans que arribin a producció. En un entorn on la competició és global, la seguretat de l'usuari final és el millor argument de venda per a qualsevol producte SaaS desenvolupat a territori espanyol.

Preguntes freqüents

Fonts: Portswigger, Herish, Blogs ·