# Capítulo 10 - Ciberseguridad 5: Vector Aplicación y Ataques de Inyección, Parte 1

**URL:** <https://discourse.forosaluddigital.cl/t/capitulo-10-ciberseguridad-5-vector-aplicacion-y-ataques-de-inyeccion-parte-1/2287>\
**Category:** Ciberseguridad\
**Created:** [27 Agosto, 2021 16:28 UTC](https://discourse.forosaluddigital.cl/t/capitulo-10-ciberseguridad-5-vector-aplicacion-y-ataques-de-inyeccion-parte-1/2287 "2021-08-27T16:28:06Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![MATIAS\_HAEUSSLER](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.forosaluddigital.cl/matias_haeussler/32/1467_2.png) [@MATIAS\_HAEUSSLER](https://discourse.forosaluddigital.cl/u/MATIAS_HAEUSSLER)\
**Post date:** [27 Agosto, 2021 16:28 UTC](https://discourse.forosaluddigital.cl/t/capitulo-10-ciberseguridad-5-vector-aplicacion-y-ataques-de-inyeccion-parte-1/2287/1 "2021-08-27T16:28:06Z")

</div>

Buenas tardes, en este décimo capítulo de la serie _Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital_ presentaré el Vector Aplicación con respecto a sus amenazas principales y recomendaciones para evitarlas.

Particularmente veremos los ataques que interactúan directamente con la aplicación, mientras que los ataques que se enfocan en las vulnerabilidades de infraestructura serán tratados en los capítulos sobre el Vector Red.

**Ataques de Inyección**

La principal forma en la que un atacante puede afectar a una aplicación al interactuar con ella es diseñar maliciosamente sus solicitudes, de manera que sus respuestas entreguen información sensible directamente o indirectamente obtniendo control sobre la aplicación web y posiblemente del sistema operativo subyacente. Éstas estrategias son llamadas ataques de inyección y existen de distintos tipos

1. **Server Side Template Injections**

2. **XML External Entities (XXE)**

3. **Cross Site Scripting (XSS)**

4. **Insecure Deserialization**

5. **Cross Site Request Forgery (CSRF)**

**Recomendaciones**

1. **Validar creación y recepción de las solicitudes**. Cada campo de un formulario y cada solicitud recibida por el servidor web debe ser validada con el objetivo no solo de que el usuario haya cometido un error, sino que para evitar un comportamiento maligno en cada una de ellas. Esto se puede lograr limitando los valores que estas puedan tener, por ejemplo mediante expresiones regulares, restricciones de tipo, rango y de longitud.

2. **Evitar implementar formatos complejos para el envío de solicitudes como XML** para cuando sea posible, y reemplazarlos por unos más simples como JSON y cuando sea necesario verificar que su procesador de XML está actualizado, deshabilitar procesamiento XML de DTD y External Entities como explica [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) y emplear herramientas como XSD para validar las solicitudes XML.

3. **Implementar Content Security Policy**. Este método es el más fuerte para potencialmente eliminar por completo la posibilidad de XSS, sin embargo hay que tener en cuenta que este mecanismo es relativamente reciente y la mayoría de las aplicaciones no están diseñadas para implementarlo fácilmente, por lo que es recomendable realizar pruebas antes de añadirla a su aplicación.

4. Además de validar e implementar un tipado estricto para la deserialización de solicitudes, **realizar su deserialización en un ambiente sin privilegios cuando sea posible**. Los ataques de deserialización han demostrado ser robustos ante distintos tipos de medidas de prevención, por lo que es recomendable limitar el alcance de las consecuencias de su éxito. Se recomienda también registrar especialmente los resultados de la deserialización, incluyendo los casos en que resulten en errores y excepciones.

5. **Emplear tokens de autenticación en los headers en vez de en las cookies**. Los ataques CSRF dependen de que las cookies sean compartidas automáticamente en todas las solicitudes, sin embargo si la sesión no se encuentra en ellas las solicitudes privilegiadas no serán aceptadas por el servidor web. Adicionalmente la **implementación de la SameSite flag en las cookies** impediría el uso maliciosa de estas en intentos de CSRF.

En el próximo capítulo veremos las demás vulnerabilidades principales a tener en cuenta durante el desarrollo de una aplicación web, tanto en general como en salud digital

→ [Link al Capítulo anterior](https://discourse.forosaluddigital.cl/t/capitulo-9-ciberseguridad-4-vector-usuario-e-ingenieria-social-parte-2)  
→ [Link al Capítulo siguiente](https://discourse.forosaluddigital.cl/t/capitulo-11-ciberseguridad-6-vector-aplicacion-y-ataques-de-inyeccion-parte-2)

**Referencias**

1. Guía completa para evitar SQLi [https://www.youtube.com/watch?v=1nJgupaUPEQ](https://www.youtube.com/watch?v=1nJgupaUPEQ)

2. XSS [Cross Site Scripting (XSS) | OWASP Foundation](https://owasp.org/www-community/attacks/xss/)

3. CSRF y SSRF [https://resources.infosecinstitute.com/topic/the-difference-between-cross-site-and-server-side-request-forgery/](https://resources.infosecinstitute.com/topic/the-difference-between-cross-site-and-server-side-request-forgery/)

4. Explicación de Cross Origin Policy [Same-Origin Policy And Cross-Origin Resource Sharing (CORS)](https://www.hackedu.com/blog/same-origin-policy-and-cross-origin-resource-sharing-cors)

5. Cómo evitar CSRF [What is cross-site request forgery?](https://www.netsparker.com/blog/web-security/csrf-cross-site-request-forgery/)

6. OWASP Top 10 [OWASP Top Ten Web Application Security Risks | OWASP Foundation](https://owasp.org/www-project-top-ten/)

7. CWE Top 25 [CWE - CWE-1337: Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses (4.19.1)](https://cwe.mitre.org/data/definitions/1337.html)