Traemos a su atención los 10 controles proactivos principales para los desarrolladores de software: 10 aspectos de seguridad en los que los desarrolladores de software deben centrarse. Este artículo contiene una lista de técnicas de seguridad que se deben implementar al desarrollar cada nuevo proyecto.
El software protegido de manera inadecuada socava la seguridad de las instalaciones de infraestructura crítica, como la atención médica, la defensa, la energía o las finanzas. Nuestra infraestructura digital global se está volviendo más compleja, el número de relaciones entre sus componentes está aumentando, por lo que la importancia de la seguridad de las aplicaciones está creciendo exponencialmente. Las amenazas de seguridad relativamente simples ya no se pueden ignorar.
OWASP
Open Web Application Security Project (OWASP) es un proyecto de seguridad de aplicaciones web de código abierto. La comunidad OWASP incluye corporaciones, organizaciones educativas e individuos de todo el mundo. OWASP está trabajando en artículos, tutoriales, documentación, herramientas y tecnologías de acceso público.
El proyecto OWASP está referenciado por muchos estándares, herramientas y organizaciones, incluidos MITRE, PCI DSS, DISA, FTC y muchos otros.
El proyecto Proactive Defense: Top-10 Requisitos de OWASP es similar al proyecto
OWASP Top-10 , pero se centra en métodos y recomendaciones para protegerse contra amenazas, y no en las amenazas mismas. Cada método y recomendación en este documento está asociado con una o más amenazas de la lista Top-10 de OWASP.
Metas y objetivos
El objetivo del proyecto Proactive Defense: OWASP Top 10 Requisitos es llamar la atención sobre la seguridad de las aplicaciones abordando los aspectos más importantes de la seguridad de la información que los desarrolladores de software deberían considerar. Alentamos a las organizaciones a aprovechar las recomendaciones de defensa proactiva de OWASP y enseñar a los desarrolladores cómo prestar atención a la seguridad de las aplicaciones, dando importancia a los errores que han ocurrido en otras organizaciones. Esperamos que las recomendaciones de OWASP le sean útiles al crear aplicaciones seguras.
Público objetivo
El documento está destinado principalmente a desarrolladores. Sin embargo, será útil para los gerentes de desarrollo, gerentes de producto, especialistas en garantía de calidad, gerentes de proyectos, así como para otros participantes en el proceso de creación de software.
Los 10 principales requisitos de defensa proactiva
C1: Definición de requisitos de seguridad.
Los requisitos de seguridad describen las funciones que deben implementarse para proporcionar ciertas configuraciones de seguridad de software. Se basan en estándares de la industria, leyes aplicables y datos de vulnerabilidad. Los requisitos definen funciones que deben desarrollarse o desarrollarse para resolver problemas de seguridad específicos o eliminar amenazas potenciales.
El estándar de certificación de seguridad de aplicaciones (ASVS) de OWASP es un catálogo de requisitos de seguridad y opciones de verificación disponibles. OWASP ASVS puede proporcionar requisitos de seguridad avanzados para los equipos de desarrollo.
Los requisitos de seguridad se clasifican según las funciones de seguridad comunes de nivel superior. Por ejemplo, ASVS contiene las siguientes categorías: autenticación, control de acceso, manejo y registro de errores, y servicios web. Para cada categoría hay una lista de parámetros que se recomienda verificar.
El proceso de aplicar con éxito los requisitos de seguridad incluye cuatro etapas: búsqueda y selección, documentación, implementación, confirmación de la implementación correcta de nuevas funciones de seguridad y funcionalidad de la aplicación.
C2: uso de marcos y bibliotecas seguras
Las bibliotecas y los marcos seguros con funciones de seguridad integradas ayudan a los desarrolladores a evitar vulnerabilidades durante las fases de desarrollo e implementación. Los desarrolladores que crean una aplicación desde cero pueden no tener suficiente conocimiento, tiempo o dinero para implementar o mantener la seguridad de la aplicación. El uso de marcos seguros puede aumentar el nivel de seguridad de la aplicación.
Cuando incluye bibliotecas o marcos de terceros en su software, se deben considerar las siguientes recomendaciones:
- Utilice bibliotecas y marcos de fuentes confiables que se desarrollen activamente y se utilicen ampliamente en aplicaciones;
- compilar y mantener actualizado el catálogo de todas las bibliotecas de terceros;
- Mantenga las bibliotecas y los componentes actualizados. Use herramientas como OWASP y Retire.JS Dependency Checks para determinar dependencias en proyectos, y también verifique vulnerabilidades conocidas y publicadas en código de terceros;
- Use la encapsulación de la biblioteca y solo la funcionalidad necesaria para que su software reduzca la probabilidad de ataques.
C3: proporcionar acceso seguro a bases de datos
Esta sección está dedicada a proporcionar acceso seguro a todos los almacenes de datos, incluidas las bases de datos relacionales y las bases de datos NoSQL.
Una de las amenazas más graves para la seguridad de las aplicaciones es la inyección SQL. Este tipo de ataque es fácil de implementar: el código SQL se puede inyectar si la entrada no confiable se agrega dinámicamente a las consultas SQL, lo que generalmente ocurre al adjuntarlas a la línea principal. La explotación de esta vulnerabilidad podría conducir al robo, eliminación o alteración de bases de datos. La aplicación también se puede utilizar para ejecutar comandos maliciosos en un sistema que contiene su base de datos, lo que permitirá que un atacante se establezca en la red.
Para evitar inyecciones SQL, debe evitar interpretar la entrada no verificada como parte de los comandos SQL. La mejor solución sería utilizar el método de "parametrización de consultas". Este método debe aplicarse a construcciones SQL y OQL, así como a procedimientos almacenados.
Se pueden encontrar ejemplos de parametrización de consultas para ASP, ColdFusion, C #, Delphi, .NET, Go, Java, Perl, PHP, PL / SQL, PostgreSQL, Python, R, Ruby y Scheme en
http://bobby-tables.com y en la
nota OWASP para la parametrización de consultas .
C4: Codificación y blindaje de datos
La codificación y el escape son métodos de protección contra la inyección de código. La codificación, también llamada "codificación de salida", es la conversión de caracteres especiales en combinaciones equivalentes que no son peligrosas para el intérprete. Por ejemplo, el carácter <se convierte en una combinación <cuando se agrega a una página HTML. Escapar consiste en agregar caracteres especiales delante de caracteres o líneas para evitar que se interpreten incorrectamente, por ejemplo, agregar \ before "(comillas dobles) le permite interpretarlos como parte del texto y no como un terminador de línea.
La codificación se aplica mejor inmediatamente antes de pasar los datos al intérprete. Si aplica este método demasiado pronto en el procesamiento de la solicitud, la codificación o protección puede afectar el uso de contenido en otras partes del programa. Por ejemplo, si el contenido HTML se escapa antes de guardarse en la base de datos, y la interfaz vuelve a escapar automáticamente de estos datos, el contenido no se mostrará correctamente debido al doble escape.
La codificación o el escape pueden usarse para evitar otras formas de incrustación en el contenido. Por ejemplo, puede neutralizar algunos metacaracteres especiales al ingresar datos para los comandos del sistema. Esto se llama "comandos de escape del sistema operativo", "shell de escape", etc. Dicha protección se puede utilizar para evitar la "inyección de comandos".
Hay otras formas de escape que se pueden usar para evitar inyecciones, como escapar de los atributos XML para proteger contra diversas formas de incrustaciones de rutas XML y XML, y escapar de nombres LDAP únicos para evitar varias inyecciones LDAP.
C5: verificación obligatoria de todas las entradas
La validación de los datos de entrada es parte de una técnica de programación que garantiza que solo los datos formateados correctamente entren en los componentes del programa.
Norma sintáctica y semántica
La aplicación debe verificar que los datos cumplan con la norma sintáctica y semántica (en ese orden) antes de usarlos (incluida la visualización al usuario).
La norma sintáctica significa que los datos coinciden con la presentación esperada. Por ejemplo, en una aplicación, un usuario puede especificar un "identificador" de cuatro dígitos para realizar ciertas operaciones. Un atacante puede ingresar datos que le permitan inyectar código SQL, por lo que la aplicación debe verificar que los datos ingresados sean exactamente números y exactamente la cantidad de cuatro caracteres (además de usar la parametrización de consulta adecuada).
La norma semántica significa el uso de solo datos de entrada que no van más allá de una determinada funcionalidad y contexto. Por ejemplo, al especificar un período de tiempo, la fecha de inicio debe preceder a la fecha de finalización.
Listas blancas y negras
Existen dos enfoques principales para verificar la sintaxis de entrada: la verificación de la lista negra y la lista blanca.
El primer método está diseñado para buscar contenido "potencialmente dañino" en los datos. Por ejemplo, una aplicación web puede bloquear la entrada que contiene la palabra SCRIPT para evitar secuencias de comandos entre sitios. Sin embargo, esta medida de protección se puede eludir mediante el uso de letras minúsculas o una combinación de letras minúsculas y mayúsculas para la etiqueta del script.
El segundo método está destinado a confirmar el cumplimiento de los datos con los requisitos de un conjunto de reglas "probadas". Por ejemplo, una lista blanca del estado de EE. UU. Buscaría un código de 2 letras en una lista de estados existentes de EE. UU.
Al crear software seguro, se recomienda como mínimo la inclusión en la lista blanca. Las listas negras pueden contener errores, pueden eludirse de varias maneras y en sí mismas pueden ser peligrosas. Aunque es posible evitar las restricciones de las listas negras, pueden ser útiles para detectar ataques obvios. Por lo tanto, las listas blancas ayudan a limitar la posibilidad de un ataque al verificar que los datos sean consistentes con las normas sintácticas y semánticas, mientras que las listas negras ayudan a detectar y prevenir ataques obvios.
Verificaciones del lado del cliente y del servidor
Para garantizar la seguridad, la verificación de entrada siempre debe realizarse en el lado del servidor. Las verificaciones del lado del cliente pueden ser útiles en términos de funcionalidad y seguridad, pero a menudo se eluden fácilmente. Por lo tanto, la validación del lado del servidor es preferible por seguridad. Por ejemplo, verificar JavaScript puede advertir al usuario que el campo debe contener solo números, pero la aplicación en el lado del servidor debe confirmar que los datos de entrada son números en un rango aceptable de valores.
C6: Implementar identificación digital
La identificación digital es una representación única del usuario (o cualquier otro objeto) en las transacciones en línea. La autenticación es el proceso de confirmar que una persona o entidad es quien es. La administración de sesión es el proceso por el cual el servidor monitorea el estado de autenticación del usuario para que pueda continuar usando el sistema sin volver a autenticarse. Edición especial
NIST 800-63B : la Guía de identificación digital (autenticación y gestión del ciclo de vida) proporciona recomendaciones detalladas para implementar los requisitos de identificación digital, autenticación y gestión de sesiones.
C7: control de acceso obligatorio
El control de acceso (o autorización) consiste en permitir o prohibir solicitudes específicas de usuarios, programas o procesos, y también implica la emisión y revocación de dichos privilegios.
Cabe señalar que la autorización (confirmación del derecho de acceso a funciones o recursos especiales) no equivale a la autenticación (verificación de identidad).
El control de acceso generalmente afecta muchos aspectos del software, dependiendo de la complejidad del sistema de control de acceso. Por ejemplo, la gestión de metadatos de control de acceso o el almacenamiento en caché para fines de escalabilidad suelen ser componentes adicionales de un sistema de control de acceso que deben crearse o mantenerse. Existen varios enfoques diferentes para el control de acceso:
- control de acceso selectivo (DAC): implica restringir el acceso a los objetos (por ejemplo, archivos o elementos de datos) en función del identificador, así como el principio de "conocimiento necesario" de los sujetos (por ejemplo, usuarios o procesos) y / o grupos a los que pertenecen los objetos;
- Control de acceso obligatorio (MAC): implica restringir el acceso a los recursos del sistema en función de la importancia de los datos (definidos por las etiquetas) contenidos en estos recursos y la autoridad formal (es decir, acceso) de los usuarios para acceder a información de importancia específica;
- Modelo de control de acceso basado en roles (RBAC): implica controlar el acceso a los recursos en función de los roles que definen las acciones permitidas con recursos y no en función de los identificadores del sujeto;
- control de acceso basado en atributos (ABAC): implica permitir o denegar solicitudes de usuario basadas en atributos de usuario y atributos de objeto, así como elementos de entorno que se pueden definir globalmente y ser más relevantes para las políticas aplicadas.
C8: protección de datos ubicua
Los datos confidenciales como contraseñas, números de tarjetas de crédito, registros médicos, datos personales y secretos comerciales requieren protección adicional, especialmente si están sujetos a la ley de privacidad de datos, como el Reglamento General de Protección de Datos de la UE (GDPR) o la ley de protección datos financieros, como el Estándar de seguridad de datos de tarjeta de pago (PCI DSS).
Los atacantes pueden robar datos de aplicaciones web y servicios web de muchas maneras diferentes. Por ejemplo, un atacante puede conectarse a una red inalámbrica compartida y ver o robar datos confidenciales de otros usuarios si se transmiten a través de una conexión a Internet insegura. Un atacante también puede usar la inyección SQL para robar contraseñas y otras credenciales de las aplicaciones, y luego ponerlas en el dominio público.
Clasificación de datos
Debe clasificar los datos en su sistema y determinar el nivel de criticidad de cada bloque de datos. Cada categoría de datos puede asociarse con reglas de protección definidas para cada nivel de criticidad. Por ejemplo, la información de marketing público que no es confidencial puede atribuirse a datos disponibles públicamente que pueden publicarse en un sitio web disponible públicamente. Los números de tarjetas de crédito pueden atribuirse a los datos personales de los usuarios que requieren cifrado al almacenarlos o transferirlos.
Cifrado de transmisión
Al transferir datos confidenciales a través de cualquier red, se debe aplicar una protección de conexión de extremo a extremo (o cifrado). TLS es, con mucho, el protocolo criptográfico más utilizado y compatible que proporciona conexiones seguras. Se utiliza en muchas áreas (aplicaciones web, servicios web, aplicaciones móviles) para la transmisión segura de datos a través de una red. Para garantizar la seguridad de las conexiones TLS, debe configurarlas correctamente.
El principal beneficio del protocolo TLS es la protección de los datos de la aplicación web contra el acceso no autorizado y los cambios durante su transferencia entre clientes (navegadores web) y el servidor de aplicaciones web, así como entre el servidor de aplicaciones web y el servidor interno u otro servidor que no sea navegador , componentes de la organización.
Cifrado de datos
La primera regla para administrar datos confidenciales es evitar almacenar datos confidenciales siempre que sea posible. Si necesita guardar datos confidenciales, asegúrese de que tengan protección criptográfica contra el acceso y los cambios no autorizados.
La criptografía es una de las áreas más avanzadas de seguridad de la información; su comprensión requiere un amplio conocimiento y experiencia. Es difícil elegir una solución única, ya que hay muchos enfoques diferentes para el cifrado, y cada uno de ellos tiene sus ventajas y desventajas, que los arquitectos y desarrolladores web deben entender claramente. Además, la investigación criptográfica seria generalmente se basa en matemáticas más altas y teoría de números, lo que crea un umbral de entrada alto.
C9: Implemente el registro y monitoreo de eventos de seguridad
La mayoría de los desarrolladores ya utilizan el registro para la depuración y el diagnóstico. También es importante registrar eventos de seguridad (datos relacionados con la seguridad) mientras se ejecuta la aplicación. El monitoreo es un análisis en vivo de la aplicación y los registros de seguridad utilizando diversas herramientas de automatización. Las mismas herramientas y plantillas se pueden aplicar a operaciones continuas, depuración y seguridad.
Beneficios del registro de eventos de seguridad
Los registros de eventos de seguridad se pueden usar para:
- suministro de un sistema de detección de ataques con datos;
- análisis e investigación de incidentes;
- cumplimiento de los requisitos reglamentarios.
Implementación del registro de eventos de seguridad
Las siguientes son recomendaciones para implementar el registro de eventos de seguridad.
- Utilice formularios y métodos estándar para registrar eventos en el sistema y entre los sistemas de su organización. Un ejemplo de una plataforma de registro de eventos estándar es Apache Logging Services, que proporciona compatibilidad de registro entre aplicaciones Java, PHP, .NET y C ++.
- No registre demasiados o muy pocos datos. Por ejemplo, asegúrese de registrar marcas de tiempo y credenciales, como la dirección IP de origen y la identificación de usuario, pero nunca registre datos personales o confidenciales.
- Preste especial atención a la sincronización horaria entre nodos para garantizar la coherencia de la marca de tiempo.
Iniciar sesión para detectar y contrarrestar ataques
Utilice el registro para determinar la actividad que indica el comportamiento malicioso del usuario. Actividad potencialmente peligrosa que se registrará:
- Los datos de entrada están fuera del rango numérico esperado;
- los datos de entrada modifican los componentes que deben permanecer sin cambios (lista de selección, casillas de verificación, otros componentes con entrada limitada);
- solicitudes que violan las reglas de control de acceso del lado del servidor;
- Puede encontrar una lista más detallada de marcadores de ataque aquí .
Cuando una aplicación detecta dicha actividad, al menos debe registrar este evento y marcarlo como peligroso. Idealmente, la aplicación debería contrarrestar el ataque, por ejemplo, cancelando la sesión del usuario y bloqueando su cuenta. El mecanismo de contramedidas permite que el programa responda a ataques detectables en tiempo real.
C10: manejo obligatorio de todos los errores y excepciones
El manejo de excepciones permite que una aplicación responda a varios errores (por ejemplo, una falla de la red o conectarse a una base de datos) de varias maneras. El manejo correcto de excepciones y errores es simplemente necesario para garantizar la confiabilidad y seguridad de su código.
, -, .
. , .
,
.
.
- . . , , , . (, ) . , , , .
- TLS. Apple «goto fail» , TLS- Apple.
- . . . .
- , try/catch . .
- , , .
- , , , .
- .
Conclusión
, . , .
:
. :
JZDLin ,
,
.
Creative Commons Attribution ShareAlike 3.0,
OWASP .