Coders Conquer Security: Share & Learn Series - Deserialización insegura
Dependiendo de la aplicación, el proceso de serialización puede ocurrir todo el tiempo. Es el término utilizado para describir cada vez que las estructuras de datos o los estados de los objetos son traducidos a un formato que puede ser almacenado o posiblemente enviado como una comunicación. La deserialización es lo contrario de este proceso, tomando los datos ahora estructurados y convirtiéndolos de nuevo en el objeto o cadena de datos que era antes del almacenamiento.
La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas como inyecciones de código, ataques de denegación de servicio o simplemente cambiar los datos para obtener alguna ventaja dentro de la aplicación, como bajar el precio de un objeto o elevar sus privilegios.
En este episodio aprenderemos:
- Cómo los atacantes pueden explotar la deserialización insegura
- Por qué es peligrosa la deserialización insegura
- Técnicas que pueden solucionar esta vulnerabilidad.
¿Cómo aprovechan los atacantes la deserialización insegura?
Hoy en día, el formato de datos más popular para serializar datos es JSON, aunque XML le sigue de cerca. Bastantes lenguajes de programación también ofrecen sus propios métodos para serializar datos, que a menudo contienen más características que JSON o XML. En cualquier caso, pueden surgir problemas si los desarrolladores programan las aplicaciones para tratar los datos deserializados como una entrada de confianza, en lugar de seguir el viejo mantra de otros blogs de esta serie, concretamente "¡Nunca confíes en la entrada del usuario!"
La entrada del usuario nunca es de confianza porque el usuario puede insertar código en esas cadenas, que podría ser ejecutado accidentalmente por el servidor receptor. Y dado que los datos crudos deserializados también pueden ser accedidos y explotados en ocasiones, tienen que entrar en esa misma categoría de no confianza.
Por ejemplo, si una aplicación de foro utiliza la serialización de objetos PHP para guardar una cookie que contiene la identificación y el rol de un usuario, entonces eso puede ser manipulado. Un usuario malicioso podría cambiar su rol de "usuario" por el de "administrador". O puede utilizar la apertura proporcionada por la cadena de datos para inyectar código, que podría ser malinterpretado y ejecutado por el servidor mientras procesa los datos "de confianza".
¿Por qué es peligrosa la deserialización insegura?
Es cierto que este tipo de ataque requiere un mínimo de habilidad por parte de un hacker, y a veces ensayo y error mientras el atacante aprende qué tipo de código o exploits aceptará el servidor a partir de sus datos manipulados y deserializados. Dicho esto, se trata de una vulnerabilidad comúnmente explotada debido al poder potencial que otorga a los hackers lo suficientemente hábiles como para utilizarla.
Dependiendo de cómo se supone que se usen los datos deserializados, se puede emplear cualquier número de ataques, incluyendo muchos de los que hemos cubierto en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código cruzado, scripting entre sitios, denegación de servicio, secuestro de control de acceso y, por supuesto, ataques de inyección SQL y XML. Básicamente abre un punto de lanzamiento, declara que todos los datos que se están deserializando son de confianza, y deja que los atacantes intenten explotarlo.
Eliminación de la deserialización insegura
Lo más seguro que pueden hacer las organizaciones para evitar la deserialización insegura es restringir las aplicaciones para que no acepten datos deserializados. Sin embargo, eso puede no ser posible o realista, pero no hay que preocuparse, porque hay otras técnicas que se pueden emplear para defenderse de este tipo de ataques.
Si es posible, los datos pueden ser saneados a algo como valores numéricos. Esto podría no detener totalmente un exploit, pero evitaría que se produzcan inyecciones de código. Aún mejor es simplemente requerir algún tipo de comprobación de integridad contra los datos deserializados, como una firma digital, que podría asegurar que las cadenas de datos no han sido manipuladas. Y todos los procesos de deserialización deben ser aislados y ejecutados en un entorno de bajo privilegio.
Una vez que tenga esas protecciones, asegúrese de registrar todos los intentos fallidos de deserialización, así como la actividad de la red que provenga de contenedores o servidores que deserialicen datos. Si un usuario desencadena más de un par de errores de deserialización en los registros, es un buen indicio de que se trata de una persona malintencionada o de que sus credenciales han sido pirateadas o robadas. Incluso se puede considerar la posibilidad de bloquear automáticamente a los usuarios que provocan constantemente errores de deserialización.
Cualquiera de estas herramientas que emplees para luchar contra la deserialización insegura, recuerda que en el fondo se trata de datos que podrían haber sido tocados o manipulados por un usuario. Nunca confíes en ellos.
Más información sobre el uso de componentes con vulnerabilidades conocidas
Para más información, puedes echar un vistazo a lo que dice la OWASP sobre la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con la muestra gratuita de la plataforma Secure Code Warrior , que entrena a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .


La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas como inyecciones de código, ataques de denegación de servicio o elevar sus privilegios.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónJaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.


Dependiendo de la aplicación, el proceso de serialización puede ocurrir todo el tiempo. Es el término utilizado para describir cada vez que las estructuras de datos o los estados de los objetos son traducidos a un formato que puede ser almacenado o posiblemente enviado como una comunicación. La deserialización es lo contrario de este proceso, tomando los datos ahora estructurados y convirtiéndolos de nuevo en el objeto o cadena de datos que era antes del almacenamiento.
La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas como inyecciones de código, ataques de denegación de servicio o simplemente cambiar los datos para obtener alguna ventaja dentro de la aplicación, como bajar el precio de un objeto o elevar sus privilegios.
En este episodio aprenderemos:
- Cómo los atacantes pueden explotar la deserialización insegura
- Por qué es peligrosa la deserialización insegura
- Técnicas que pueden solucionar esta vulnerabilidad.
¿Cómo aprovechan los atacantes la deserialización insegura?
Hoy en día, el formato de datos más popular para serializar datos es JSON, aunque XML le sigue de cerca. Bastantes lenguajes de programación también ofrecen sus propios métodos para serializar datos, que a menudo contienen más características que JSON o XML. En cualquier caso, pueden surgir problemas si los desarrolladores programan las aplicaciones para tratar los datos deserializados como una entrada de confianza, en lugar de seguir el viejo mantra de otros blogs de esta serie, concretamente "¡Nunca confíes en la entrada del usuario!"
La entrada del usuario nunca es de confianza porque el usuario puede insertar código en esas cadenas, que podría ser ejecutado accidentalmente por el servidor receptor. Y dado que los datos crudos deserializados también pueden ser accedidos y explotados en ocasiones, tienen que entrar en esa misma categoría de no confianza.
Por ejemplo, si una aplicación de foro utiliza la serialización de objetos PHP para guardar una cookie que contiene la identificación y el rol de un usuario, entonces eso puede ser manipulado. Un usuario malicioso podría cambiar su rol de "usuario" por el de "administrador". O puede utilizar la apertura proporcionada por la cadena de datos para inyectar código, que podría ser malinterpretado y ejecutado por el servidor mientras procesa los datos "de confianza".
¿Por qué es peligrosa la deserialización insegura?
Es cierto que este tipo de ataque requiere un mínimo de habilidad por parte de un hacker, y a veces ensayo y error mientras el atacante aprende qué tipo de código o exploits aceptará el servidor a partir de sus datos manipulados y deserializados. Dicho esto, se trata de una vulnerabilidad comúnmente explotada debido al poder potencial que otorga a los hackers lo suficientemente hábiles como para utilizarla.
Dependiendo de cómo se supone que se usen los datos deserializados, se puede emplear cualquier número de ataques, incluyendo muchos de los que hemos cubierto en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código cruzado, scripting entre sitios, denegación de servicio, secuestro de control de acceso y, por supuesto, ataques de inyección SQL y XML. Básicamente abre un punto de lanzamiento, declara que todos los datos que se están deserializando son de confianza, y deja que los atacantes intenten explotarlo.
Eliminación de la deserialización insegura
Lo más seguro que pueden hacer las organizaciones para evitar la deserialización insegura es restringir las aplicaciones para que no acepten datos deserializados. Sin embargo, eso puede no ser posible o realista, pero no hay que preocuparse, porque hay otras técnicas que se pueden emplear para defenderse de este tipo de ataques.
Si es posible, los datos pueden ser saneados a algo como valores numéricos. Esto podría no detener totalmente un exploit, pero evitaría que se produzcan inyecciones de código. Aún mejor es simplemente requerir algún tipo de comprobación de integridad contra los datos deserializados, como una firma digital, que podría asegurar que las cadenas de datos no han sido manipuladas. Y todos los procesos de deserialización deben ser aislados y ejecutados en un entorno de bajo privilegio.
Una vez que tenga esas protecciones, asegúrese de registrar todos los intentos fallidos de deserialización, así como la actividad de la red que provenga de contenedores o servidores que deserialicen datos. Si un usuario desencadena más de un par de errores de deserialización en los registros, es un buen indicio de que se trata de una persona malintencionada o de que sus credenciales han sido pirateadas o robadas. Incluso se puede considerar la posibilidad de bloquear automáticamente a los usuarios que provocan constantemente errores de deserialización.
Cualquiera de estas herramientas que emplees para luchar contra la deserialización insegura, recuerda que en el fondo se trata de datos que podrían haber sido tocados o manipulados por un usuario. Nunca confíes en ellos.
Más información sobre el uso de componentes con vulnerabilidades conocidas
Para más información, puedes echar un vistazo a lo que dice la OWASP sobre la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con la muestra gratuita de la plataforma Secure Code Warrior , que entrena a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

Dependiendo de la aplicación, el proceso de serialización puede ocurrir todo el tiempo. Es el término utilizado para describir cada vez que las estructuras de datos o los estados de los objetos son traducidos a un formato que puede ser almacenado o posiblemente enviado como una comunicación. La deserialización es lo contrario de este proceso, tomando los datos ahora estructurados y convirtiéndolos de nuevo en el objeto o cadena de datos que era antes del almacenamiento.
La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas como inyecciones de código, ataques de denegación de servicio o simplemente cambiar los datos para obtener alguna ventaja dentro de la aplicación, como bajar el precio de un objeto o elevar sus privilegios.
En este episodio aprenderemos:
- Cómo los atacantes pueden explotar la deserialización insegura
- Por qué es peligrosa la deserialización insegura
- Técnicas que pueden solucionar esta vulnerabilidad.
¿Cómo aprovechan los atacantes la deserialización insegura?
Hoy en día, el formato de datos más popular para serializar datos es JSON, aunque XML le sigue de cerca. Bastantes lenguajes de programación también ofrecen sus propios métodos para serializar datos, que a menudo contienen más características que JSON o XML. En cualquier caso, pueden surgir problemas si los desarrolladores programan las aplicaciones para tratar los datos deserializados como una entrada de confianza, en lugar de seguir el viejo mantra de otros blogs de esta serie, concretamente "¡Nunca confíes en la entrada del usuario!"
La entrada del usuario nunca es de confianza porque el usuario puede insertar código en esas cadenas, que podría ser ejecutado accidentalmente por el servidor receptor. Y dado que los datos crudos deserializados también pueden ser accedidos y explotados en ocasiones, tienen que entrar en esa misma categoría de no confianza.
Por ejemplo, si una aplicación de foro utiliza la serialización de objetos PHP para guardar una cookie que contiene la identificación y el rol de un usuario, entonces eso puede ser manipulado. Un usuario malicioso podría cambiar su rol de "usuario" por el de "administrador". O puede utilizar la apertura proporcionada por la cadena de datos para inyectar código, que podría ser malinterpretado y ejecutado por el servidor mientras procesa los datos "de confianza".
¿Por qué es peligrosa la deserialización insegura?
Es cierto que este tipo de ataque requiere un mínimo de habilidad por parte de un hacker, y a veces ensayo y error mientras el atacante aprende qué tipo de código o exploits aceptará el servidor a partir de sus datos manipulados y deserializados. Dicho esto, se trata de una vulnerabilidad comúnmente explotada debido al poder potencial que otorga a los hackers lo suficientemente hábiles como para utilizarla.
Dependiendo de cómo se supone que se usen los datos deserializados, se puede emplear cualquier número de ataques, incluyendo muchos de los que hemos cubierto en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código cruzado, scripting entre sitios, denegación de servicio, secuestro de control de acceso y, por supuesto, ataques de inyección SQL y XML. Básicamente abre un punto de lanzamiento, declara que todos los datos que se están deserializando son de confianza, y deja que los atacantes intenten explotarlo.
Eliminación de la deserialización insegura
Lo más seguro que pueden hacer las organizaciones para evitar la deserialización insegura es restringir las aplicaciones para que no acepten datos deserializados. Sin embargo, eso puede no ser posible o realista, pero no hay que preocuparse, porque hay otras técnicas que se pueden emplear para defenderse de este tipo de ataques.
Si es posible, los datos pueden ser saneados a algo como valores numéricos. Esto podría no detener totalmente un exploit, pero evitaría que se produzcan inyecciones de código. Aún mejor es simplemente requerir algún tipo de comprobación de integridad contra los datos deserializados, como una firma digital, que podría asegurar que las cadenas de datos no han sido manipuladas. Y todos los procesos de deserialización deben ser aislados y ejecutados en un entorno de bajo privilegio.
Una vez que tenga esas protecciones, asegúrese de registrar todos los intentos fallidos de deserialización, así como la actividad de la red que provenga de contenedores o servidores que deserialicen datos. Si un usuario desencadena más de un par de errores de deserialización en los registros, es un buen indicio de que se trata de una persona malintencionada o de que sus credenciales han sido pirateadas o robadas. Incluso se puede considerar la posibilidad de bloquear automáticamente a los usuarios que provocan constantemente errores de deserialización.
Cualquiera de estas herramientas que emplees para luchar contra la deserialización insegura, recuerda que en el fondo se trata de datos que podrían haber sido tocados o manipulados por un usuario. Nunca confíes en ellos.
Más información sobre el uso de componentes con vulnerabilidades conocidas
Para más información, puedes echar un vistazo a lo que dice la OWASP sobre la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con la muestra gratuita de la plataforma Secure Code Warrior , que entrena a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónJaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Dependiendo de la aplicación, el proceso de serialización puede ocurrir todo el tiempo. Es el término utilizado para describir cada vez que las estructuras de datos o los estados de los objetos son traducidos a un formato que puede ser almacenado o posiblemente enviado como una comunicación. La deserialización es lo contrario de este proceso, tomando los datos ahora estructurados y convirtiéndolos de nuevo en el objeto o cadena de datos que era antes del almacenamiento.
La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas como inyecciones de código, ataques de denegación de servicio o simplemente cambiar los datos para obtener alguna ventaja dentro de la aplicación, como bajar el precio de un objeto o elevar sus privilegios.
En este episodio aprenderemos:
- Cómo los atacantes pueden explotar la deserialización insegura
- Por qué es peligrosa la deserialización insegura
- Técnicas que pueden solucionar esta vulnerabilidad.
¿Cómo aprovechan los atacantes la deserialización insegura?
Hoy en día, el formato de datos más popular para serializar datos es JSON, aunque XML le sigue de cerca. Bastantes lenguajes de programación también ofrecen sus propios métodos para serializar datos, que a menudo contienen más características que JSON o XML. En cualquier caso, pueden surgir problemas si los desarrolladores programan las aplicaciones para tratar los datos deserializados como una entrada de confianza, en lugar de seguir el viejo mantra de otros blogs de esta serie, concretamente "¡Nunca confíes en la entrada del usuario!"
La entrada del usuario nunca es de confianza porque el usuario puede insertar código en esas cadenas, que podría ser ejecutado accidentalmente por el servidor receptor. Y dado que los datos crudos deserializados también pueden ser accedidos y explotados en ocasiones, tienen que entrar en esa misma categoría de no confianza.
Por ejemplo, si una aplicación de foro utiliza la serialización de objetos PHP para guardar una cookie que contiene la identificación y el rol de un usuario, entonces eso puede ser manipulado. Un usuario malicioso podría cambiar su rol de "usuario" por el de "administrador". O puede utilizar la apertura proporcionada por la cadena de datos para inyectar código, que podría ser malinterpretado y ejecutado por el servidor mientras procesa los datos "de confianza".
¿Por qué es peligrosa la deserialización insegura?
Es cierto que este tipo de ataque requiere un mínimo de habilidad por parte de un hacker, y a veces ensayo y error mientras el atacante aprende qué tipo de código o exploits aceptará el servidor a partir de sus datos manipulados y deserializados. Dicho esto, se trata de una vulnerabilidad comúnmente explotada debido al poder potencial que otorga a los hackers lo suficientemente hábiles como para utilizarla.
Dependiendo de cómo se supone que se usen los datos deserializados, se puede emplear cualquier número de ataques, incluyendo muchos de los que hemos cubierto en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código cruzado, scripting entre sitios, denegación de servicio, secuestro de control de acceso y, por supuesto, ataques de inyección SQL y XML. Básicamente abre un punto de lanzamiento, declara que todos los datos que se están deserializando son de confianza, y deja que los atacantes intenten explotarlo.
Eliminación de la deserialización insegura
Lo más seguro que pueden hacer las organizaciones para evitar la deserialización insegura es restringir las aplicaciones para que no acepten datos deserializados. Sin embargo, eso puede no ser posible o realista, pero no hay que preocuparse, porque hay otras técnicas que se pueden emplear para defenderse de este tipo de ataques.
Si es posible, los datos pueden ser saneados a algo como valores numéricos. Esto podría no detener totalmente un exploit, pero evitaría que se produzcan inyecciones de código. Aún mejor es simplemente requerir algún tipo de comprobación de integridad contra los datos deserializados, como una firma digital, que podría asegurar que las cadenas de datos no han sido manipuladas. Y todos los procesos de deserialización deben ser aislados y ejecutados en un entorno de bajo privilegio.
Una vez que tenga esas protecciones, asegúrese de registrar todos los intentos fallidos de deserialización, así como la actividad de la red que provenga de contenedores o servidores que deserialicen datos. Si un usuario desencadena más de un par de errores de deserialización en los registros, es un buen indicio de que se trata de una persona malintencionada o de que sus credenciales han sido pirateadas o robadas. Incluso se puede considerar la posibilidad de bloquear automáticamente a los usuarios que provocan constantemente errores de deserialización.
Cualquiera de estas herramientas que emplees para luchar contra la deserialización insegura, recuerda que en el fondo se trata de datos que podrían haber sido tocados o manipulados por un usuario. Nunca confíes en ellos.
Más información sobre el uso de componentes con vulnerabilidades conocidas
Para más información, puedes echar un vistazo a lo que dice la OWASP sobre la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con la muestra gratuita de la plataforma Secure Code Warrior , que entrena a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
Índice
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Kit de motivación para el liderazgo en ingeniería
¿Necesita ayuda para conseguir la aprobación de los responsables de ingeniería para su programa SCW? Este folleto proporciona las principales ventajas que le ayudarán a comunicar la importancia de su programa de codificación segura.
La potencia de OpenText Fortify + Secure Code Warrior
OpenText Fortify y Secure Code Warrior unen sus fuerzas para ayudar a las empresas a reducir riesgos, transformar a los desarrolladores en campeones de la seguridad y fomentar la confianza de los clientes. Más información aquí.
Recursos para empezar
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.
10 predicciones clave: Secure Code Warrior sobre la influencia de la IA y el diseño seguro en 2025
Las organizaciones se enfrentan a decisiones difíciles sobre el uso de la IA para apoyar la productividad a largo plazo, la sostenibilidad y el retorno de la inversión en seguridad. En los últimos años nos ha quedado claro que la IA nunca sustituirá por completo el papel del desarrollador. Desde las asociaciones entre IA y desarrolladores hasta las crecientes presiones (y confusión) en torno a las expectativas de seguridad por diseño, echemos un vistazo más de cerca a lo que podemos esperar durante el próximo año.
OWASP Top 10 para aplicaciones LLM: Novedades, cambios y cómo mantenerse seguro
Manténgase a la vanguardia de la seguridad de las aplicaciones LLM con las últimas actualizaciones del Top 10 de OWASP. Descubra qué hay de nuevo, qué ha cambiado y cómo Secure Code Warrior le equipa con recursos de aprendizaje actualizados para mitigar los riesgos en la IA Generativa.
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.