Compartir a través de

Desarrollo de aplicaciones seguras en Azure

En este artículo, presentamos actividades y controles de seguridad que se deben tener en cuenta al desarrollar aplicaciones para la nube. Se tratan las preguntas y conceptos de seguridad que se deben tener en cuenta durante las fases de implementación y comprobación del ciclo de vida de desarrollo de seguridad (SDL) de Microsoft. El objetivo es ayudarle a definir actividades y servicios de Azure que puede usar para desarrollar una aplicación más segura.

En este artículo se tratan las siguientes fases del SDL:

  • Implementación
  • Comprobación

Implementación

El enfoque de la fase de implementación es establecer procedimientos recomendados para la prevención temprana y detectar y quitar problemas de seguridad del código. Supongamos que la aplicación se usa de maneras que no tenía intención de usarla. Esto le ayuda a protegerse contra el uso indebido accidental o intencional de la aplicación.

Realización de revisiones de código

Antes de proteger el código, realice revisiones de código para aumentar la calidad general del código y reducir el riesgo de crear errores. Puede usar Visual Studio para administrar el proceso de revisión de código.

Realización de análisis de código estático

El análisis de código estático (también conocido como análisis de código fuente) se realiza como parte de una revisión de código. El análisis de código estático normalmente hace referencia a la ejecución de herramientas de análisis de código estático para encontrar posibles vulnerabilidades en código que no se está ejecutando. El análisis de código estático usa técnicas como la comprobación de taint y el análisis del flujo de datos.

Azure Marketplace ofrece herramientas de desarrollo que realizan análisis estáticos de código y ayudan con las revisiones de código.

Validar y sanear cada entrada de la aplicación

Trate toda la entrada como que no es de confianza para proteger la aplicación frente a las vulnerabilidades de aplicaciones web más comunes. Los datos que no son de confianza son un vehículo para ataques por inyección. La entrada de la aplicación incluye parámetros en la dirección URL, la entrada del usuario, los datos de la base de datos o de una API, y cualquier cosa que se pase en que un usuario podría manipular potencialmente. Una aplicación debe validar que los datos son sintácticas y semánticamente válidos antes de que la aplicación use los datos de cualquier manera (incluida la visualización de los datos de nuevo al usuario).

Valide la entrada al principio del flujo de datos para asegurarse de que solo los datos formados correctamente entran en el flujo de trabajo. No desea que los datos mal formados se conserven en su base de datos o que se desencadene un mal funcionamiento en un componente aguas abajo.

La inclusión en listas de bloqueados y la lista de permitidos son dos enfoques generales para realizar la validación de la sintaxis de entrada:

  • La inclusión en la lista de bloqueados intenta comprobar que una entrada de usuario determinada no contiene contenido "malintencionado".

  • La lista de permitidos intenta comprobar que una entrada de usuario determinada coincide con un conjunto de entradas "buenas conocidas". La lista de permitidos basada en caracteres es una forma de lista de permitidos en la que una aplicación comprueba que la entrada del usuario contiene solo caracteres "correctos conocidos" o que la entrada coincide con un formato conocido.

    Por ejemplo, esto podría implicar comprobar que un nombre de usuario solo contiene caracteres alfanuméricos o que contiene exactamente dos números.

El listado de permitidos es el enfoque preferido para crear software seguro. La creación de listas de bloqueo es susceptible a errores porque es imposible pensar en una lista completa de entradas potencialmente maliciosas.

Realice este trabajo en el servidor, no en el lado cliente (o en el servidor y en el lado cliente).

Comprobación de las salidas de la aplicación

Cualquier salida que presente visualmente o dentro de un documento siempre debe codificarse y escaparse. El escape, también conocido como codificación de salida, se usa para ayudar a garantizar que los datos no confiables no sean un vehículo para un ataque por inyección. El escape, combinado con la validación de datos, proporciona defensas superpuestas para aumentar la seguridad del sistema en su conjunto.

El escape garantiza que todo se muestre como salida. El escape también permite al intérprete saber que los datos no están diseñados para ejecutarse y esto evita que los ataques funcionen. Esta es otra técnica de ataque común denominada scripting entre sitios (XSS).

Si usa un marco web de un tercero, puede comprobar las opciones de codificación de salida en sitios web mediante la hoja de características clave de prevención XSS de OWASP.

Uso de consultas con parámetros al ponerse en contacto con la base de datos

Nunca cree una consulta de base de datos en línea "sobre la marcha" en el código y envíela directamente a la base de datos. El código malintencionado insertado en la aplicación podría provocar que la base de datos se robe, borre o modifique. La aplicación también puede usarse para ejecutar comandos de sistema operativo malintencionados en el sistema operativo que hospeda la base de datos.

En su lugar, use consultas con parámetros o procedimientos almacenados. Al usar consultas parametrizadas, puede invocar el procedimiento desde su código de forma segura y pasarle una cadena sin preocuparse de que se tratará como parte de la sentencia de consulta.

Eliminación de encabezados de servidor estándar

Los encabezados como Server, X-Powered-By y X-AspNet-Version revelar información sobre el servidor y las tecnologías subyacentes. Se recomienda suprimir estos encabezados para evitar la huella digital de la aplicación. Consulte eliminación de encabezados de servidor estándar en sitios web de Azure.

Separar los datos de producción

Los datos de producción o los datos "reales" no deben usarse para el desarrollo, las pruebas ni ningún otro propósito que no sea el previsto para la empresa. Se debe usar un conjunto de datos enmascarado (anónimo) para todo el desarrollo y las pruebas.

Esto significa que menos personas tienen acceso a los datos reales, lo que reduce la superficie expuesta a ataques. También significa que menos empleados ven datos personales, lo que elimina una posible vulneración de confidencialidad.

Implementación de una directiva de contraseña segura

Para defenderse contra la adivinación basada en diccionarios y por fuerza bruta, debe implementar una directiva de contraseña segura para asegurarse de que los usuarios creen una contraseña compleja (por ejemplo, 12 caracteres de longitud mínima y que requieran caracteres alfanuméricos y especiales).

El Id. externa de Microsoft Entra en inquilinos externos le ayuda con la administración de contraseñas, ya que proporciona restablecimiento de contraseña de autoservicio y mucho más.

Para defenderse contra ataques en cuentas predeterminadas, compruebe que todas las claves y contraseñas se pueden reemplazar y que se generan o reemplazan después de instalar los recursos.

Si la aplicación debe generar automáticamente contraseñas, asegúrese de que las contraseñas generadas son aleatorias y que tienen una entropía alta.

Validación de cargas de archivos

Si la aplicación permite cargas de archivos, tenga en cuenta las precauciones que puede tomar para esta actividad de riesgo. El primer paso de muchos ataques es obtener código malintencionado en un sistema que está bajo ataque. El uso de una carga de archivos ayuda al atacante a hacerlo. OWASP ofrece soluciones para validar un archivo para asegurarse de que el archivo que está cargando es seguro.

La protección antimalware ayuda a identificar y eliminar virus, spyware y otro software malintencionado. Puede instalar Microsoft Antimalware o una solución de protección de puntos de conexión de un asociado de Microsoft (Trend Micro, Broadcom, McAfee, Antivirus de Microsoft Defender en Windows y Endpoint Protection).

Microsoft Antimalware incluye características como la protección en tiempo real, el examen programado, la corrección de malware, las actualizaciones de firma, las actualizaciones del motor, los informes de ejemplos y la recopilación de eventos de exclusión. Puede integrar soluciones de asociados y Microsoft Antimalware con Microsoft Defender para la nube para facilitar la implementación y las detecciones integradas (alertas e incidentes).

No almacenar en caché contenido confidencial

No almacene en caché contenido confidencial en el explorador. Los exploradores pueden almacenar información para el almacenamiento en caché y el historial. Los archivos almacenados en caché se almacenan en una carpeta como la carpeta Archivos de Internet temporales, en el caso de Internet Explorer. Cuando se vuelve a hacer referencia a estas páginas, el explorador muestra las páginas de su caché. Si se muestra información confidencial (dirección, detalles de tarjeta de crédito, número de seguridad social, nombre de usuario) al usuario, es posible que la información se almacene en la memoria caché del explorador y se pueda recuperar examinando la memoria caché del explorador o presionando el botón Atrás del explorador.

Comprobación

La fase de comprobación implica un esfuerzo completo para garantizar que el código cumpla los principios de seguridad y privacidad establecidos en las fases anteriores.

Búsqueda y corrección de vulnerabilidades en las dependencias de la aplicación

Examine la aplicación y sus bibliotecas dependientes para identificar los componentes vulnerables conocidos. Los productos que están disponibles para realizar este análisis incluyen OWASP Dependency Check, Snyk y Black Duck.

Prueba de la aplicación en un estado operativo

Las pruebas dinámicas de seguridad de aplicaciones (DAST) son un proceso de prueba de una aplicación en un estado operativo para encontrar vulnerabilidades de seguridad. Las herramientas DAST analizan programas mientras se ejecutan para encontrar vulnerabilidades de seguridad, como daños en la memoria, configuración de servidor no segura, scripting entre sitios, problemas de privilegios de usuario, inyección de código SQL y otros problemas de seguridad críticos.

DAST es diferente de las pruebas de seguridad de aplicaciones estáticas (SAST). Las herramientas de SAST analizan el código fuente o las versiones compiladas del código cuando el código no se está ejecutando para encontrar errores de seguridad.

Realice DAST, preferiblemente con la ayuda de un profesional de seguridad ( un evaluador de penetración o un evaluador de vulnerabilidades). Si un profesional de seguridad no está disponible, puede realizar DAST usted mismo con un escáner de proxy web y algún entrenamiento. Conecte un escáner DAST al principio para asegurarse de que no introduce problemas de seguridad obvios en el código. Consulte el sitio de OWASP para obtener una lista de escáneres de vulnerabilidades de aplicaciones web.

Realizar pruebas de vulnerabilidad ante datos aleatorios o inesperados

En las pruebas de fuzzing, se provoca un fallo en el programa mediante la introducción deliberada de datos incorrectos o aleatorios a una aplicación. La inducción del error del programa ayuda a revelar posibles problemas de seguridad antes de que se publique la aplicación.

Detección de riesgos de seguridad es el servicio de pruebas aproximadas único de Microsoft para encontrar errores críticos para la seguridad en el software.

Realización de una revisión de la superficie expuesta a ataques

Revisar la superficie expuesta a ataques después de la finalización del código ayuda a garantizar que se haya considerado cualquier cambio de diseño o implementación en una aplicación o sistema. Ayuda a garantizar que los nuevos vectores de ataque que se crearon como resultado de los cambios, incluidos los modelos de amenazas, se han revisado y mitigado.

Puede crear una imagen de la superficie expuesta a ataques examinando la aplicación. Microsoft ofrece una herramienta de análisis de superficie expuesta a ataques denominada Analizador de superficie expuesta a ataques. Puede elegir entre muchas herramientas o servicios de análisis dinámicos y de vulnerabilidades comerciales, como Detector de superficie expuesta a ataques de OWASP, Arachni y w3af. Estas herramientas de escaneo rastrean tu aplicación y asignan las partes accesibles a través de la web. También puede buscar en Azure Marketplace herramientas de desarrollo similares.

Realizar pruebas de penetración de seguridad

Asegurarse de que la aplicación es segura es tan importante como probar cualquier otra funcionalidad. Realice pruebas de penetración como parte estándar del proceso de compilación e implementación. Programe pruebas de seguridad y exámenes de vulnerabilidades periódicos en las aplicaciones, y supervise si hay puertos abiertos, ataques y puntos de conexión.

Ejecución de pruebas de comprobación de seguridad

Azure Tenant Security Solution (AzTS) de Secure DevOps Kit for Azure (AzSK) contiene SVT para varios servicios de la plataforma Azure. Estos SVT se ejecutan periódicamente para asegurarse de que la suscripción de Azure y los distintos recursos que componen la aplicación están en un estado seguro. También puede automatizar estas pruebas mediante la característica de extensiones de integración continua e implementación continua (CI/CD) de AzSK, que hace que los SVT estén disponibles como una extensión de Visual Studio.

Pasos siguientes

En los artículos siguientes, se recomiendan controles de seguridad y actividades que pueden ayudarle a diseñar e implementar aplicaciones seguras.