Estándares de codificación segura: aplicación de prácticas de codificación segura con SAST

Cuando los equipos de desarrollo usan estándares de codificación segura Para desarrollar software, el resultado es menos errores de seguridad y, en última instancia, una mejor calidad que conduce a una experiencia más sólida tanto para los desarrolladores como para los usuarios. En este blog, repasaremos los conceptos básicos de los estándares de codificación segura, las mejores prácticas y cómo y cuándo usarlos.

Cómo funciona la codificación segura

La codificación segura significa que los desarrolladores aplican un conjunto de estándares de codificación o pautas de codificación segura que implementan en el código fuente para prevenir y mitigar vulnerabilidades comunes que a menudo conducen a ataques cibernéticos. La implementación de prácticas de codificación seguras en el código es la primera línea de defensa que protege contra los delincuentes que explotan el software y que elimina las superficies de ataque a las que los adversarios suelen atacar con malware. Cuando las organizaciones se adhieren religiosamente a las mejores prácticas de codificación segura, pueden reducir el costo de mantenimiento del software y los desarrolladores pueden dedicar más tiempo a innovar, en lugar de dedicar tiempo a la corrección de errores.

Las prácticas de codificación segura garantizan que los controles de seguridad se implementen en el código para reducir los problemas de seguridad que pueden manifestarse como resultado de un código mal desarrollado. Es imperativo que las organizaciones formalicen prácticas de codificación seguras para establecer un conjunto mínimo de estándares de seguridad de software sobre cómo los desarrolladores deben escribir código, que la organización puede hacer cumplir y validar con sistemas automatizados. análisis estático or pruebas de seguridad de aplicaciones estáticas (SAST) instrumentos. Estas herramientas utilizan reglas y verificadores que analizan el código fuente en busca de violaciones de sintaxis, variables no definidas, calidad del código, violaciones de codificación y seguridad y errores de programación (por nombrar algunos).

Las herramientas de análisis estático de Parasoft emplean estándares de codificación segura como CERT estándares de codificación, OWASP Top 10 (parte de las pautas de codificación segura de OWASP), enumeración de debilidades comunes de MITRE (CWE), y Seguridad y desarrollo de aplicaciones DISA STIGS en reglas y damas como se muestra en la Tabla 1.

Nombre estándar de codificación	Mantenido por	Resumen del propósito
CERT (Equipo de respuesta a emergencias informáticas)	Centro de Coordinación CERT	Directrices para ayudar a los desarrolladores a evitar errores durante la codificación y la implementación, y también a detectar errores de bajo nivel en el diseño.
OWASP Top Ten	Fundación OWASP (Proyecto de seguridad de aplicaciones web abiertas)	Los desarrolladores de software y aplicaciones web utilizan estos estándares para identificar y remediar riesgos de alta seguridad en las aplicaciones web.
CWE (enumeración de debilidades comunes)	Comunidad desarrollada y mantenida.	Este es un sistema de categorías que ayuda a los desarrolladores a identificar vulnerabilidades y debilidades en el software, y les ayuda a comprender las fallas del software. Los desarrolladores también usan el sistema para desarrollar herramientas para corregir y prevenir fallas.
Seguridad y desarrollo de aplicaciones DISA STIGS	Agencia de Sistemas de Información de Defensa (DISA) y división del Departamento de Defensa de los Estados Unidos.	Ayuda a gerentes, diseñadores, desarrolladores y administradores de sistemas a desarrollar y mantener controles de seguridad en aplicaciones y desarrollo de aplicaciones.

Las malas prácticas de codificación provocan problemas de seguridad

Los desarrolladores deben ser conscientes de las consecuencias de sus actividades de codificación y refactorización al crear y exponer vulnerabilidades en el software. Las siguientes son algunas cosas comunes que podrían salir mal cuando los desarrolladores no siguen y usan prácticas de codificación seguras. Realizamos un seguimiento de las mejores prácticas para mitigar y remediar estos problemas de seguridad.

Problema: inyección SQL

Esto sucede cuando un atacante inyecta información de forma insegura en una consulta SQL, muchas veces a través de una cadena de cadenas básica. La inyección de SQL es un riesgo de seguridad altamente peligroso para las aplicaciones porque es relativamente fácil de usar incorrectamente y puede llevar al explotador a modificar, limpiar o robar toda la base de datos. Los atacantes también pueden usar la aplicación para ejecutar comandos peligrosos en el sistema operativo que aloja la base de datos, lo que le da acceso a su red.

Problema: Autenticación y gestión de sesiones rotas

Los desarrolladores a menudo implementan incorrectamente las tareas de la aplicación asociadas con la administración y autenticación de sesiones. Esto permite a los atacantes comprometer claves, contraseñas y tokens de sesión y permitir que los malos actores utilicen las identidades de los usuarios en su beneficio.

Problema: Control de acceso roto

Los sistemas a menudo no hacen cumplir correctamente lo que los usuarios autenticados pueden hacer. Los malos actores pueden usar tales fallas para obtener acceso a la funcionalidad y los datos, por ejemplo, a las cuentas y archivos de los usuarios, para modificar los datos o para cambiar los permisos de acceso.

Problema: Secuencias de comandos entre sitios (XSS)

Esto ocurre siempre que la aplicación permite que datos sospechosos ingresen a una nueva página web sin la autenticación adecuada. XSS permite a los piratas informáticos implementar scripts en el navegador del objetivo. Los scripts pueden destrozar sitios web o enviar a los usuarios a sitios maliciosos y apoderarse de las sesiones de los usuarios.

Mejores prácticas de código de seguridad

El aumento de los ataques cibernéticos atribuidos a un software poco desarrollado hace que sea esencial que los desarrolladores se adhieran a prácticas de codificación seguras. Cuando lo hacen, mejoran la productividad y ayudan a acelerar la entrega de software porque hay menos problemas de seguridad que abordar. Esto aumenta la probabilidad de que se apruebe la compilación. Cuando se aprueba una compilación, significa que se han resuelto todas las severidades críticas y altas y que no existe un riesgo significativo para la organización. Por ejemplo, una organización podría definir umbrales (en términos de gravedad) y / o identificar problemas específicos que no son negociables y, si se identifican, interrumpirá la construcción hasta que se resuelvan los problemas.

Una forma de garantizar que se apruebe una compilación es hacer cumplir las prácticas de codificación segura y la validación del cumplimiento con análisis estático como parte de las pruebas automatizadas. Las siguientes son buenas prácticas de seguridad que los desarrolladores pueden seguir como parte de la codificación segura.

Para mitigar la inyección de SQL

Usar configuración segura

A menudo, los sistemas de administración de bases de datos no incluyen un componente seguro por defecto. Los desarrolladores deben asegurarse de que los controles de seguridad en la plataforma de alojamiento y el Sistema de gestión de bases de datos (DBMS) funcionen y estén configurados correctamente. Existen guías, estándares y puntos de referencia para los DBMS más populares. La hoja de referencia de la base de datos proporciona una guía rápida para desarrollar una configuración segura.

Usar autenticación segura

Autenticar adecuadamente todos los accesos a una base de datos. Utilice un método seguro para autenticar el DBMS. Solo autentíquese a través de un canal seguro y asegure las credenciales correctamente antes de ponerlas a disposición. Consulte la Hoja de referencia de la base de datos para obtener más información.

Utilice una comunicación segura

Casi todos los DBMS admiten una variedad de métodos para comunicarse, como API, servicios, etc., tanto inseguros (no cifrados o no autenticados) como seguros (cifrados o autenticados). Es aconsejable que los desarrolladores utilicen solo las opciones de comunicación segura disponibles con Protect Data Everywhere (ver más abajo). La hoja de referencia de la base de datos brinda asistencia rápida para brindar una comunicación segura.

Para mitigar la autenticación rota y la administración de sesiones

NIST 800-63b define tres niveles de seguridad de autenticación, también conocido como AAL o niveles de garantía de autenticación.

Nivel 1: contraseñas

El nivel 1 es para aplicaciones de bajo riesgo que no contienen PII (información de identificación personal). Solo requiere una ID de factor único, generalmente una contraseña.

Las mejores prácticas incluyen:

• Emplear contraseñas con no menos de 8 caracteres, si usamos MFA (autenticación multifactor); 10 caracteres si no usamos MFA.
• Uso de todos los caracteres ASCII imprimibles, además del carácter de espacio.
• Promocionar el uso de contraseñas y contraseñas largas.
• Eliminando requisitos de complejidad (los desarrolladores han descubierto que no son muy efectivos).
• Evitar el uso de contraseñas comunes, especialmente aquellas que se han visto comprometidas anteriormente.
• Recuperación de contraseña que implementa elementos MFA.
• Almacenamiento seguro de contraseñas mediante controles criptográficos.

Nivel 2: Autenticación multifactor

Este nivel es para aplicaciones con mayor riesgo que contienen PII, que los usuarios han proporcionado en línea. El nivel 2 de AAL requiere MFA, incluida la implementación de QTP (prueba rápida profesional). MFA certifica que un usuario es quien dice ser y requiere que la persona se identifique con dos o más de estas combinaciones:

• Un PIN o contraseña
• Un teléfono o una ficha
• Biometría, como una huella digital o una imagen facial

Nivel 3: autenticación basada en criptografía

Cuando un sistema integrado puede ocasionar pérdidas económicas sustanciales, daños personales, infracciones penales o civiles o daños considerables al interés público, se necesita una autenticación de nivel 3. Los desarrolladores suelen utilizar módulos criptográficos para lograr este sólido nivel de garantía.

Gestión de sesiones

Una aplicación puede realizar un seguimiento de la autenticación durante un período de tiempo limitado. Esto permite al usuario seguir usando la aplicación sin la necesidad de volver a autenticarse con cada solicitud. El seguimiento de esto se conoce como gestión de sesiones.

Generación y vencimiento de sesiones

El sistema rastrea el estado del usuario durante una sesión. El servidor almacena la sesión y adjunta un identificador de sesión al usuario para que la información del usuario pueda identificar la sesión que tiene los datos correctos para el usuario. El cliente simplemente mantiene el identificador, que también protege del cliente la información confidencial de la sesión del lado del servidor.

Los controles de seguridad a considerar al implementar o construir sistemas de administración de sesiones incluyen:

• Asegurarse de que la identificación de la sesión sea única, larga y aleatoria.
• Asegurarse de que la aplicación genera una nueva sesión, o al menos rota el ID de sesión durante la autenticación y la reautenticación.
• Asegurarse de que la aplicación implemente un tiempo de espera de inactividad después de un tiempo de inactividad, además de establecer una vida útil máxima para cada sesión. Después de esto, el usuario debe volver a autenticarse.

Cookies

Las aplicaciones suelen utilizar cookies del navegador para almacenar identificadores de sesión de aplicaciones web cuando los sistemas implementan métodos de gestión de sesiones. Algunas defensas son:

• Solo una pequeña cantidad de dominios debería poder acceder a las cookies. La aplicación debe etiquetar sus rutas para que las etiquetas caduquen al final, o poco después, la sesión pierde su vitalidad.
• Establecer las etiquetas "seguras" para asegurarse de que el sistema transfiera solo en un canal seguro.
• Configurar el indicador HttpOnly para evitar que JavaScript acceda a la cookie.
• Agregar características de "samesite" a las cookies, lo que impide que algunos navegadores actuales envíen cookies que tienen demandas entre sitios. Esto protege contra ataques de tipo fuga de información y falsificación de demanda entre sitios.

Tokens

Para algunos tipos de autenticación, las sesiones del lado del servidor pueden estar restringidas. Los "servicios sin estado" permiten que el sistema administre los datos de la sesión para mejorar el rendimiento. El resultado es que la carga de verificar y almacenar las sesiones de los usuarios en el servidor es menor. Una aplicación "sin estado" crea un token de acceso temporal, que el sistema utiliza para autenticar la solicitud de un cliente menos las credenciales del usuario después de la autenticación inicial.

Tokens web JSON (JWT)

Este es un estándar abierto. Es un método compacto y autónomo para transferir información de forma segura entre entidades como un elemento JSON (JavaScript Object Notation). El sistema puede verificar la información porque está firmada digitalmente. Durante la autenticación, el sistema crea un token JWT y el servidor lo verifica antes de que ocurra cualquier procesamiento.

El servidor no siempre guarda el JWT. El sistema mantiene la integridad del token con una firma digital para que un servidor posterior pueda confirmar que el JWT sigue siendo válido y que nadie lo ha corrompido desde que el sistema creó el token.

Este método es portátil y sin estado, lo que significa que las tecnologías de servidor y cliente pueden ser diferentes pero, no obstante, pueden interactuar.

Para mitigar los datos desprotegidos

Haga lo siguiente para evitar datos desprotegidos:

• Clasifique la información en la aplicación de acuerdo con el nivel de sensibilidad y asigne cada categoría de datos a la regla de protección adecuada.
• Cifre los datos que están en tránsito. Para proteger los datos de las aplicaciones web en una red, los desarrolladores suelen utilizar TLS (seguridad de la capa de transporte) configurada correctamente.
• Cifre los datos en reposo. Evite almacenar información confidencial, si es posible. Sin embargo, si debe almacenarlo, asegúrese de protegerlo criptográficamente.
• Almacenamiento local seguro en dispositivos móviles. Las personas a menudo roban o pierden dispositivos móviles, lo que hace que la información que contienen sea vulnerable a fugas. Los propietarios deben almacenar un mínimo de datos confidenciales en sus dispositivos y almacenarlos en el directorio de almacenamiento de datos especificado.
• Gestione los ciclos de vida de las claves secretas. Los desarrolladores utilizan claves secretas en aplicaciones para funciones confidenciales; por ejemplo, para proteger tarjetas de crédito y para firmar JWT. Gestione las claves correctamente mediante:
  • Asegurarse de que todas las claves secretas estén protegidas contra el uso no autorizado.
  • Usar claves independientes si se necesitan varias claves.
  • Almacenar las claves correctamente en bóvedas secretas.
  • Creación de aplicaciones para cambiar claves y algoritmos cuando sea necesario.
  • Funciones de construcción para adaptarse a la rotación de claves.
• Administra los secretos de la aplicación. Las aplicaciones tienen muchos "secretos" que las aplicaciones necesitan para funcionar de forma segura, como contraseñas, certificados y claves de cifrado. Si alguien comprometiera estos secretos, puede provocar una falla total del sistema. Para administrar los secretos de la aplicación:
  • No los pase a través de variables de entorno ni los almacene en archivos de configuración o código.
  • Guárdelos de forma segura en bóvedas de secretos.

Para mitigar el control de acceso roto

Los desarrolladores pueden considerar las siguientes medidas de control de acceso durante la etapa de diseño:

• Incluye control de acceso desde el principio. Además, permita la personalización.
• Obligue a todas las solicitudes a pasar las comprobaciones de control de acceso.
• Denegar por defecto. Si el programa no permite específicamente la solicitud, denegue.
• Implementar el "principio de privilegio mínimo". Asegúrese de que todos los programas, procesos y usuarios tengan el menor acceso posible.
• No codifique roles. Demasiados programas utilizan de forma predeterminada el control de acceso basado en roles, que es frágil y no permite reglas de control de acceso de datos múltiples y horizontales y específicas. También es difícil de auditar.
• Registre cada falla en el control de acceso. Estos pueden indicar que los explotadores están buscando debilidades en la aplicación.

Mitigación de secuencias de comandos entre sitios (XSS)

Escapar y codificar son métodos de defensa que ayudan a detener los ataques de inyección. Escapar significa que el codificador agrega un carácter específico antes de la cadena para evitar que se malinterprete. Por ejemplo, puede agregar una barra invertida (\) antes de una comilla doble (“) para que el sistema lo interprete como texto en lugar de como una señal para cerrar una cadena. La codificación, también llamada codificación de salida, significa que el desarrollador cambia los caracteres especiales a una forma diferente pero igual, lo que los hace no peligrosos en el intérprete. Por ejemplo, cambiar <por la cadena <cuando escribe en HTML.

Otros métodos de protección contra inyección incluyen la codificación de salida contextual, que los desarrolladores de codificación implementan cuando crean una interfaz de usuario; neutralizar metacaracteres específicos cuando agrega entrada a un comando de un sistema operativo; Codificación Unicode, un método para almacenar caracteres usando varios bytes; y canonización, que es cuando los sistemas transforman los datos en una forma estándar o simple.

Cómo las pruebas de seguridad de aplicaciones estáticas (SAST) ayudan a los desarrolladores a mejorar sus prácticas de codificación

Los desarrolladores de software utilizan SAST (pruebas de seguridad de aplicaciones estáticas) para ejecutar pruebas automatizadas para analizar el código fuente sin ejecutar o ejecutar el código. El objetivo es identificar infracciones de codificación y debilidades que podrían exponer vulnerabilidades de software. SAST se considera un enfoque de prueba de "caja blanca" porque tiene acceso al código fuente que documenta el diseño, el marco y cómo se implementa el sistema y / o la aplicación.

SAST utiliza los detalles documentados en el código fuente, junto con su estructura de código, para garantizar el cumplimiento de los estándares y pautas de codificación segura. SAST utiliza reglas y verificadores para hacer cumplir y validar el cumplimiento, así como para identificar violaciones de codificación en las prácticas de codificación de los desarrolladores. Los equipos de desarrollo pueden utilizar diferentes estándares y pautas de codificación segura como los estándares de codificación segura CERT y CWE al inicio del proceso de desarrollo para garantizar que el software cumpla con ciertos requisitos de calidad y seguridad.

Cabe señalar que las organizaciones de desarrollo de software maduras y de alto rendimiento utilizan estos estándares y prácticas para adaptar las políticas de seguridad y la gobernanza para los equipos de desarrollo. Muchas organizaciones agregan orientación complementaria que pueden utilizar para la capacitación y concienciación de los desarrolladores. OWASP Top 10 y los siete perniciosos Reinos desempeñan un papel clave en el aumento de la conciencia de las cosas que podrían salir mal en las prácticas de codificación.

Debido a que SAST no requiere que el software se ejecute para realizar un análisis, los desarrolladores pueden implementarlo sin problemas en sus flujos de trabajo de desarrollo existentes para analizar el código en tiempo real, señalando inmediatamente cualquier infracción de codificación que provoquen las reglas de codificación y los verificadores. El resultado es encontrar problemas críticos de calidad y seguridad dentro del flujo de trabajo del desarrollador donde el costo de arreglar y remediar los problemas de seguridad es el más económico. Esto da como resultado un software de mayor calidad con menos problemas de seguridad o vulnerabilidades, lo que permite a las organizaciones ganar confianza para acelerar la implementación y entrega de software.

Si bien la integración de SAST en los flujos de trabajo de los desarrolladores ayuda a los desarrolladores a clasificar sus violaciones de codificación, SAST también puede integrarse sin problemas en una canalización automatizada para analizar las confirmaciones de código antes de que el software se publique en producción. Cada confirmación puede activar automáticamente un escaneo desde una herramienta SAST.

Las herramientas de Parasoft SAST aprovechan AI / ML para el escaneo incremental, que solo analiza el código que cambió como parte de ese compromiso. Esto permite un uso más eficiente de SAST y proporciona a las organizaciones de desarrollo una vista histórica de los escaneos. La integración de SAST en el proceso de CI / CD es una parte esencial para crear un código seguro, confiable y de calidad durante la integración y antes de la entrega final. Satisface el concepto de aseguramiento continuo del software, donde las prácticas de aseguramiento del software se automatizan en actividades de desarrollo para garantizar la implementación y entrega del software a gran velocidad.