From f439131e2e5fe146a2994ab0936a5e3d0463c75e Mon Sep 17 00:00:00 2001 From: roxana-calderon-owasp Date: Sat, 15 Mar 2025 19:45:49 -0400 Subject: [PATCH 1/4] chapter6 design 01-threat-modeling --- release-es/06-design/00-toc.md | 78 +++-- .../06-design/01-threat-modeling/00-toc.md | 34 +- .../01-threat-modeling/01-threat-modeling.md | 293 +++++++++++++++++- .../06-design/01-threat-modeling/02-pytm.md | 110 ++++++- .../01-threat-modeling/03-threat-dragon.md | 76 ++++- release-es/06-design/03-mas-checklist.md | 69 ++++- release-es/06-design/toc.md | 72 ++++- 7 files changed, 650 insertions(+), 82 deletions(-) diff --git a/release-es/06-design/00-toc.md b/release-es/06-design/00-toc.md index cfbcbe85..b089e1f5 100644 --- a/release-es/06-design/00-toc.md +++ b/release-es/06-design/00-toc.md @@ -3,7 +3,7 @@ title: Diseño layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: @@ -11,36 +11,72 @@ order: {% include breadcrumb.html %} -![WIP logo](../../assets/images/dg_wip.png "Trabajo en curso"){height=180px} +![Logo de la guía del desarrollador](../../assets/images/dg_logo.png "Guía del Desarrollador OWASP"){height=180px} ## 4. Diseño -No hay traducción de esta página, consulte [versión original en inglés][release0600]. +Refiriéndose a la [Hoja de Referencia de Diseño de Producto Seguro][spdcs], el propósito de la arquitectura y diseño seguros es garantizar +que todos los productos cumplan o excedan los requisitos de seguridad establecidos por la organización, +centrándose en la seguridad vinculada a los componentes y tecnologías utilizados durante el desarrollo de la aplicación. -Sections: +El Diseño de Arquitectura Segura examina la selección y composición de componentes que forman la base de la solución. +La Gestión de Tecnología examina la seguridad de las tecnologías de apoyo utilizadas durante el desarrollo, despliegue y operaciones, +como el stack de tecnología de desarrollo y sus herramientas, herramientas de despliegue, y sistemas operativos y sus herramientas. -4.1 [Modelado de amenazas](#modelado-de-amenazas) -4.1.1 [Modelado de amenazas en la práctica](#modelado-de-amenazas-en-la-práctica) +Un diseño seguro ayudará a establecer valores predeterminados seguros, minimizar el área de superficie de ataque +y fallar de manera segura hacia valores predeterminados bien definidos y comprendidos. +También considerará y seguirá varios principios, como: + +* Privilegio Mínimo y Separación de Deberes +* Defensa en Profundidad +* Confianza Cero +* Seguridad en lo Abierto + +Un Ciclo de Vida de Desarrollo Seguro (SDLC) ayuda a asegurar que todas las decisiones de seguridad tomadas sobre el producto en desarrollo +sean elecciones explícitas y resulten en el nivel correcto de seguridad para el diseño del producto. +Se pueden utilizar varios ciclos de vida de desarrollo seguro y generalmente incluyen el modelado de amenazas en el proceso de diseño. + +Las listas de verificación y las Hojas de Referencia son herramientas importantes durante el proceso de diseño; +proporcionan una referencia fácil de conocimiento y ayudan a evitar la repetición de errores y fallos de diseño. + +El [Diseño][sammd] de aplicaciones de software es una de las principales funciones de negocio descritas en +el [Modelo de Madurez de Aseguramiento de Software (SAMM)][samm], e incluye prácticas de seguridad: + +* [Evaluación de Amenazas][sammdta] +* [Requisitos de Seguridad][sammdsr] +* [Arquitectura de Seguridad][sammdsa] + +Secciones: + +4.1 [Modelado de amenazas](#threat-modeling) +4.1.1 [Modelado de amenazas en la práctica](#threat-modeling-in-practice) 4.1.2 [pytm](#pytm) 4.1.3 [Threat Dragon](#threat-dragon) 4.1.4 [Cornucopia](#cornucopia) 4.1.5 [LINDDUN GO](#linddun-go) -4.1.6 [Kit de herramientas de modelado de amenazas](#kit-de-herramientas-de-modelado-de- amenazas) -4.2 [Lista de verificación de aplicaciones web](#lista-de-verificación-de-aplicaciones-web) -4.2.1 [Definir requisitos de seguridad](#definir-requisitos-de-seguridad) -4.2.2 [Aprovechar los frameworks y librerías](#aprovechar-los-frameworks-y-librerías) -4.2.3 [Asegurar el acceso a la base de datos](#asegurar-el-acceso-a-la-base-de-datos) -4.2.4 [Codificar y escapar caracteres especiales en datos](#codificar-y-escapar-caracteres-especiales-en-datos) -4.2.5 [Validar todas las entradas](#validar-todas-las-entradas) -4.2.6 [Implementar identidad digital](#implementar-identidad-digital) -4.2.7 [Hacer respetar los controles de acceso](#hacer-respetar-los-controles-de-acceso) -4.2.8 [Proteger los datos en todas partes](#proteger-los-datos-en-todas-partes) -4.2.9 [Implementar registro y monitoreo](#implementar-registro-y-monitoreo) -4.2.10 [Manejar todos los errores y excepciones](#cmanejar-todos-los-errores-y-excepciones) -4.3 [MAS lista de verificación](#mas-lista-de-verificación) +4.1.6 [Kit de herramientas de Modelado de Amenazas](#threat-modeling-toolkit) +4.2 [Lista de verificación de aplicaciones web](#web-application-checklist) +4.2.1 [Lista de verificación: Definir Requisitos de Seguridad](#checklist-define-security-requirements) +4.2.2 [Lista de verificación: Aprovechar Marcos y Bibliotecas de Seguridad](#checklist-leverage-security-frameworks-and-libraries) +4.2.3 [Lista de verificación: Acceso Seguro a Base de Datos](#checklist-secure-database-access) +4.2.4 [Lista de verificación: Codificar y Escapar Datos](#checklist-encode-and-escape-data) +4.2.5 [Lista de verificación: Validar Todas las Entradas](#checklist-validate-all-inputs) +4.2.6 [Lista de verificación: Implementar Identidad Digital](#checklist-implement-digital-identity) +4.2.7 [Lista de verificación: Aplicar Controles de Acceso](#checklist-enforce-access-controls) +4.2.8 [Lista de verificación: Proteger Datos en Todas Partes](#checklist-protect-data-everywhere) +4.2.9 [Lista de verificación: Implementar Registro y Monitoreo de Seguridad](#checklist-implement-security-logging-and-monitoring) +4.2.10 [Lista de verificación: Manejar todos los Errores y Excepciones](#checklist-handle-all-errors-and-exceptions) +4.3 [Lista de verificación de aplicaciones móviles MAS](#mas-checklist) ---- -[release0600]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/toc.md +La Guía del Desarrollador de OWASP es un esfuerzo comunitario; si hay algo que necesita ser cambiado, [cree un issue][issue0600]. + -\newpage +[issue0600]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/00-toc +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet \ No newline at end of file diff --git a/release-es/06-design/01-threat-modeling/00-toc.md b/release-es/06-design/01-threat-modeling/00-toc.md index 3d2b12a0..5084dcd6 100644 --- a/release-es/06-design/01-threat-modeling/00-toc.md +++ b/release-es/06-design/01-threat-modeling/00-toc.md @@ -1,9 +1,7 @@ ---- - -title: Modelado de amenazas +title: Modelado de Amenazas layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: @@ -11,23 +9,37 @@ order: {% include breadcrumb.html %} -![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){height=180px} +![logo de la Guía del Desarrollador](../../../assets/images/dg_logo_bbd.png "Guía del Desarrollador OWASP"){height=180px} ### 4.1 Modelado de amenazas -No hay traducción de esta página, consulte [versión original en inglés][release0601]. +Según la [Hoja de Referencia de Modelado de Amenazas][cstm], +el modelado de amenazas es un enfoque estructurado para identificar y priorizar amenazas potenciales a un sistema. +El proceso de modelado de amenazas incluye determinar el valor que las posibles mitigaciones tendrían +para reducir o neutralizar estas amenazas. + +Evaluar las amenazas potenciales durante la fase de diseño de su proyecto puede ahorrar recursos significativos +si durante una fase posterior del proyecto se requiere refactorización para incluir mitigaciones de riesgos. +Los resultados de las actividades de modelado de amenazas generalmente incluyen: + +* Documentar cómo fluyen los datos a través de un sistema para identificar dónde podría ser atacado +* Identificar tantas amenazas potenciales al sistema como sea posible +* Sugerir controles de seguridad que pueden implementarse para reducir la probabilidad o el impacto de una amenaza potencial -Sections: +Secciones: -4.1.1 [Modelado de amenazas en la práctica](#modelado-de-amenazas-en-la-práctica) +4.1.1 [Modelado de amenazas en la práctica](#threat-modeling-in-practice) 4.1.2 [pytm](#pytm) 4.1.3 [Threat Dragon](#threat-dragon) 4.1.4 [Cornucopia](#cornucopia) 4.1.5 [LINDDUN GO](#linddun-go) -4.1.6 [Kit de herramientas de modelado de amenazas](#kit-de-herramientas-de-modelado-de- amenazas) +4.1.6 [Kit de herramientas de modelado de amenazas](#threat-modeling-toolkit) ---- +Traducción de versión [original en inglés][release0601]. -[release0601]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/toc.md +La Guía del Desarrollador de OWASP es un esfuerzo comunitario; si hay algo que necesita cambios, [cree un issue][issue0601]. -\newpage +[release0601]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/00-toc.md +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet +[issue0601]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/00-toc \ No newline at end of file diff --git a/release-es/06-design/01-threat-modeling/01-threat-modeling.md b/release-es/06-design/01-threat-modeling/01-threat-modeling.md index f4afa29d..d69a243e 100644 --- a/release-es/06-design/01-threat-modeling/01-threat-modeling.md +++ b/release-es/06-design/01-threat-modeling/01-threat-modeling.md @@ -1,9 +1,9 @@ --- -title: Modelado de amenazas en la práctica +title: Modelado de Amenazas en la Práctica layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Adam Shostack, Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: 46110 permalink: /release-es/diseño/modelado_amenazas/modelado_amenazas_práctica/ @@ -12,24 +12,285 @@ permalink: /release-es/diseño/modelado_amenazas/modelado_amenazas_práctica/ {% include breadcrumb.html %} - +### 4.1.1 Modelado de amenazas en la práctica -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +Esta sección trata sobre el Modelado de Amenazas, una actividad descrita en el Modelo de Madurez de Aseguramiento de Software de OWASP ([SAMM][samm]). +El modelado de amenazas es parte de la práctica de seguridad de [Evaluación de Amenazas][sammdta] en la función empresarial de [Diseño][sammd]. -### 4.1.1 Modelado de amenazas en la práctica +Gran parte del material de esta sección está extraído del [proyecto de Modelado de Amenazas][tmproject] de OWASP, +y la filosofía de esta sección intenta seguir el [Manifiesto de Modelado de Amenazas][tmmanifesto]. + +![TMM logo](../../../../assets/images/logos/tmmanifesto.png "OWASP TM Manifesto"){: height="60px" } + +#### Descripción general + +Las actividades de modelado de amenazas intentan descubrir lo que podría salir mal dentro de un sistema y determinar qué hacer al respecto. +Los resultados del modelado de amenazas toman diversas formas, incluyendo modelos y diagramas de sistemas, listas de amenazas, +mitigaciones o suposiciones, notas de reuniones y más. +Esto puede reunirse en un único documento de modelo de amenazas; una representación estructurada de toda la información +que afecta a la seguridad de una aplicación. +Una buena visión general de esta actividad se proporciona en la sección sobre modelado de amenazas del proyecto [Cultura de Seguridad][culturetm]. + +En esencia, es una visión de la aplicación y su entorno a través de cristales de seguridad. + +El modelado de amenazas es un proceso para capturar, organizar y analizar toda esta información +y permite la toma de decisiones informadas sobre el riesgo de seguridad de la aplicación. +Además de producir un modelo, los esfuerzos típicos de modelado de amenazas también producen una lista priorizada +de vulnerabilidades de seguridad _potenciales_ en el concepto, los requisitos, el diseño o la implementación. +Cualquier vulnerabilidad potencial que se haya identificado a partir del modelo debe ser remediada +utilizando una de las estrategias comunes: mitigar, eliminar, transferir o aceptar la amenaza de ser explotada. + +Hay muchas razones para hacer modelado de amenazas, pero la más importante es que esta actividad es _útil_, +probablemente es la única etapa en un ciclo de vida de desarrollo donde un equipo se detiene y pregunta: "¿Qué puede salir mal?". + +Hay otras razones para el modelado de amenazas, por ejemplo, el cumplimiento de estándares o el análisis para la recuperación ante desastres, +pero el objetivo principal del modelado de amenazas es remediar vulnerabilidades (posibles) antes de que los actores maliciosos puedan explotarlas. + +#### Qué es el modelado de amenazas + +El modelado de amenazas trabaja para identificar, comunicar y comprender las amenazas y mitigaciones +dentro del contexto de proteger algo de valor. + +El modelado de amenazas se puede aplicar a una amplia gama de cosas, incluyendo software, aplicaciones, sistemas, redes, +sistemas distribuidos, cosas en Internet de las cosas, procesos de negocio, etc. +Hay muy pocos productos técnicos que no puedan tener un modelado de amenazas; que sea +más o menos gratificante, dependiendo de cuánto éste se comunica, o interactúa, con el mundo. + +Un documento de modelo de amenazas es un registro del proceso de modelado de amenazas, y a menudo incluye: + +* una descripción / diseño / modelo de lo que es preocupante +* una lista de suposiciones que pueden ser verificadas o rechazadas en el futuro a medida que cambia el panorama de amenazas +* amenazas potenciales al sistema +* remediación / acciones a tomar para cada amenaza +* formas de validar el modelo y las amenazas, y verificación del éxito de las acciones tomadas + +El modelo de amenazas debe estar en una forma que pueda ser fácilmente revisada y modificada +durante las discusiones posteriores de modelado de amenazas. + +#### Por qué hacerlo + +Como todas las actividades de ingeniería, el esfuerzo dedicado al modelado de amenazas tiene que ser justificable. +Raramente cualquier proyecto o desarrollo tiene esfuerzo de ingeniería que "salga sobrando", +y los beneficios del modelado de amenazas tienen que superar el costo de ingeniería de esta actividad. +Usualmente esto es difícil de cuantificar; una forma más fácil de abordarlo puede ser preguntar +¿cuáles son los costos de _no_ hacer modelado de amenazas? +Estos costos pueden consistir en fallas de cumplimiento, un mayor riesgo de ser explotado, daño a la reputación, etc. + +La inclusión del modelado de amenazas en las actividades de desarrollo seguro puede ayudar a: + +* Construir un diseño seguro +* Inversión eficiente de recursos; priorizar adecuadamente la seguridad, el desarrollo y otras tareas +* Reunir a Seguridad y Desarrollo para colaborar en una comprensión compartida, informando el desarrollo del sistema +* Identificar amenazas y requisitos de cumplimiento, y evaluar su riesgo +* Definir y construir los controles requeridos. +* Equilibrar riesgos, controles y usabilidad +* Identificar dónde construir un control es innecesario, basado en un riesgo aceptable +* Documentar amenazas y mitigación +* Asegurar que los requisitos de negocio (o metas) estén adecuadamente protegidos frente a + un actor malicioso, accidentes u otras causas de impacto +* Identificación de casos de prueba de seguridad / escenarios de prueba de seguridad para probar los requisitos de seguridad + +El modelado de amenazas también proporciona una clara "línea de visión" (mediante límites y alcances del objetivo) a través de un proyecto que puede ser utilizada +para justificar otros esfuerzos de seguridad. +El modelo de amenazas permite que las decisiones de seguridad se tomen racionalmente, con toda la información disponible, +para que las decisiones de seguridad puedan ser adecuadamente respaldadas. +El proceso de modelado de amenazas naturalmente produce un argumento de aseguramiento que puede ser utilizado para explicar +y defender la seguridad de una aplicación. +Un argumento de aseguramiento comienza con algunas afirmaciones de alto nivel y luego las justifica con sub-afirmaciones o evidencias. + +#### Cuándo modelar amenazas + +No hay un momento incorrecto para hacer modelado de amenazas; +cuanto antes se haga en el ciclo de vida del desarrollo, más beneficioso es, +pero el modelado de amenazas también es útil en cualquier momento durante el desarrollo de la aplicación. + +El modelado de amenazas se aplica mejor de forma continua a lo largo de un proyecto de desarrollo de software. +El proceso es esencialmente el mismo en diferentes niveles de abstracción, +aunque la información se vuelve cada vez más granular a lo largo del ciclo de vida del desarrollo. +Idealmente, un modelo de amenazas de alto nivel debería definirse en la fase de concepto o planificación, +y luego refinarse durante las fases de desarrollo. +A medida que se agregan más detalles al sistema, se identifican nuevos vectores de ataque, +por lo que el proceso continuo de modelado de amenazas debe examinar, diagnosticar y abordar estas amenazas. + +Nótese que es una parte natural del refinamiento de un sistema que se expongan nuevas amenazas. +Cuando se selecciona una tecnología particular, como Java por ejemplo, +se asume la responsabilidad de identificar las nuevas amenazas que se crean por esa elección. +Incluso decisiones de implementación como usar expresiones regulares para la validación +introducen nuevas amenazas potenciales que hay que tratar. + +Modelado de amenazas: _cuanto antes mejor, pero nunca demasiado tarde_ + +#### Preguntas que hacer + +A menudo, el modelado de amenazas es una actividad conceptual más que un proceso riguroso, +donde se reúnen equipos de desarrollo y se les pide que piensen en formas de comprometer la seguridad de su sistema. +Para proporcionar algo de estructura, es útil comenzar con el [Marco de Cuatro Preguntas][4QFW] de Shostack: + +**1 ¿En qué estamos trabajando**? + +Como punto de partida, se debe definir el alcance del Modelo de Amenazas. +Esto requerirá una comprensión de la aplicación que se está construyendo, +y algunos ejemplos de entradas para el modelo de amenazas podrían ser: + +* Diagramas de arquitectura +* Transiciones de flujo de datos +* Clasificaciones de datos -No hay traducción de esta página, consulte [versión original en inglés][release060101]. +Es común representar las respuestas a esta pregunta con uno o más diagramas de flujo de datos +y a menudo diagramas complementarios como diagramas de secuencia de mensajes. + +Es mejor reunir a personas de diferentes roles con suficiente conciencia técnica y de riesgo +para que puedan acordar el marco a utilizar durante el ejercicio de modelado de amenazas. + +**2 ¿Qué puede salir mal**? + +Esta es una actividad de investigación para encontrar las principales amenazas que se aplican a tu aplicación. +Hay muchas formas de abordar la pregunta, incluida la discusión abierta o el uso de una estructura para ayudar a pensarlo. +Las técnicas y metodologías a considerar incluyen CIA, [STRIDE][stride], [LINDDUN][linddun], +[cadenas de eliminación cibernética][chains], [PASTA][pasta], patrones de ataque comunes ([CAPEC][capec]) y otros. + +Existen recursos disponibles que ayudarán a identificar amenazas y vulnerabilidades. +OWASP proporciona un conjunto de tarjetas, [Cornucopia][corncards], que ofrecen sugerencias y explicaciones para vulnerabilidades generales. +El juego de tarjetas de modelado de amenazas [Elevation of Privileges][eop] es una forma fácil de comenzar con el modelado de amenazas, +y existe la versión OWASP de [Serpientes y Escaleras][snakes] que realmente gamifica estas actividades. + +**3 ¿Qué vamos a hacer al respecto**? + +En esta fase, se convierte los hallazgos del modelo de amenazas en acciones específicas. +Considere la remediación apropiada para cada amenaza identificada: Transferir, Evitar, Mitigar o Eliminar. + +**4 ¿Hicimos un trabajo lo suficientemente bueno**? + +Finalmente, realiza una actividad retrospectiva sobre el trabajo identificado para verificar +calidad, viabilidad, progreso o planificación. + +El [Manual de Modelado de Amenazas][tmpb] de OWASP profundiza en estos aspectos prácticos +y proporciona estrategias para mantener el modelado de amenazas dentro de una organización. + +#### Cómo hacerlo + +No existe un único proceso para el modelado de amenazas. +Cómo se hace en la práctica variará según la cultura de la organización, +según qué tipo de sistema/aplicación se está modelando +y según las preferencias del propio equipo de desarrollo. +Las diversas técnicas y conceptos se discuten en la [Hoja de Referencia de Modelado de Amenazas][cstm] +y se pueden resumir así: + +1. Terminología: intente usar términos estándar como actores, límites de confianza, etc., ya que esto ayudará a transmitir estos conceptos +2. Alcance: sea claro sobre lo que se está modelando y manténgase dentro de este alcance +3. Documentar: decida qué herramientas y qué resultados se requieren para satisfacer el cumplimiento, por ejemplo +4. Descomponer: divida el sistema que se está modelando en partes manejables +5. Confianza: identifique los límites de confianza, considere la [segmentación de red][ccsnet] +6. Agentes: identifique quiénes son los actores (maliciosos o no) y qué pueden hacer +7. Categorizar: priorice las amenazas teniendo en cuenta la probabilidad, el impacto y cualquier otro factor +8. Remediación: asegúrese de decidir qué hacer con las amenazas identificadas, la razón principal del modelado de amenazas + +Vale la pena decirlo de nuevo: hay muchas formas de hacer modelado de amenazas, +todas perfectamente válidas, así que elija el proceso correcto que funcione para un equipo específico. + +#### Recomendación final + +Algunas palabras finales sobre el modelado de amenazas. + +**Hágalo incremental**: + +Considere firmemente usar [modelado de amenazas incremental][sammgata]. +Sin duda alguna es una mala idea tratar de modelar completamente una aplicación o sistema existente; +puede ser muy lento modelar todo un sistema, +y para cuando se complete dicho modelo, probablemente ya estaría desactualizado. +En cambio, modela incrementalmente nuevas características o mejoras a medida que se desarrollan. + +El modelado de amenazas incremental asume que las aplicaciones y características existentes +ya han sido atacadas con el tiempo y estas vulnerabilidades del mundo real han sido remediadas. +Son las nuevas características o nuevas aplicaciones las que presentan un mayor riesgo de seguridad; +si son vulnerables, reducirán la seguridad de la aplicación o sistema existente. +Concentrarse en los nuevos cambios aplica el esfuerzo de modelado de amenazas en el lugar donde más se necesita; +como mínimo, los cambios no deberían empeorar la seguridad, e, idealmente, la seguridad debería mejorar. + +**Las herramientas son secundarias**: + +Es bueno estandarizar las herramientas de modelado de amenazas en toda la organización, +pero también permitir que los equipos elijan cómo registran sus modelos de amenazas. +Si un equipo decide usar Threat Dragon, por ejemplo, y otro quiere usar una pizarra, +entonces eso generalmente está bien. +Las discusiones mantenidas durante el proceso de modelado de amenazas son más importantes que la herramienta utilizada, +aunque podrías preguntar al equipo que usa la pizarra cómo implementan el control de cambios para sus modelos. + +**La brevedad es primordial**: + +Es muy fácil crear un modelo de amenazas que se parezca mucho a un diagrama del sistema, con muchos componentes y flujos de datos. +Esto logrará un diagrama convincente, pero no es un modelo específico para la amenaza de exploits. +En cambio, concéntrese en las superficies de ataque/amenaza y sea robusto al consolidar múltiples componentes del sistema +en un solo componente del modelo de amenazas. +Esto mantendrá el número de componentes y flujos de datos de tamano manejable, y enfoca la discusión en lo que más importa: +actores maliciosos (externos o internos) tratando de comprometer la seguridad de su sistema. + +**Elige tu metodología**: + +Es una buena estrategia elegir una metodología de categorización de amenazas para toda la organización +y luego tratar de mantenerla. +Por ejemplo, podría ser [STRIDE][stride] o [LINDDUN][linddun], pero si la tríada CIA proporciona suficiente granularidad, +entonces también es una elección perfectamente buena. + +#### Lectura adicional + +* [Manifiesto de Modelado de Amenazas][tmmanifesto] +* [Proyecto de Modelo de Amenazas][tmproject] de OWASP +* [Hoja de Referencia de Modelado de Amenazas] [cstm] de OWASP +* [Manual de Modelado de Amenazas (OTMP)][tmpb] de OWASP +* [Hoja de Referencia de Análisis de Superficie de Ataque][asacs] de OWASP +* Páginas comunitarias de OWASP sobre [Modelado de Amenazas][TM] y el [Proceso de Modelado de Amenazas][TMP] +* [El Marco de Cuatro Preguntas Para el Modelado de Amenazas](https://youtu.be/Yt0PhyEdZXU) video de 60 segundos +* [Cadena de Eliminación Cibernética][chains] de Lockheed +* Proceso de VerSprite para Simulación de Ataques y Análisis de Amenazas ([PASTA][pasta]) +* [Modelado de Amenazas: Diseñando para la Seguridad][TMdesigning] +* [Modelado de Amenazas: Una Guía Práctica para Equipos de Desarrollo][TMpractical] + +#### Recursos + +* [Marco de Cuatro Preguntas][4QFW] de Shostack +* [pytm][PYTM] herramienta de Modelado de Amenazas Pythonica de OWASP +* OWASP [Threat Dragon][tdtm] herramienta de modelado de amenazas usando diagramas de flujo de datos +* [Threagile](https://threagile.io), un proyecto de código abierto que proporciona modelado de amenazas Ágil +* [Herramienta de Modelado de Amenazas][TMT] de Microsoft, una herramienta ampliamente utilizada en toda la comunidad de seguridad y de descarga gratuita +* [threatspec](https://github.com/threatspec/threatspec), una herramienta de código abierto basada en comentarios en línea con el código +* Enumeración y Clasificación de Patrones de Ataque Comunes de MITRE ([CAPEC][capec]) +* [Calculadora del Sistema Común de Puntuación de Vulnerabilidades][nist-cvss] de NIST ---- +Traducción de versión [original en inglés][release060101]. -[release060101]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/01-threat-modeling.md +La Guía del Desarrollador de OWASP es un esfuerzo comunitario; si hay algo que necesita cambios, +[cree un issue][issue060101] o [edítelo en GitHub][edit060101]. -\newpage +[release060101]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/01-threat-modeling.md +[4QFW]: https://github.com/adamshostack/4QuestionFrame +[asacs]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet +[capec]: https://capec.mitre.org/ +[chains]: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html +[corncards]: https://owasp.org/www-project-cornucopia/ +[ccsnet]: https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet +[culturetm]: https://owasp.org/www-project-security-culture/stable/6-Threat_Modelling/ +[eop]: https://shostack.org/games/elevation-of-privilege +[edit060101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/01-threat-modeling.md +[issue060101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/01-threat-modeling +[linddun]: https://linddun.org/ +[nist-cvss]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[pasta]: https://versprite.com/blog/what-is-pasta-threat-modeling/ +[PYTM]: https://owasp.org/www-project-pytm/ +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[sammgata]: https://owaspsamm.org/guidance/agile/#TA +[snakes]: https://owasp.org/www-project-snakes-and-ladders/ +[stride]: https://en.wikipedia.org/wiki/STRIDE_%28security%29 +[tdtm]: https://owasp.org/www-project-threat-dragon/ +[tmpb]: https://owasp.org/www-project-threat-modeling-playbook/ +[tmproject]: https://owasp.org/www-project-threat-model/ +[tmmanifesto]: https://www.threatmodelingmanifesto.org/ +[TM]: https://owasp.org/www-community/Threat_Modeling +[TMP]: https://owasp.org/www-community/Threat_Modeling_Process +[TMdesigning]: https://shostack.org/books/threat-modeling-book +[TMpractical]: https://threatmodeling.dev/ +[TMT]: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool diff --git a/release-es/06-design/01-threat-modeling/02-pytm.md b/release-es/06-design/01-threat-modeling/02-pytm.md index 2db2f0f7..41fd9ec5 100644 --- a/release-es/06-design/01-threat-modeling/02-pytm.md +++ b/release-es/06-design/01-threat-modeling/02-pytm.md @@ -1,9 +1,9 @@ --- -title: Pytm +title: Modelado de Amenazas Pythónico layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: 46120 permalink: /release-es/diseño/modelado_amenazas/pytm/ @@ -22,14 +22,112 @@ permalink: /release-es/diseño/modelado_amenazas/pytm/ } -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +![Logo de pytm](../../../../assets/images/logos/pytm.png "OWASP pytm"){: .image-right } ### 4.1.2 pytm -No hay traducción de esta página, consulte [versión original en inglés][release060102]. +El proyecto OWASP [pytm (Modelado de Amenazas Pythónico)][pytmproject] es un marco para el modelado de amenazas y su automatización. +El objetivo de pytm es realizar el modelado de amenazas Shift-Left, lo que significa iniciar el modelado ya en etapas tempranas del proyecto, haciendo que el modelado de amenazas sea más automatizado y centrado en el desarrollador. + +Pytm es un Proyecto de Laboratorio de OWASP con una comunidad de colaboradores que crean [versiones regulares][pytmreleases]. + +#### ¿Qué es pytm? + +Pytm es una biblioteca Java que proporciona una forma programática de modelado de amenazas; +el modelo de aplicación en sí se define como un archivo fuente de python3 y sigue la sintaxis del programa Python. +Los hallazgos se incluyen en el programa python del modelo de aplicación con amenazas definidas como filas en un archivo de texto asociado. +El archivo de amenazas puede reutilizarse entre proyectos y permite la acumulación de una base de conocimiento. + +Usando pytm, el modelo y las amenazas pueden ser programáticamente generados como un diagrama de flujo de datos [dot][graphvizdot] +que se muestra utilizando [Graphviz][graphviz], una utilidad de software de visualización de gráficos de código abierto. +Alternativamente, el modelo y las amenazas pueden generarse como un archivo [PlantUML][plantuml] que luego puede mostrarse, +usando Java y el archivo `.jar` de PlantUML, como un diagrama de secuencia. + +Si se requiere un documento de informe, un script de pytm puede generar el modelo, las amenazas y los hallazgos como markdown. +Programas como [pandoc][pandoc] pueden tomar este archivo markdown despues +y proporcionar el documento en varios formatos como PDF, ePub o html. + +La serie Spotlight de OWASP proporciona una visión general de pytm: 'Proyecto 6 - [OWASP pytm][spotlight06]'. + +#### ¿Por qué usar pytm? + +El equipo de desarrollo de pytm señala con razón que el modelado de amenazas tradicional a menudo llega demasiado tarde +en el proceso de desarrollo, y a veces puede no ocurrir en absoluto. +Además, crear flujos de datos manuales/diagramáticos e informes puede consumir muchísimo tiempo. +Estas son ciertamente observaciones válidas, +y por lo tanto pytm intenta que el modelado de amenazas "se desplace a la izquierda" en el ciclo de vida del desarrollo. + +Muchas herramientas tradicionales de modelado de amenazas como OWASP Threat Dragon proporcionan +una forma gráfica de crear diagramas e introducir amenazas. +Estas aplicaciones almacenan los modelos como texto, por ejemplo JSON y YAML, pero el método principal de entrada es a través de la aplicación. + +Pytm es diferente - el método principal para crear y actualizar los modelos de amenazas es a través de código. +Este código fuente define completamente el modelo junto con sus hallazgos, amenazas y remediaciones. +Los diagramas e informes se consideran salidas del modelo; no las entradas al modelo. +Esto hace que pytm sea una herramienta poderosa para describir un sistema o aplicación, y permite que el modelo se continúe construyendo con el tiempo. + +Este enfoque en el modelo como código y salidas programáticas hace que Pytm sea particularmente útil en entornos automatizados, +ayudando a que el modelo de amenazas se integre en el proceso de diseño desde el principio, +así como en sesiones de modelado de amenazas más tradicionales. + +#### Cómo usar pytm + +La mejor descripción de cómo usar pytm se encuentra en el capítulo 4 del libro +[Threat Modeling: a practical guide for development teams][TMchap4] +que está escrito por dos de los principales colaboradores del proyecto pytm. + +Pytm está basado en código dentro de un entorno de programa, en lugar de ejecutarse como una aplicación única, +por lo que hay varios componentes que deben instalarse en la máquina de destino para permitir que pytm se ejecute. +Actualmente no funciona en Windows, solo en Linux o MacOS, por lo que si necesita ejecutar Windows, use una VM de Linux +o siga las instrucciones para crear un contenedor Docker. + +Las siguientes herramientas y bibliotecas deben estar instaladas: + +* Python 3.x +* Paquete [Graphviz][graphvizdot] +* Java, como OpenJDK 10 u 11 +* El archivo JAR ejecutable de [PlantUML][plantumljar] +* Y por supuesto pytm: clone el [repositorio del proyecto pytm][pytmrepo] + +Una vez instalado el entorno, navegue al directorio principal de su copia local del proyecto. + +Siga [el ejemplo][pytmexample] proporcionado por el repositorio del proyecto pytm y ejecuta los scripts sugeridos +para generar el diagrama de flujo de datos, el diagrama de secuencia y el informe: + +```text +mkdir -p tm +./tm.py --report docs/basic_template.md | pandoc -f markdown -t html > tm/report.html +./tm.py --dfd | dot -Tpng -o tm/dfd.png +./tm.py --seq | java -Djava.awt.headless=true -jar $PLANTUML_PATH -tpng -pipe > tm/seq.png +``` + +#### Referencias + +* [Modelado de Amenazas Pythónico][pytmproject] (pytm) de OWASP +* [Graphviz][graphviz] +* [pandoc][pandoc] +* [PlantUML][plantuml] +* Repositorio [pytm][pytmrepo] +* [Spotlight][spotlight06] sobre pytm +* [Threat Modeling: una guía práctica para equipos de desarrollo][TMchap4] ---- +Traducción de versión [original en inglés][release060102]. -[release060102]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/02-pytm.md +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060102] o [edítelo en GitHub][edit060102]. -\newpage +[release060102]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/02-pytm.md +[graphviz]: https://graphviz.org/ +[graphvizdot]: https://graphviz.org/download/ +[issue060102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/02-pytm +[pandoc]: https://pandoc.org/installing.html +[plantuml]: https://plantuml.com/ +[plantumljar]: https://plantuml.com/download +[edit060102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/02-pytm.md +[pytmrepo]: https://github.com/OWASP/pytm/ +[pytmproject]: https://owasp.org/www-project-pytm/ +[pytmexample]:https://github.com/OWASP/pytm/blob/master/tm.py +[pytmreleases]:https://github.com/OWASP/pytm/releases +[spotlight06]: https://youtu.be/oTqkPaEbTnE +[TMchap4]: https://www.oreilly.com/library/view/threat-modeling/9781492056546/ch04.html diff --git a/release-es/06-design/01-threat-modeling/03-threat-dragon.md b/release-es/06-design/01-threat-modeling/03-threat-dragon.md index bceb690c..3fd80a45 100644 --- a/release-es/06-design/01-threat-modeling/03-threat-dragon.md +++ b/release-es/06-design/01-threat-modeling/03-threat-dragon.md @@ -3,7 +3,7 @@ title: Threat Dragon layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: 46130 permalink: /release-es/diseño/modelado_amenazas/threat_dragon/ @@ -22,14 +22,80 @@ permalink: /release-es/diseño/modelado_amenazas/threat_dragon/ } -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +![Logo de Threat dragon](../../../../assets/images/logos/threat_dragon.png "OWASP Threat Dragon"){: .image-right } ### 4.1.3 Threat Dragon -No hay traducción de esta página, consulte [versión original en inglés][release060103]. +El proyecto [Threat Dragon][tdtm] de OWASP proporciona una herramienta diagramática para el modelado de amenazas +de aplicaciones, APIs y sistemas de software. +Es un Proyecto de Laboratorio OWASP con [varias versiones][tddownload] y está en desarrollo activo. + +#### ¿Qué es Threat Dragon? + +Threat Dragon es una herramienta que puede ayudar a los equipos de desarrollo con su proceso de modelado de amenazas. +Permite crear y modificar diagramas de flujo de datos que proporcionan el +contexto y dirección para las actividades de modelado de amenazas. +También almacena los detalles de las amenazas identificadas durante las sesiones de modelado de amenazas, +y éstas se guardan junto con el diagrama del modelo de amenazas en un archivo basado en texto. +Threat Dragon también puede generar el diagrama del modelo de amenazas y las amenazas asociadas como un reporte PDF. + +#### ¿Por qué usarlo? + +Threat Dragon es una herramienta útil para equipos pequeños que desean crear modelos de amenazas rápida y fácilmente. +Threat Dragon tiene como objetivos: + +* Simplicidad - puedes instalar y comenzar a usar Threat Dragon muy rápidamente +* Flexibilidad - la diagramación y generación de amenazas permite describir todo tipo de amenazas +* Accesibilidad - varios tipos diferentes de equipos pueden beneficiarse de la facilidad de uso de Threat Dragon + +Admite varias metodologías y categorizaciones de amenazas utilizadas durante las actividades de modelado de amenazas: + +* STRIDE +* LINDDUN +* PLOT4ai +* CIA +* DIE + +y puede ser utilizado por todo tipo de equipos de desarrollo. + +#### Cómo usarlo + +La serie Spotlight de OWASP proporciona una visión general de Threat Dragon y cómo usarlo: +'Proyecto 22 - [OWASP Threat Dragon][spotlight22]'. + +Es sencillo comenzar a usar Threat Dragon; la última versión está [disponible para usar en línea][tddemo]: + +1. seleccione 'Login to Local Session' (Iniciar sesión en sesión local) +2. seleccione 'Explore a Sample Threat Model' (Explorar un modelo de amenazas de ejemplo) +3. seleccione 'Version 2 Demo Model' (Modelo de demostración versión 2) +4. Se muestra los metadatos del modelo de amenazas que pueden ser editados +5. haga clic en el diagrama 'Main Request Data Flow' (Flujo de datos de solicitud principal) para mostrar el diagrama de flujo de datos +6. los componentes del diagrama pueden ser inspeccionados, y se muestran sus amenazas asociadas +7. los componentes pueden ser añadidos y eliminados, junto con la edición de sus propiedades + +Threat Dragon se distribuye como una aplicación de escritorio multiplataforma y como una aplicación web. +La [aplicación de escritorio][tddownload] puede descargarse para Windows, Linux y MacOS. +La aplicación web puede ejecutarse utilizando un [contenedor Docker][tddocker] o desde el [código fuente][tdcode]. + +Una característica importante de Threat Dragon es la salida de informes en PDF que puede utilizarse para documentación +y propósitos de cumplimiento GRC; desde la ventana de metadatos del modelo de amenazas, haga clic en el botón Reporte. + +#### Referencias + +* OWASP [Threat Dragon][tdtm] ---- +Traducción de versión [original en inglés][release060103]. -[release060103]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/03-threat-dragon.md +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060103] o [edítelo en GitHub][edit060103]. -\newpage +[release060103]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/01-threat-modeling/03-threat-dragon.md +[issue060103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/03-threat-dragon +[edit060103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/03-threat-dragon.md +[tddemo]: https://www.threatdragon.com/#/ +[tdcode]: https://github.com/OWASP/threat-dragon +[tddocker]: https://hub.docker.com/r/owasp/threat-dragon/tags +[tddownload]: https://github.com/OWASP/threat-dragon/releases +[tdtm]: https://owasp.org/www-project-threat-dragon/ +[spotlight22]: https://youtu.be/hUOAoc6QGJo diff --git a/release-es/06-design/03-mas-checklist.md b/release-es/06-design/03-mas-checklist.md index 41581c68..bae4a8af 100644 --- a/release-es/06-design/03-mas-checklist.md +++ b/release-es/06-design/03-mas-checklist.md @@ -1,9 +1,9 @@ --- -title: MAS lista de verificación +title: Lista de verificación MAS layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: 46400 permalink: /release-es/diseño/mas_lista_verificación/ @@ -22,14 +22,69 @@ permalink: /release-es/diseño/mas_lista_verificación/ } -![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +![Logo de la lista de verificación MAS](../../../assets/images/logos/mas.png "Lista de verificación OWASP MAS"){: .image-right } -### 4.3 MAS lista de verificación +### 4.3 Lista de verificación MAS -No hay traducción de esta página, consulte [versión original en inglés][release0603]. +El proyecto insignia de OWASP [Seguridad de Aplicaciones Móviles][masproject] (MAS) proporciona +estándares de la industria para la seguridad de aplicaciones móviles. + +El proyecto OWASP MAS proporciona el [Estándar de Verificación de Seguridad de Aplicaciones Móviles][masvs] (MASVS) +para aplicaciones móviles y una completa [Guía de Pruebas de Seguridad de Aplicaciones Móviles][mastg] (MASTG). + +La [Lista de verificación de Seguridad de Aplicaciones Móviles][masc] contiene enlaces a los casos de prueba MASTG para cada control MASVS. + +#### ¿Qué es la Lista de verificación MAS? + +La Lista de verificación MAS proporciona una lista que hace seguimiento de los casos de prueba MASTG para un control MASVS determinado. +Esta Lista de verificación MAS está dividida en categorías que coinciden con las categorías MASVS: + +* [MASVS-STORAGE](https://mas.owasp.org/checklists/MASVS-STORAGE/) almacenamiento de datos sensibles +* [MASVS-CRYPTO](https://mas.owasp.org/checklists/MASVS-CRYPTO/) mejores prácticas de criptografía +* [MASVS-AUTH](https://mas.owasp.org/checklists/MASVS-AUTH/) mecanismos de autenticación y autorización +* [MASVS-NETWORK](https://mas.owasp.org/checklists/MASVS-NETWORK/) comunicaciones de red +* [MASVS-PLATFORM](https://mas.owasp.org/checklists/MASVS-PLATFORM/) interacciones con la plataforma móvil +* [MASVS-CODE](https://mas.owasp.org/checklists/MASVS-CODE/) puntos de entrada de la plataforma y datos junto con software de terceros +* [MASVS-RESILIENCE](https://mas.owasp.org/checklists/MASVS-RESILIENCE/) integridad y ejecución en una plataforma confiable +* [MASVS-PRIVACY](https://mas.owasp.org/checklists/MASVS-PRIVACY/) privacidad de usuarios, datos y recursos + +Además de los enlaces web, hay una [hoja de cálculo descargable][masxls]. + +#### ¿Por qué usarla? + +El OWASP MASVS es el estándar de la industria para [seguridad de aplicaciones móviles][csmas]. +Si se está aplicando el MASTG a una aplicación móvil, la Lista de verificación MAS es una referencia útil +que también puede utilizarse para fines de cumplimiento. + +#### Cómo utilizarla + +La [versión en línea][masc] es útil para listar los controles MASVS y qué pruebas MASTG aplican. +Siga los enlaces para acceder a los controles y pruebas individuales. + +La [descarga de la hoja de cálculo][masxls] permite registrar el estado de cada prueba, +con una hoja separada para cada categoría MASVS. +Este registro de resultados de pruebas puede utilizarse como evidencia para fines de cumplimiento. + +#### Referencias + +* Proyecto de Seguridad de Aplicaciones Móviles ([MAS][masproject]) +* [Lista de verificación][masc] MAS +* Estándar de Verificación MAS ([MASVS][masvs]) +* Guía de Pruebas MAS ([MASTG][mastg]) +* Hoja de Referencia de OWASP sobre [Seguridad de Aplicaciones Móviles][csmas] ---- +Traducción de versión [original en inglés][release0603]. -[release0603]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/03-mas-checklist.md +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue0603] o [edítelo en GitHub][edit0603]. -\newpage +[release0603]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/03-mas-checklist.md +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit0603]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/03-mas-checklist.md +[issue0603]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/03-mas-checklist +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[masxls]: https://github.com/OWASP/owasp-mastg/releases/latest/download/OWASP_MAS_Checklist.xlsx +[masc]: https://mas.owasp.org/checklists/ +[mastg]: https://mas.owasp.org/MASTG/ +[masvs]: https://mas.owasp.org/MASVS/ diff --git a/release-es/06-design/toc.md b/release-es/06-design/toc.md index a050a0b5..71f55d88 100644 --- a/release-es/06-design/toc.md +++ b/release-es/06-design/toc.md @@ -3,7 +3,7 @@ title: Diseño layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: 46000 permalink: /release-es/diseño/ @@ -22,12 +22,42 @@ permalink: /release-es/diseño/ } -![WIP logo](../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +![Logo de la guía del desarrollador](../../assets/images/dg_logo.png "Guía del Desarrollador OWASP"){: .image-right } ## 4. Diseño -No hay traducción de esta página, consulte [versión original en inglés][release0600]. -Sections: +Refiriéndonos a la [Hoja de Referencia de Diseño de Productos Seguros][spdcs], el propósito de la arquitectura y diseño seguros es garantizar +que todos los productos cumplan o excedan los requisitos de seguridad establecidos por la organización, +enfocándose en la seguridad vinculada a los componentes y tecnologías utilizadas durante el desarrollo de la aplicación. + +El Diseño de Arquitectura Segura examina la selección y composición de componentes que forman la base de la solución. +La Gestión de Tecnología examina la seguridad de las tecnologías de apoyo utilizadas durante el desarrollo, despliegue y operaciones, +como entornos de desarrollo y herramientas, herramientas de despliegue, y sistemas operativos y herramientas. + +Un diseño seguro ayudará a establecer configuraciones predeterminadas seguras, minimizar el área de superficie de ataque +y fallar de manera segura con configuraciones predeterminadas bien definidas y comprendidas. +También considerará y seguirá varios principios, tales como: + +* Privilegio Mínimo y Separación de Funciones +* Defensa en Profundidad +* Confianza Cero +* Seguridad en Abierto + +Un Ciclo de Vida de Desarrollo Seguro (SDLC) ayuda a garantizar que todas las decisiones de seguridad tomadas sobre el producto en desarrollo +sean elecciones explícitas y resulten en el nivel correcto de seguridad para el diseño del producto. +Se pueden utilizar varios ciclos de vida de desarrollo seguro y generalmente incluyen el modelado de amenazas en el proceso de diseño. + +Las Listas de Verificación y Hojas de Referencia son una herramienta importante durante el proceso de diseño; +proporcionan una referencia fácil de conocimiento y ayudan a evitar repetir errores y fallos de diseño. + +El [Diseño][sammd] de aplicaciones de software es una de las principales funciones empresariales descritas en +el [Modelo de Madurez de Aseguramiento de Software (SAMM)][samm], e incluye prácticas de seguridad: + +* [Evaluación de Amenazas][sammdta] +* [Requisitos de Seguridad][sammdsr] +* [Arquitectura de Seguridad][sammdsa] + +Secciones: 4.1 [Modelado de amenazas](01-threat-modeling/toc.md) 4.1.1 [Modelado de amenazas en la práctica](01-threat-modeling/01-threat-modeling.md) @@ -37,20 +67,30 @@ Sections: 4.1.5 [LINDDUN GO](01-threat-modeling/05-linddun-go.md) 4.1.6 [Kit de herramientas de modelado de amenazas](01-threat-modeling/06-toolkit.md) 4.2 [Lista de verificación de aplicaciones web](02-web-app-checklist/toc.md) -4.2.1 [Definir requisitos de seguridad](02-web-app-checklist/01-define-security-requirements.md) -4.2.2 [Aprovechar los frameworks y librerías](02-web-app-checklist/02-frameworks-libraries.md) -4.2.3 [Asegurar el acceso a la base de datos](02-web-app-checklist/03-secure-database-access.md) -4.2.4 [Codificar y escapar caracteres especiales en datos](02-web-app-checklist/04-encode-escape-data.md) -4.2.5 [Validar todas las entradas](02-web-app-checklist/05-validate-inputs.md) -4.2.6 [Implementar identidad digital](02-web-app-checklist/06-digital-identity.md) -4.2.7 [Hacer respetar los controles de acceso](02-web-app-checklist/07-access-controls.md) -4.2.8 [Proteger los datos en todas partes](02-web-app-checklist/08-protect-data.md) -4.2.9 [Implementar registro y monitoreo de seguridad](02-web-app-checklist/09-logging-monitoring.md) -4.2.10 [Manejar todos los errores y excepciones](02-web-app-checklist/10-handle-errors-exceptions.md) -4.3 [Lista de verificación de aplicaciones móviles](03-mas-checklist.md) +4.2.1 [Lista de verificación: Definir requisitos de seguridad](02-web-app-checklist/01-define-security-requirements.md) +4.2.2 [Lista de verificación: Aprovechar marcos de trabajo y bibliotecas de seguridad](02-web-app-checklist/02-frameworks-libraries.md) +4.2.3 [Lista de verificación: Acceso seguro a bases de datos](02-web-app-checklist/03-secure-database-access.md) +4.2.4 [Lista de verificación: Codificar y escapar datos](02-web-app-checklist/04-encode-escape-data.md) +4.2.5 [Lista de verificación: Validar todas las entradas](02-web-app-checklist/05-validate-inputs.md) +4.2.6 [Lista de verificación: Implementar identidad digital](02-web-app-checklist/06-digital-identity.md) +4.2.7 [Lista de verificación: Hacer cumplir controles de acceso](02-web-app-checklist/07-access-controls.md) +4.2.8 [Lista de verificación: Proteger datos en todas partes](02-web-app-checklist/08-protect-data.md) +4.2.9 [Lista de verificación: Implementar registro y monitoreo de seguridad](02-web-app-checklist/09-logging-monitoring.md) +4.2.10 [Lista de verificación: Manejar todos los errores y excepciones](02-web-app-checklist/10-handle-errors-exceptions.md) +4.3 [Lista de verificación MAS](03-mas-checklist.md) ---- +Traducción de versión [original en inglés][release0601]. -Traducción de versión [original en inglés][release0600]. +La Guía del Desarrollador OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue0600] o [edítelo en GitHub][edit0600]. [release0600]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/toc.md +[edit0600]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/toc.md +[issue0600]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/00-toc +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet From 8ebef641d4667940ac7b0c88530464a2997ab122 Mon Sep 17 00:00:00 2001 From: roxana-calderon-owasp Date: Sat, 15 Mar 2025 20:36:09 -0400 Subject: [PATCH 2/4] permalinks back to Spanish --- release-es/04-foundations/01-security-fundamentals.md | 2 +- release-es/04-foundations/02-secure-development.md | 2 +- release-es/04-foundations/03-security-principles.md | 2 +- release-es/04-foundations/04-crypto-principles.md | 2 +- release-es/04-foundations/05-top-ten.md | 4 ++-- release-es/04-foundations/toc.md | 2 +- release-es/05-requirements/00-toc.md | 3 ++- release-es/05-requirements/01-requirements.md | 4 ++-- release-es/05-requirements/02-risk.md | 2 +- release-es/05-requirements/03-opencre.md | 4 ++-- release-es/05-requirements/04-security-rat.md | 4 ++-- release-es/05-requirements/05-asvs.md | 4 ++-- release-es/05-requirements/06-mas.md | 4 ++-- release-es/05-requirements/07-skf.md | 4 ++-- 14 files changed, 22 insertions(+), 21 deletions(-) diff --git a/release-es/04-foundations/01-security-fundamentals.md b/release-es/04-foundations/01-security-fundamentals.md index efdad282..d4ea630f 100644 --- a/release-es/04-foundations/01-security-fundamentals.md +++ b/release-es/04-foundations/01-security-fundamentals.md @@ -6,7 +6,7 @@ tags: Guía del Desarrollador OWASP contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 44010 -permalink: /release-es/foundations/security_fundamentals/ +permalink: /release-es/fundamentos/fundamentos_seguridad/ --- diff --git a/release-es/04-foundations/02-secure-development.md b/release-es/04-foundations/02-secure-development.md index f9b86fbc..b738c909 100644 --- a/release-es/04-foundations/02-secure-development.md +++ b/release-es/04-foundations/02-secure-development.md @@ -6,7 +6,7 @@ tags: Guía del Desarrollador OWASP contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 44020 -permalink: /release-es/foundations/secure_development/ +permalink: /release-es/fundamentos/desarrollo_seguro/ --- diff --git a/release-es/04-foundations/03-security-principles.md b/release-es/04-foundations/03-security-principles.md index 4422e048..34316d18 100644 --- a/release-es/04-foundations/03-security-principles.md +++ b/release-es/04-foundations/03-security-principles.md @@ -6,7 +6,7 @@ tags: Guía del Desarrollador OWASP contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 44030 -permalink: /release-es/foundations/security_principles/ +permalink: /release-es/fundamentos/principios_seguridad/ --- diff --git a/release-es/04-foundations/04-crypto-principles.md b/release-es/04-foundations/04-crypto-principles.md index 674e2d3f..81a7fb08 100644 --- a/release-es/04-foundations/04-crypto-principles.md +++ b/release-es/04-foundations/04-crypto-principles.md @@ -6,7 +6,7 @@ tags: Guía del Desarrollador OWASP contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 44040 -permalink: /release-es/foundations/crypto_principles/ +permalink: /release-es/fundamentos/principios_criptografía/ --- diff --git a/release-es/04-foundations/05-top-ten.md b/release-es/04-foundations/05-top-ten.md index fe58da91..2eedfaff 100644 --- a/release-es/04-foundations/05-top-ten.md +++ b/release-es/04-foundations/05-top-ten.md @@ -3,10 +3,10 @@ title: OWASP Top Ten layout: col-document tags: Guía del Desarrollador OWASP -contributors: Jon Gadsden, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 44050 -permalink: /release-es/foundations/owasp_top_ten/ +permalink: /release-es/fundamentos/owasp_top_ten/ --- diff --git a/release-es/04-foundations/toc.md b/release-es/04-foundations/toc.md index c15e990a..87bd5c28 100644 --- a/release-es/04-foundations/toc.md +++ b/release-es/04-foundations/toc.md @@ -6,7 +6,7 @@ tags: Guía del Desarrollador OWASP contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 44000 -permalink: /release-es/foundations/ +permalink: /release-es/fundamentos/ --- diff --git a/release-es/05-requirements/00-toc.md b/release-es/05-requirements/00-toc.md index 607fb21d..8d09788a 100644 --- a/release-es/05-requirements/00-toc.md +++ b/release-es/05-requirements/00-toc.md @@ -3,7 +3,7 @@ title: Requisitos layout: col-document tags: Guía del Desarrollador OWASP -contributors: Roxana Calderon, Jon Gadsden, Andreas Happe +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: permalink: @@ -46,6 +46,7 @@ Secciones: ---- Traducción de versión [original en inglés][release0500]. + La Guía de Desarrollador OWASP es un esfuerzo comunitario; si hay algo que necesite cambios, [cree un issue][issue0500]. [release0500]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/05-requirements/00-toc.md diff --git a/release-es/05-requirements/01-requirements.md b/release-es/05-requirements/01-requirements.md index 17715f26..2b299db3 100644 --- a/release-es/05-requirements/01-requirements.md +++ b/release-es/05-requirements/01-requirements.md @@ -3,10 +3,10 @@ title: Requisitos en la Práctica layout: col-document tags: Guía del Desarrollador OWASP -contributors: Jon Gadsden, Andreas Happe, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 45010 -permalink: /release-es/requirements/requirements_in_practice/ +permalink: /release-es/requisitos/requisitos_práctica/ --- diff --git a/release-es/05-requirements/02-risk.md b/release-es/05-requirements/02-risk.md index 93e0f801..a4ca928f 100644 --- a/release-es/05-requirements/02-risk.md +++ b/release-es/05-requirements/02-risk.md @@ -6,7 +6,7 @@ tags: Guía del Desarrollador OWASP contributors: Jon Gadsden, Roxana Calderon document: Guía del Desarrollador OWASP order: 45020 -permalink: /release-es/requirements/risk_profile/ +permalink: /release-es/requisitos/perfil_de_riesgo/ --- diff --git a/release-es/05-requirements/03-opencre.md b/release-es/05-requirements/03-opencre.md index b185c878..6f98b564 100644 --- a/release-es/05-requirements/03-opencre.md +++ b/release-es/05-requirements/03-opencre.md @@ -3,10 +3,10 @@ title: OpenCRE layout: col-document tags: Guía del Desarrollador OWASP -contributors: Jon Gadsden, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 45030 -permalink: /release-es/requirements/opencre/ +permalink: /release-es/requisitos/opencre/ --- diff --git a/release-es/05-requirements/04-security-rat.md b/release-es/05-requirements/04-security-rat.md index 716f96d0..5102d55c 100644 --- a/release-es/05-requirements/04-security-rat.md +++ b/release-es/05-requirements/04-security-rat.md @@ -3,10 +3,10 @@ title: SecurityRAT layout: col-document tags: Guía del Desarrollador OWASP -contributors: Jon Gadsden, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 45040 -permalink: /release-es/requirements/security_rat/ +permalink: /release-es/requisitos/securityrat/ --- diff --git a/release-es/05-requirements/05-asvs.md b/release-es/05-requirements/05-asvs.md index 576ced87..1a42485d 100644 --- a/release-es/05-requirements/05-asvs.md +++ b/release-es/05-requirements/05-asvs.md @@ -3,10 +3,10 @@ title: Requisitos ASVS layout: col-document tags: Guía del desarrollador de OWASP -contributors: Jon Gadsden, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 45050 -permalink: /release-es/requirements/asvs/ +permalink: /release-es/requisitos/asvs/ --- diff --git a/release-es/05-requirements/06-mas.md b/release-es/05-requirements/06-mas.md index 0b84e1ef..4d340ddb 100644 --- a/release-es/05-requirements/06-mas.md +++ b/release-es/05-requirements/06-mas.md @@ -3,10 +3,10 @@ title: Requisitos MAS layout: col-document tags: Guía del Desarrollador OWASP -contributors: Jon Gadsden, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 45060 -permalink: /release-es/requirements/mas/ +permalink: /release-es/requisitos/mas/ --- diff --git a/release-es/05-requirements/07-skf.md b/release-es/05-requirements/07-skf.md index e7281809..56672391 100644 --- a/release-es/05-requirements/07-skf.md +++ b/release-es/05-requirements/07-skf.md @@ -3,10 +3,10 @@ title: Requisitos SKF layout: col-document tags: Guía del Desarrollador OWASP -contributors: Jon Gadsden, Roxana Calderon +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 45070 -permalink: /release-es/requirements/skf/ +permalink: /release-es/requisitos/skf/ --- From e0e0a5520d4a87c9e6b22b1d227b87b042860bf2 Mon Sep 17 00:00:00 2001 From: roxana-calderon-owasp Date: Mon, 17 Mar 2025 23:45:17 -0400 Subject: [PATCH 3/4] 06-design folder Spanish Translations --- release-es/05-requirements/toc.md | 4 +- .../06-design/02-web-app-checklist/00-toc.md | 51 +++++--- .../01-define-security-requirements.md | 82 +++++++++--- .../02-frameworks-libraries.md | 105 +++++++++++++--- .../03-secure-database-access.md | 64 +++++++--- .../04-encode-escape-data.md | 62 ++++++--- .../05-validate-inputs.md | 77 +++++++++--- .../06-digital-identity.md | 118 +++++++++++++++--- .../07-access-controls.md | 62 ++++++--- .../02-web-app-checklist/08-protect-data.md | 69 +++++++--- .../09-logging-monitoring.md | 63 +++++++--- .../10-handle-errors-exceptions.md | 62 ++++++--- .../06-design/02-web-app-checklist/toc.md | 51 +++++--- .../01-define-security-requirements.md | 56 ++++----- 14 files changed, 710 insertions(+), 216 deletions(-) diff --git a/release-es/05-requirements/toc.md b/release-es/05-requirements/toc.md index d15fa15e..a4d6f1bc 100644 --- a/release-es/05-requirements/toc.md +++ b/release-es/05-requirements/toc.md @@ -3,10 +3,10 @@ title: Requisitos layout: col-document tags: Guía del desarrollador OWASP -contributors: Jon Gadsden, Andreas Happe, Roxana Calderon +contributors: Roxana Calderon document: Guía del desarrollador OWASP order: 45000 -permalink: /release-es/requirements/ +permalink: /release-es/requisitos/ --- diff --git a/release-es/06-design/02-web-app-checklist/00-toc.md b/release-es/06-design/02-web-app-checklist/00-toc.md index 8d32c493..2102cfc2 100644 --- a/release-es/06-design/02-web-app-checklist/00-toc.md +++ b/release-es/06-design/02-web-app-checklist/00-toc.md @@ -1,9 +1,9 @@ --- -title: Lista de verificación de aplicaciones web +title: Lista de Verificación para Aplicaciones Web layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: @@ -11,27 +11,42 @@ order: {% include breadcrumb.html %} -![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){height=180px} +![logo de la Guía del Desarrollador](../../../assets/images/dg_logo_bbd.png "Guía del Desarrollador OWASP"){height=180px} -### 4.2 Lista de verificación de aplicaciones web +### 4.2 Lista de verificación para aplicaciones web -No hay traducción de esta página, consulte [versión original en inglés][release0602]. +Las listas de verificación son un recurso valioso para los equipos de desarrollo. +Proporcionan estructura para establecer buenas prácticas y procesos +y también son útiles durante las revisiones de código y actividades de diseño. -Sections: +Las listas de verificación que siguen son listas generales categorizadas para seguir los controles enumerados en el +proyecto [Top 10 Controles Proactivos de OWASP][proactive10]. +Estas listas de verificación proporcionan sugerencias que definitivamente deben adaptarse a +los requisitos y entorno específicos de un proyecto; no están destinadas a seguirse en su totalidad. -4.2.1 [Definir requisitos de seguridad](#definir-requisitos-de-seguridad) -4.2.2 [Aprovechar los frameworks y librerías](#aprovechar-los-frameworks-y-librerías) -4.2.3 [Asegurar el acceso a la base de datos](#asegurar-el-acceso-a-la-base-de-datos) -4.2.4 [Codificar y escapar caracteres especiales en datos](#codificar-y-escapar-caracteres-especiales-en-datos) -4.2.5 [Validar todas las entradas](#validar-todas-las-entradas) -4.2.6 [Implementar identidad digital](#implementar-identidad-digital) -4.2.7 [Hacer respetar los controles de acceso](#hacer-respetar-los-controles-de-acceso) -4.2.8 [Proteger los datos en todas partes](#proteger-los-datos-en-todas-partes) -4.2.9 [Implementar registro y monitoreo](#implementar-registro-y-monitoreo) -4.2.10 [Manejar todos los errores y excepciones](#cmanejar-todos-los-errores-y-excepciones) +Probablemente el mejor punto de partida para una lista de verificación es el proporcionado por el [Estándar de Verificación de Seguridad de Aplicaciones (ASVS)][asvs]. +El ASVS puede utilizarse para proporcionar un marco para una lista de verificación inicial, según el nivel de verificación de seguridad, +y esta lista de verificación inicial del ASVS puede ampliarse utilizando las siguientes secciones de la lista de verificación. + +Secciones: + +4.2.1 [Lista de verificación: Definir Requisitos de Seguridad](#checklist-define-security-requirements) +4.2.2 [Lista de verificación: Aprovechar Marcos y Bibliotecas de Seguridad](#checklist-leverage-security-frameworks-and-libraries) +4.2.3 [Lista de verificación: Asegurar el Acceso a la Base de Datos](#checklist-secure-database-access) +4.2.4 [Lista de verificación: Codificar y Escapar Datos](#checklist-encode-and-escape-data) +4.2.5 [Lista de verificación: Validar Todas las Entradas](#checklist-validate-all-inputs) +4.2.6 [Lista de verificación: Implementar Identidad Digital](#checklist-implement-digital-identity) +4.2.7 [Lista de verificación: Aplicar Controles de Acceso](#checklist-enforce-access-controls) +4.2.8 [Lista de verificación: Proteger los Datos en Todas Partes](#checklist-protect-data-everywhere) +4.2.9 [Lista de verificación: Implementar Registro y Monitoreo de Seguridad](#checklist-implement-security-logging-and-monitoring) +4.2.10 [Lista de verificación: Manejar Todos los Errores y Excepciones](#checklist-handle-all-errors-and-exceptions) ---- +Traducción de versión [original en inglés][release0602]. -[release0602]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/toc.md +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, [cree un issue][issue0602]. -\newpage +[release0602]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/toc.md +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[issue0602]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/00-toc +[proactive10]: https://owasp.org/www-project-proactive-controls/ diff --git a/release-es/06-design/02-web-app-checklist/01-define-security-requirements.md b/release-es/06-design/02-web-app-checklist/01-define-security-requirements.md index 30a778dd..1bfe15d4 100644 --- a/release-es/06-design/02-web-app-checklist/01-define-security-requirements.md +++ b/release-es/06-design/02-web-app-checklist/01-define-security-requirements.md @@ -1,9 +1,9 @@ --- -title: Definir requisitos de seguridad +title: Lista de verificación para Definir Requisitos de Seguridad layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46210 permalink: /release-es/diseño/lista_verificación_web/definir_requisitos_seguridad/ @@ -12,24 +12,76 @@ permalink: /release-es/diseño/lista_verificación_web/definir_requisitos_seguri {% include breadcrumb.html %} - +### 4.2.1 Lista de verificación: Definir Requisitos de Seguridad -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +Un requisito de seguridad es una declaración de funcionalidad de seguridad que garantiza que se está satisfaciendo la seguridad del software. +Los requisitos de seguridad se derivan de estándares de la industria, leyes aplicables y un historial de vulnerabilidades pasadas. -### 4.2.1 Definir requisitos de seguridad +Consulte el control proactivo [C4: Abordar la Seguridad desde el Principio][control4] y sus [hojas de referencia][csproactive-c1] +para más contexto del proyecto Top 10 Controles Proactivos de OWASP, +y use las listas a continuación como sugerencias para una lista de verificación adaptada al proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060201]. +#### 1. Configuración del sistema + +1. Restringir aplicaciones, procesos y cuentas de servicio a los mínimos privilegios posibles +2. Si la aplicación debe ejecutarse con privilegios elevados, elevar privilegios lo más tarde posible y reducirlos tan pronto como sea posible +3. Eliminar toda funcionalidad y archivos innecesarios +4. Eliminar código de prueba o cualquier funcionalidad no destinada a producción, antes del despliegue +5. El almacén de configuración de seguridad para la aplicación debe estar disponible en formato legible para humanos para facilitar las auditorías +6. Aislar los entornos de desarrollo de la producción y proporcionar acceso solo a grupos autorizados de desarrollo y prueba +7. Implementar un sistema de control de cambios de software para gestionar y registrar cambios en el código tanto en desarrollo como en producción + +#### 2. Prácticas criptográficas + +1. Utilizar módulos criptográficos de código abierto y revisados por pares +2. Todas las funciones criptográficas utilizadas para proteger secretos del usuario de la aplicación deben implementarse en un sistema confiable +3. Los módulos criptográficos deben fallar de manera segura +4. Asegurarse de que todos los elementos aleatorios como números, nombres de archivo, UUID(identificador único universal) y cadenas se generan + utilizando el generador de números aleatorios aprobado del módulo criptográfico +5. Los módulos criptográficos utilizados por la aplicación cumplen con FIPS 140-2 o un estándar equivalente +6. Establecer y utilizar una política y proceso para la gestión de claves criptográficas +7. Asegurar que cualquier clave secreta esté protegida contra acceso no autorizado +8. Almacenar claves en una bóveda de secretos adecuada como se describe a continuación +9. Utilizar claves independientes cuando se requieren múltiples claves +10. Crear soporte para cambiar algoritmos y claves cuando sea necesario +11. Construir características de la aplicación para manejar una rotación de claves + +#### 3. Gestión de archivos + +1. No pasar datos suministrados por el usuario directamente a ninguna función de inclusión dinámica +2. Requerir autenticación antes de permitir la carga de un archivo +3. Limitar el tipo de archivos que se pueden cargar solo a aquellos tipos que son necesarios para fines del negocio +4. Validar que los archivos cargados son del tipo esperado comprobando las cabeceras de archivo en lugar de la extensión +5. No guardar archivos en el mismo contexto web de la aplicación +6. Prevenir o restringir la carga de cualquier archivo que pueda ser interpretado por el servidor web +7. Desactivar los privilegios de ejecución en los directorios de carga de archivos +8. Al hacer referencia a archivos existentes, utilizar una lista blanca de nombres y tipos de archivos permitidos +9. No pasar datos suministrados por el usuario a una redirección dinámica +10. No pasar rutas de directorio o archivo, utilizar valores de índice mapeados a una lista predefinida de rutas +11. Nunca enviar la ruta absoluta del archivo al cliente +12. Asegurar que los archivos y recursos de la aplicación sean de solo lectura +13. Escanear los archivos cargados por usuarios en busca de virus y malware + +#### Referencias + +* [Estándar de Verificación de Seguridad de Aplicaciones][asvs] (ASVS) de OWASP +* [Seguridad de Aplicaciones Móviles][mas] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060201]. + +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse +entonces [cree un issue][issue060201] o [edítelo en GitHub][edit060201]. [release060201]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/01-define-security-requirements.md +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[csproactive-c1]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c1-define-security-requirements +[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ +[edit060201]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/01-define-security-requirements.md +[issue060201]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/01-define-security-requirements +[mas]: https://mas.owasp.org/ +[proactive10]: https://top10proactive.owasp.org/ + -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/02-frameworks-libraries.md b/release-es/06-design/02-web-app-checklist/02-frameworks-libraries.md index 5fecba03..541f353c 100644 --- a/release-es/06-design/02-web-app-checklist/02-frameworks-libraries.md +++ b/release-es/06-design/02-web-app-checklist/02-frameworks-libraries.md @@ -1,9 +1,9 @@ --- -title: Aprovechar los frameworks y librerías +title: Lista de verificación para Aprovechar Marcos y Bibliotecas de Seguridad layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46220 permalink: /release-es/diseño/lista_verificación_web/aprovechar_frameworks_librerías/ @@ -12,24 +12,99 @@ permalink: /release-es/diseño/lista_verificación_web/aprovechar_frameworks_lib {% include breadcrumb.html %} - +### 4.2.2 Lista de verificación: Aprovechar Marcos y Bibliotecas de Seguridad -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +Las bibliotecas de código seguro y los marcos de software con seguridad integrada ayudan a los desarrolladores a protegerse contra +fallos de diseño e implementación relacionados con la seguridad. -### 4.2.2 Aprovechar los frameworks y librerías +Consulte el control proactivo [C4: Abordar la Seguridad desde el Principio][control4] +y sus [hojas de referencia][csproactive-c2] para más contexto del proyecto Top 10 Controles Proactivos de OWASP. -No hay traducción de esta página, consulte [versión original en inglés][release060202]. +Para listas de verificación específicas de tecnología, consulte las Hojas de Referencia de OWASP apropiadas: + +* [Seguridad AJAX][csajax] +* [Fortalecimiento de seguridad de la cadena de herramientas basada en C][cscbased] +* [Seguridad Django][csdjango] +* [Django REST framework][csdjangorest] +* [Seguridad Docker][csdocker] +* [Seguridad DotNet][csdotnet] +* [Seguridad GraphQL][csgraphql] +* [Infraestructura como Código][csias] +* [Seguridad Java][csjava] +* [Gestión de Javascript][csjcavascript] +* [Kubernetes][cskube] +* [Seguridad Laravel][cslaravel] +* [Seguridad de Microservicios][csmicro] +* [Mejores prácticas de seguridad NPM][csnpm] +* [Seguridad Node.js][csnode] +* [Seguridad Node.js para Docker][csnodedocker] +* [Configuración PHP][csphp] +* [APIs REST][csrest] y [cómo evaluarlas][csrassess] +* [Seguridad Ruby on Rails][csruby] +* [Framework Symfony][cssymfony] +* [Servicios Web][cswebservice] +* [Seguridad XML][csxml] + +y utilícelas como punto de partida para una lista de verificación adaptada a la tecnología utilizada por el proyecto. + +Además, considere las siguientes comprobaciones adicionales para marcos y bibliotecas. + +#### 1. Marcos y Bibliotecas de Seguridad + +1. Asegurar que los servidores, marcos y componentes del sistema ejecuten las últimas versiones y parches aprobados +2. Utilizar bibliotecas y marcos de fuentes confiables que se mantengan activamente y sean ampliamente utilizados +3. Revisar todas las aplicaciones secundarias y bibliotecas de terceros para determinar la necesidad empresarial +4. Validar la funcionalidad segura de todas las aplicaciones secundarias y bibliotecas de terceros +5. Crear y mantener un catálogo de inventario de todas las bibliotecas de terceros utilizando Análisis de Composición de Software (SCA) +6. Mantener proactivamente actualizadas todas las bibliotecas y componentes de terceros +7. Reducir la superficie de ataque encapsulando la biblioteca y exponiendo solo el comportamiento requerido en su software +8. Utilizar código administrado testeado y aprobado en lugar de crear nuevo código no administrado para tareas comunes +9. Utilizar APIs específicas para tareas integradas para realizar tareas del sistema operativo +10. No permitir que la aplicación emita comandos directamente al Sistema Operativo +11. Utilizar sumas de verificación o hashes para verificar la integridad del código interpretado, bibliotecas, ejecutables y archivos de configuración +12. Restringir a los usuarios la generación de nuevo código o la alteración del código existente +13. Implementar actualizaciones seguras utilizando canales cifrados + +#### Referencias + +* [Dependency Check][dependency] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060202]. + +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse +entonces [envía un issue][issue060202] o [edita en GitHub][edit060202]. [release060202]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/02-frameworks-libraries.md +[csajax]: https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet +[cscbased]: https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet +[csdjango]: https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet +[csdjangorest]: https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet +[csdocker]: https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet +[csdotnet]: https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet +[csgraphql]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet +[csias]: https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet +[csjava]: https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet +[csjcavascript]: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet +[cskube]: https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet +[cslaravel]: https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet +[csmicro]: https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet +[csnpm]: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet +[csnode]: https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet +[csnodedocker]: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet +[csphp]: https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet +[csrest]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet +[csrassess]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[csruby]: https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet +[cssymfony]: https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet +[cswebservice]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet +[csxml]: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet +[csproactive-c2]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c2-leverage-security-frameworks-and-libraries +[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ +[dependency]: https://owasp.org/www-project-dependency-check/ +[edit060202]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/02-frameworks-libraries.md +[issue060202]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/02-frameworks-libraries +[proactive10]: https://top10proactive.owasp.org/ -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/03-secure-database-access.md b/release-es/06-design/02-web-app-checklist/03-secure-database-access.md index ac27e96b..7fda6a6b 100644 --- a/release-es/06-design/02-web-app-checklist/03-secure-database-access.md +++ b/release-es/06-design/02-web-app-checklist/03-secure-database-access.md @@ -1,9 +1,9 @@ --- -title: Asegurar el acceso a la base de datos +title: Lista de Comprobación para Acceso Seguro a Bases de Datos layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46230 permalink: /release-es/diseño/lista_verificación_web/asegurar_base_datos/ @@ -12,24 +12,60 @@ permalink: /release-es/diseño/lista_verificación_web/asegurar_base_datos/ {% include breadcrumb.html %} - +### 4.2.3 Lista de comprobación: Acceso Seguro a Bases de Datos -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +Asegure que el acceso a todos los almacenes de datos sea seguro, incluyendo tanto bases de datos relacionales como bases de datos NoSQL. -### 4.2.3 Asegurar el acceso a la base de datos +Consulte el control proactivo [C3: Validar todas las Entradas y Manejar Excepciones][control3] y sus [hojas de referencia][csproactive-c3] +para más contexto sobre el proyecto Top 10 Controles Proactivos de OWASP, +y use la lista a continuación como sugerencias para una lista de comprobación adaptada al proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060203]. +#### 1. Consultas seguras + +1. Utilizar Parametrización de Consultas para evitar que entradas no confiables sean interpretadas como parte de un comando SQL +2. Utilizar consultas parametrizadas fuertemente tipadas +3. Utilizar validación de entrada y codificación de salida, asegurándose de encargarse de los meta caracteres +4. No ejecutar el comando de base de datos si la validación de entrada falla +5. Asegurar que las variables estén fuertemente tipadas +6. Las cadenas de conexión no deben estar codificadas de forma fija dentro de la aplicación +7. Las cadenas de conexión deben almacenarse en un archivo de configuración separado en un sistema confiable y deben estar cifradas + +#### 2. Configuración segura + +1. La aplicación debe usar el nivel más bajo posible de privilegios al acceder a la base de datos +2. Utilizar procedimientos almacenados para abstraer el acceso a datos y permitir la eliminación de permisos a las tablas base en la base de datos +3. Cerrar la conexión de la base de datos tan pronto como sea posible +4. Desactivar toda funcionalidad innecesaria de la base de datos +5. Eliminar contenido predeterminado innecesario del proveedor, por ejemplo esquemas de muestra +6. Deshabilitar cualquier cuenta predeterminada que no sea necesaria para soportar los requisitos del negocio + +#### 3. Autenticación segura + +1. Eliminar o cambiar todas las contraseñas administrativas predeterminadas de la base de datos +2. La aplicación debe conectarse a la base de datos con credenciales diferentes para cada nivel de confianza + (por ejemplo, usuario, usuario de solo lectura, invitado, administradores) +3. Utilizar credenciales seguras para el acceso a la base de datos + +#### Referencias + +* [Hoja de Referencia: Parametrización de Consultas][csquery] de OWASP +* [Hoja de Referencia: Seguridad de Bases de Datos][csdb]de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060203]. + +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse +entonces [cree un issue][issue060203] o [edítelo en GitHub][edit060203]. [release060203]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/03-secure-database-access.md +[csproactive-c3]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c3-secure-database-access +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[csdb]: https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet +[csquery]: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet +[edit060203]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/03-secure-database-access.md +[issue060203]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/03-secure-database-access +[proactive10]: https://top10proactive.owasp.org/ + \newpage diff --git a/release-es/06-design/02-web-app-checklist/04-encode-escape-data.md b/release-es/06-design/02-web-app-checklist/04-encode-escape-data.md index f10bea4d..0aa53798 100644 --- a/release-es/06-design/02-web-app-checklist/04-encode-escape-data.md +++ b/release-es/06-design/02-web-app-checklist/04-encode-escape-data.md @@ -1,9 +1,9 @@ --- -title: Codificar y escapar caracteres especiales en datos +title: Lista de Comprobación para Codificar y Escapar Datos layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46240 permalink: /release-es/diseño/lista_verificación_web/codificar_escapar_datos/ @@ -12,24 +12,56 @@ permalink: /release-es/diseño/lista_verificación_web/codificar_escapar_datos/ {% include breadcrumb.html %} - +### 4.2.4 Lista de comprobación: Codificar y Escapar Datos -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +La codificación y el escapado de datos de salida son técnicas defensivas destinadas a detener ataques de inyección +en un sistema o aplicación objetivo que está recibiendo los datos de salida. -### 4.2.4 Codificar y escapar caracteres especiales en datos +El sistema objetivo puede ser otro componente de software o puede reflejarse de nuevo en el sistema inicial, +como comandos del sistema operativo, +por lo que codificar y escapar datos de salida ayuda a proporcionar defensa en profundidad para el sistema en su conjunto. -No hay traducción de esta página, consulte [versión original en inglés][release060204]. +Consulte el control proactivo [C3: Validar todas las Entradas y Manejar Excepciones][control3] y sus [hojas de referencia][csproactive-c4] +para más contexto del proyecto OWASP Top 10 Controles Proactivos, +y use la lista a continuación como sugerencias para una lista de comprobación adaptada al proyecto individual. + +#### 1. Codificación de caracteres y canonicalización + +1. Aplicar codificación a la salida justo antes de que el contenido sea pasado al sistema objetivo +2. Realizar toda la codificación de salida en un sistema confiable +3. Utilizar una rutina estándar y probada para cada tipo de codificación de salida +4. Especificar conjuntos de caracteres, como UTF-8, para todas las salidas +5. Aplicar canonicalización para convertir datos unicode en una forma estándar +6. Asegurar que la codificación de salida sea segura para todos los sistemas objetivo +7. En particular, desinfectar todas las salidas utilizadas para comandos del sistema operativo + +#### 2. Codificación contextual de salida + +La codificación contextual de salida de datos se basa en cómo será utilizada por el objetivo. +Los métodos específicos varían dependiendo de la forma en que se utilizan los datos de salida, como la codificación de entidades HTML. + +1. Codificar contextualmente todos los datos devueltos al cliente desde fuentes no confiables +2. Codificar contextualmente toda la salida de datos no confiables en consultas para SQL, XML y LDAP + +#### Referencias + +* [Hoja de Referencia: Prevención de Inyección][ipcs] de OWASP +* [Proyecto Java Encoder][encoder] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060204]. + +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse +entonces [cree un issue][issue060204] o [edítelo en GitHub][edit060204]. [release060204]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/04-encode-escape-data.md +[csproactive-c4]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c4-encode-and-escape-data +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[edit060204]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/04-encode-escape-data.md +[encoder]: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project +[ipcs]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet +[issue060204]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/04-encode-escape-data +[proactive10]: https://top10proactive.owasp.org/ -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/05-validate-inputs.md b/release-es/06-design/02-web-app-checklist/05-validate-inputs.md index 4d4e4926..a49e52e5 100644 --- a/release-es/06-design/02-web-app-checklist/05-validate-inputs.md +++ b/release-es/06-design/02-web-app-checklist/05-validate-inputs.md @@ -1,9 +1,9 @@ --- -title: Validar todas las entradas +title: Lista de Verificación para Validar Todas las Entradas layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46250 permalink: /release-es/diseño/lista_verificación_web/validar_entradas/ @@ -12,24 +12,71 @@ permalink: /release-es/diseño/lista_verificación_web/validar_entradas/ {% include breadcrumb.html %} - +### 4.2.5 Lista de Verificación: Validar Todas las Entradas -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +La validación de entradas es una colección de técnicas que aseguran que solo los datos con formato adecuado +puedan ingresar a una aplicación de software o componente del sistema. -### 4.2.5 Validar todas las entradas +Es vital que se realice la validación de entradas para proporcionar el punto de partida para una aplicación o sistema seguro. +Sin validación de entradas, la aplicación/sistema de software seguirá siendo vulnerable a ataques nuevos y variados. -No hay traducción de esta página, consulte [versión original en inglés][release060205]. +Consulte el control proactivo [C3: Validar Todas las Entradas y Manejar Excepciones][control3] y sus [hojas de referencia][csproactive-c5] +para más contexto del proyecto Top 10 Controles Proactivos de OWASP, +y use la lista a continuación como sugerencias para una lista de verificación adaptada al proyecto individual. + +#### 1. Validez sintáctica y semántica + +1. Identificar todas las fuentes de datos y clasificarlas en confiables y no confiables +2. Validar todos los datos de entrada de fuentes no confiables, como datos proporcionados por el cliente +3. Codificar la entrada a un conjunto de caracteres común antes de validar +4. Especificar conjuntos de caracteres, como UTF-8, para todas las fuentes de entrada +5. Si el sistema admite conjuntos de caracteres extendidos UTF-8, validar después de completar la decodificación UTF-8 +6. Verificar que los valores de encabezado del protocolo en solicitudes y respuestas contengan solo caracteres ASCII +7. Validar datos de redirecciones +8. Validar el rango de datos y también la longitud de datos +9. Utilizar la canonicalización para tratar con ataques de ofuscación +10. Todos los fallos de validación deben resultar en el rechazo de la entrada + +#### 2. Bibliotecas y frameworks + +1. Realizar toda la validación de entrada en un sistema confiable [^SCP1] +2. Usar una biblioteca o framework de validación de entrada centralizado para toda la aplicación +3. Si la rutina de validación estándar no puede hacerse cargo de algunas entradas, use verificaciones discretas adicionales +4. Si cualquier entrada potencialmente peligrosa _debe_ permitirse, implemente controles adicionales +5. Validar para los tipos de datos esperados utilizando una lista de permitidos en lugar de una lista de denegados + +#### 3. Validar datos serializados + +1. Implementar verificaciones de integridad o cifrado de los objetos serializados + para prevenir la creación de objetos hostiles o la manipulación de datos +2. Aplicar restricciones estrictas de tipo durante la deserialización antes de la creación de objetos; + típicamente se espera un conjunto definible de clases +3. Aislar las funciones que hacen deserialización para que se ejecuten en entornos de muy bajo privilegio, como contenedores temporales +4. Registrar excepciones y fallos de deserialización de seguridad +5. Restringir o monitorear la conectividad de red entrante y saliente de contenedores o servidores que deserializan +6. Monitorear la deserialización, por ejemplo, alertando si un agente de usuario deserializa constantemente + +#### Referencias + +* [Hoja de Referencia: Validación de Entrada][ivcs] de OWASP +* [Proyecto Java HTML Sanitizer][sanitizer] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060205]. + +La Guía del Desarrollador de OWASP es un esfuerzo comunitario; si hay algo que necesita cambiar, +entonces [cree un issue][issue060205] o [edítelo en GitHub][edit060205]. + +[^SCP1]: Lista de verificación de prácticas de codificación segura [release060205]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/05-validate-inputs.md +[csproactive-c5]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c5-validate-all-inputs +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[ivcs]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet +[edit060205]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/05-validate-inputs.md +[issue060205]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/05-validate-inputs +[proactive10]: https://top10proactive.owasp.org +[sanitizer]: https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/06-digital-identity.md b/release-es/06-design/02-web-app-checklist/06-digital-identity.md index ed6bfadf..0acc6341 100644 --- a/release-es/06-design/02-web-app-checklist/06-digital-identity.md +++ b/release-es/06-design/02-web-app-checklist/06-digital-identity.md @@ -1,9 +1,9 @@ --- -title: Implementar identidad digital +title: Lista de Verificación para Implementar Identidad Digital layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46260 permalink: /release-es/diseño/lista_verificación_web/identidad_digital/ @@ -12,24 +12,112 @@ permalink: /release-es/diseño/lista_verificación_web/identidad_digital/ {% include breadcrumb.html %} - +### 4.2.6 Lista de Verificación: Implementar Identidad Digital -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +La [autenticación][csauthn] es el proceso de verificar que un individuo o entidad es quien dice ser. +La gestión de sesiones es un proceso mediante el cual un servidor mantiene el estado de la autenticación de los usuarios +para que el usuario pueda continuar utilizando el sistema sin tener que volver a autenticarse. -### 4.2.6 Implementar identidad digital +Consulte el control proactivo [C7: Implementar Identidad Digital][control7] y sus [hojas de referencia][csproactive-c6] +para obtener más contexto del proyecto OWASP Top 10 Controles Proactivos, +y utilice la lista a continuación como sugerencias para una lista de verificación adaptada para el proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060206]. +#### 1. Autenticación + +1. Diseñar a fondo la autenticación del control de acceso desde el principio +2. Forzar que todas las solicitudes pasen por controles de acceso a menos que sean públicas +3. No codificar de forma fija (hard code) controles de acceso basados en roles +4. Registrar todos los eventos de control de acceso +5. Utilizar [Autenticación Multi-Factor][csmfa] (MFA) para cuentas transaccionales sensibles o de alto valor + +#### 2. Contraseñas + +1. Requerir autenticación para todas las páginas y recursos, excepto aquellos específicamente destinados a ser públicos +2. Todos los controles de autenticación deben aplicarse en un sistema confiable +3. Establecer y utilizar servicios de autenticación estándar y probados siempre que sea posible +4. Utilizar una implementación centralizada para todos los controles de autenticación +5. Segregar la lógica de autenticación del recurso solicitado y + utilizar redirección hacia y desde el control de autenticación centralizado +6. Todos los controles de autenticación deben fallar de manera segura +7. La administración y gestión de cuentas debe ser al menos tan segura como el mecanismo de autenticación principal +8. Si su aplicación gestiona un almacén de credenciales, utilice hashes unidireccionales criptográficamente fuertes con un salt +9. El hash de contraseñas debe implementarse en un sistema confiable +10. Validar los datos de autenticación solo al completar toda la entrada de datos +11. Las respuestas de fallo de autenticación no deben indicar qué parte de los datos de autenticación fue incorrecta +12. Utilizar autenticación para conexiones a sistemas externos que involucren información o funciones confidenciales +13. Las credenciales de autenticación para acceder a servicios externos a la aplicación deben almacenarse en un almacén seguro +14. Utilizar solo solicitudes HTTP POST para transmitir credenciales de autenticación +15. Enviar contraseñas no temporales solo a través de una conexión cifrada o como datos cifrados +16. Aplicar requisitos de complejidad y longitud de contraseña establecidos por políticas o regulaciones +17. Aplicar la desactivación de cuentas después de un número establecido de intentos de inicio de sesión no válidos +18. Las operaciones de restablecimiento y cambio de contraseña requieren el mismo nivel de controles que la creación de cuentas y la autenticación +19. Las preguntas de restablecimiento de contraseña están en desuso, consulte [Hoja de Referencia sobre Elegir y Usar Preguntas de Seguridad][csquestions] para saber por qué +20. Si utiliza restablecimientos basados en correo electrónico, envíe correo electrónico solo a una dirección preregistrada con un enlace/contraseña temporal +21. Las contraseñas y enlaces temporales deben tener un tiempo de caducidad corto +22. Aplicar el cambio de contraseñas temporales en el próximo uso +23. Notificar a los usuarios cuando ocurre un restablecimiento de contraseña +24. Prevenir la reutilización de contraseñas +25. El último uso (exitoso o no exitoso) de una cuenta de usuario debe informarse al usuario + en su próximo inicio de sesión exitoso +26. Cambiar todas las contraseñas e ID de usuario predeterminados proporcionados por el proveedor o deshabilitar las cuentas asociadas +27. Volver a autenticar a los usuarios antes de realizar operaciones críticas +28. Si utiliza código de terceros para la autenticación, inspeccione el código cuidadosamente + para asegurarse de que no esté afectado por ningún código malicioso + +#### 3. Autenticación basada en criptografía + +1. Utilizar los controles de gestión de sesiones del servidor o del framework +2. La creación de identificadores de sesión siempre debe realizarse en un sistema confiable +3. Los controles de gestión de sesiones deben utilizar algoritmos cuidadosamente probados que garanticen identificadores de sesión suficientemente aleatorios +4. Establecer el dominio y la ruta para las cookies que contienen identificadores de sesión autenticados + a un valor apropiadamente restringido para el sitio +5. La funcionalidad de cierre de sesión debe terminar completamente la sesión o conexión asociada +6. La funcionalidad de cierre de sesión debe estar disponible en todas las páginas protegidas por autorización +7. Establecer un tiempo de espera de inactividad de sesión que sea lo más corto posible, + basado en equilibrar el riesgo y los requisitos funcionales del negocio +8. No permitir inicios de sesión persistentes y aplicar terminaciones periódicas de sesión, incluso cuando la sesión está activa +9. Si se estableció una sesión antes del inicio de sesión, cierre esa sesión y establezca una nueva después de un inicio de sesión exitoso +10. Genere un nuevo identificador de sesión en cualquier reautenticación +11. No permitir inicios de sesión concurrentes con el mismo ID de usuario +12. No exponer identificadores de sesión en URLs, mensajes de error o registros +13. Implementar controles de acceso apropiados para proteger los datos de sesión del lado del servidor + de acceso no autorizado por parte de otros usuarios del servidor +14. Generar periódicamente un nuevo identificador de sesión y desactivar el antiguo +15. Generar un nuevo identificador de sesión si la seguridad de la conexión cambia de HTTP a HTTPS, + como puede ocurrir durante la autenticación +16. Establecer el atributo `secure` para las cookies transmitidas a través de una conexión [TLS][tls] +17. Establecer cookies con el atributo `HttpOnly`, + a menos que específicamente requiera scripts del lado del cliente dentro de su aplicación para leer o establecer un valor de cookie + +#### Referencias + +* [Hoja de Referencia: Autenticación][csauthn] de OWASP +* [Hoja de Referencia: Autenticación][csauthn] de OWASP +* [Hoja de Referencia: Elegir y Usar Preguntas de Seguridad][csquestions] de OWASP +* [Hoja de Referencia: Contraseña Olvidada][csforgot] de OWASP +* [Hoja de Referencia: Autenticación Multifactor][csmfa] de OWASP +* [Hoja de Referencia: Almacenamiento de Contraseñas][cspass] de OWASP +* [Hoja de Referencia: Gestión de Sesiones][cssession] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060206]. + +La Guía para Desarrolladores OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060206] o [edítelo en GitHub][edit060206]. [release060206]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/06-digital-identity.md +[csproactive-c6]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c6-implement-digital-identity +[control7]: https://top10proactive.owasp.org/the-top-10/c7-secure-digital-identities/ +[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet +[csmfa]: https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet +[cspass]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet +[csforgot]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet +[cssession]: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet +[csquestions]: https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet +[edit060206]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/06-digital-identity.md +[issue060206]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/06-digital-identity +[proactive10]: https://top10proactive.owasp.org +[tls]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/07-access-controls.md b/release-es/06-design/02-web-app-checklist/07-access-controls.md index 51e30ae5..2e8d3824 100644 --- a/release-es/06-design/02-web-app-checklist/07-access-controls.md +++ b/release-es/06-design/02-web-app-checklist/07-access-controls.md @@ -1,35 +1,65 @@ --- -title: Hacer respetar los controles de acceso +title: Lista de Verificación para Aplicar Controles de Acceso layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP -order: 46270 +order: 6270 permalink: /release-es/diseño/lista_verificación_web/controles_acceso/ --- {% include breadcrumb.html %} - +### 4.2.7 Lista de Verificación: Aplicar Controles de Acceso -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +El Control de Acceso o [Autorización][csauthz] es el proceso de conceder o denegar solicitudes específicas +de un usuario, programa o proceso. -### 4.2.7 Hacer respetar los controles de acceso +Consulte el control proactivo [C1: Implementar Controles de Acceso][control1] y sus [hojas de referencia][csproactive-c7] +para obtener más contexto del proyecto OWASP Top 10 Controles Proactivos, +y utilice la lista a continuación como sugerencias para una lista de verificación adaptada para el proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060207]. +#### 1. Autorización + +1. Diseñar el control de acceso / autorización a fondo desde el principio +2. Forzar que todas las solicitudes pasen por verificaciones de control de acceso a menos que sean públicas +3. Denegar por defecto; si una solicitud no está específicamente permitida, entonces es denegada +4. Aplicar el privilegio mínimo, proporcionando el menor acceso que sea necesario +5. Registrar todos los eventos de autorización + +#### 2. Control de acceso + +1. Obligar al uso de controles de autorización en cada solicitud +2. Utilizar solo objetos de sistema confiables para tomar decisiones de autorización de acceso +3. Utilizar un único componente para todo el sitio para verificar la autorización de acceso +4. Los controles de acceso deben fallar de manera segura +5. Denegar todo acceso si la aplicación no puede acceder a su información de configuración de seguridad +6. Segregar la lógica privilegiada del resto del código de la aplicación +7. Limitar el número de transacciones que un solo usuario o dispositivo puede realizar en un período de tiempo determinado, + lo suficientemente bajo para disuadir ataques automatizados pero por encima del requisito real del negocio +8. Si se permiten sesiones autenticadas largas, revalidar periódicamente la autorización de un usuario +9. Implementar auditoría de cuentas y hacer obligatoria la desactivación de cuentas no utilizadas +10. La aplicación debe admitir la terminación de sesiones cuando cese la autorización + +#### Referencias + +* [Hoja de Referencia: Autorización][csauthz] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060207]. + +La Guía para Desarrolladores OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060207] o [edítelo en GitHub][edit060207]. [release060207]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/07-access-controls.md +[csproactive-c7]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c7-enforce-access-controls +[control1]: https://top10proactive.owasp.org/the-top-10/c1-accesscontrol/ +[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet +[edit060207]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/07-access-controls.md +[issue060207]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/07-access-controls +[proactive10]: https://top10proactive.owasp.org/ -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/08-protect-data.md b/release-es/06-design/02-web-app-checklist/08-protect-data.md index 5f5b9570..2627820c 100644 --- a/release-es/06-design/02-web-app-checklist/08-protect-data.md +++ b/release-es/06-design/02-web-app-checklist/08-protect-data.md @@ -1,35 +1,72 @@ --- -title: Proteger los datos en todas partes +title: Lista de Verificación para Proteger Datos en Todas Partes layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46280 -permalink: /release-es/diseño/lista_verificación_web/proteger_datos/ +permalink: /release/design/web_app_checklist/protect_data/ --- {% include breadcrumb.html %} - +### 4.2.8 Lista de Verificación: Proteger Datos en Todas Partes -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +Los datos sensibles como contraseñas, números de tarjetas de crédito, registros médicos, información personal y secretos comerciales +requieren protección adicional, particularmente si esos datos están sujetos a leyes de privacidad (Reglamento General de Protección de Datos de la UE, GDPR), +reglas de protección de datos financieros como el Estándar de Seguridad de Datos para la Industria de Tarjetas de Pago (PCI DSS) u otras regulaciones. -### 4.2.8 Proteger los datos en todas partes +Consulte el control proactivo [C2: Usar la Criptografía de manera adecuada][control2] y sus [hojas de referencia][csproactive-c8] +para obtener más contexto del proyecto OWASP Top 10 Controles Proactivos, +y utilice la lista a continuación como sugerencias para una lista de verificación adaptada para el proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060208]. +#### 1. Protección de datos + +1. Clasificar los datos según el nivel de sensibilidad +2. Implementar controles de acceso apropiados para datos sensibles +3. Cifrar datos en tránsito +4. Asegurar que los canales de comunicación seguros estén configurados correctamente +5. Evitar almacenar datos sensibles cuando sea posible +6. Asegurar que los datos sensibles en reposo estén protegidos criptográficamente para evitar divulgación y modificación no autorizada +7. Eliminar datos sensibles cuando ya no sean necesarios +8. Almacenar secretos a nivel de aplicación en una bóveda de secretos +9. Verificar que los secretos no estén almacenados en código, archivos de configuración o variables de entorno +10. Implementar el privilegio mínimo, restringiendo el acceso a funcionalidades, datos e información del sistema +11. Proteger todas las copias en caché o temporales de datos sensibles contra acceso no autorizado +12. Eliminar esas copias temporales de datos sensibles tan pronto como ya no sean necesarias + +#### 2. Gestión de memoria + +1. Inicializar explícitamente todas las variables y almacenes de datos +2. Verificar que los búferes sean tan grandes como se especifica +3. Comprobar los límites del búfer si se llama a la función en un bucle y proteger contra desbordamientos +4. Cerrar específicamente los recursos, no depender del recolector de basura +5. Usar pilas no ejecutables cuando estén disponibles +6. Liberar correctamente la memoria asignada al completar las funciones y en todos los puntos de salida +7. Sobrescribir cualquier información sensible almacenada en la memoria asignada en todos los puntos de salida de la función +8. Proteger las variables y recursos compartidos contra el acceso concurrente inapropiado + +#### Referencias + +* [Hoja de Referencia: Almacenamiento Criptográfico][cscs] de OWASP +* [Hoja de Referencia: Gestión de Secretos][cssm] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060208]. + +La Guía para Desarrolladores OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060208] o [edítelo en GitHub][edit060208]. [release060208]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/08-protect-data.md +[csproactive-c8]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c8-protect-data-everywhere +[control2]: https://top10proactive.owasp.org/the-top-10/c2-crypto/ +[cscs]: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet +[cssm]: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet +[edit060208]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/08-protect-data.md +[issue060208]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/08-protect-data +[proactive10]: https://top10proactive.owasp.org/ -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/09-logging-monitoring.md b/release-es/06-design/02-web-app-checklist/09-logging-monitoring.md index 689c5ecf..faa00431 100644 --- a/release-es/06-design/02-web-app-checklist/09-logging-monitoring.md +++ b/release-es/06-design/02-web-app-checklist/09-logging-monitoring.md @@ -1,9 +1,9 @@ --- -title: Implementar registro y monitoreo +title: Lista de Verificación para Implementar Registro y Monitoreo de Seguridad layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46290 permalink: /release-es/diseño/lista_verificación_web/registro_monitoreo/ @@ -12,24 +12,57 @@ permalink: /release-es/diseño/lista_verificación_web/registro_monitoreo/ {% include breadcrumb.html %} - +### 4.2.9 Lista de Verificación: Implementar Registro y Monitoreo de Seguridad -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +El registro es la grabación de información de seguridad durante la operación en tiempo de ejecución de una aplicación. +El monitoreo es la revisión en vivo de los registros de aplicaciones y seguridad utilizando varias formas de automatización. -### 4.2.9 Implementar registro y monitoreo +Consulte el control proactivo [C9: Implementar Registro y Monitoreo de Seguridad][control9] +y sus [hojas de referencia][csproactive-c9] para obtener más contexto del proyecto OWASP Top 10 Controles Proactivos, +y utilice la lista a continuación como sugerencias para una lista de verificación adaptada para el proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060209]. +#### 1. Registro de seguridad + +1. Registrar datos enviados que estén fuera de un rango numérico esperado. +2. Registrar datos enviados que impliquen cambios en datos que no deberían ser modificables +3. Registrar solicitudes que violen las reglas de control de acceso del lado del servidor +4. Codificar y validar cualquier carácter peligroso antes de registrar para prevenir ataques de inyección en registros +5. No registrar información sensible +6. Los controles de registro deben admitir tanto el éxito como el fracaso de eventos de seguridad especificados +7. No almacenar información sensible en los registros, incluidos detalles innecesarios del sistema, identificadores de sesión o contraseñas +8. Utilizar una función hash criptográfica para validar la integridad de las entradas de registro + +#### 2. Diseño de registro de seguridad + +1. Proteger la integridad del registro +2. Asegurar que las entradas de registro que incluyen datos no confiables no se ejecutarán como código en la interfaz o software de visualización de registros previsto +3. Restringir el acceso a los registros solo a individuos autorizados +4. Utilizar una rutina central para todas las operaciones de registro +5. Reenviar registros de sistemas distribuidos a un servicio de registro central y seguro +6. Seguir un formato y enfoque de registro común dentro del sistema y entre sistemas de una organización +7. Sincronizar entre nodos para garantizar que las marcas de tiempo sean consistentes +8. Todos los controles de registro deben implementarse en un sistema confiable +9. Asegurar que exista un mecanismo para realizar análisis de registros + +#### Referencias + +* [Hoja de Referencia: Registro][cslogging] de OWASP +* [Hoja de Referencia: Vocabulario de Registro de Aplicaciones][csvocabulary] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060209]. + +La Guía para Desarrolladores OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060209] o [edítelo en GitHub][edit060209]. [release060209]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/09-logging-monitoring.md +[csproactive-c9]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c9-implement-security-logging-and-monitoring +[control9]: https://top10proactive.owasp.org/the-top-10/c9-security-logging-and-monitoring/ +[cslogging]: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet +[csvocabulary]: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet +[edit060209]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/09-logging-monitoring.md +[issue060209]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/09-logging-monitoring +[proactive10]: https://top10proactive.owasp.org/ -\newpage +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/10-handle-errors-exceptions.md b/release-es/06-design/02-web-app-checklist/10-handle-errors-exceptions.md index 40e18d38..ae9608c8 100644 --- a/release-es/06-design/02-web-app-checklist/10-handle-errors-exceptions.md +++ b/release-es/06-design/02-web-app-checklist/10-handle-errors-exceptions.md @@ -1,35 +1,63 @@ --- -title: Manejar todos los errores y excepciones +title: Lista de Verificación para Manejar todos los Errores y Excepciones layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46300 -permalink: /release-es/diseño/lista_verificación_web/errores_excepciones/ +permalink: /release/design/web_app_checklist/handle_errors_and_exceptions/ --- {% include breadcrumb.html %} - +### 4.2.10 Lista de Verificación: Manejar todos los Errores y Excepciones -![WIP logo](../../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +Manejar [excepciones y errores][cserror] correctamente es crítico para hacer que su código sea confiable y seguro. +El manejo de errores y excepciones ocurre en todas las áreas de una aplicación, incluyendo la lógica crítica del negocio +así como las características de seguridad y el código del framework. -### 4.2.10 Manejar todos los errores y excepciones +Consulte el control proactivo [C3: Validar todas las Entradas y Manejar Excepciones][control3] +y sus [hojas de referencia][csproactive-c10] para obtener más contexto del proyecto OWASP Top 10 Controles Proactivos, +y utilice la lista a continuación como sugerencias para una lista de verificación adaptada para el proyecto individual. -No hay traducción de esta página, consulte [versión original en inglés][release060210]. +#### 1. Errores y excepciones + +1. Gestionar las excepciones de manera centralizada para evitar bloques try/catch duplicados en el código +2. Asegurar que todo comportamiento inesperado se maneje correctamente dentro de la aplicación +3. Asegurar que los mensajes de error mostrados a los usuarios no filtren datos críticos, + pero que sean lo suficientemente detallados para permitir la respuesta adecuada del usuario +4. Asegurar que los registros de excepciones proporcionen información suficiente para los equipos de soporte, control de calidad, forense o respuesta a incidentes +5. Probar y verificar cuidadosamente el código de manejo de errores +6. No revelar información sensible en las respuestas de error, por ejemplo + detalles del sistema, identificadores de sesión o información de la cuenta +7. Utilizar manejadores de errores que no muestren información de depuración o de seguimiento de pila +8. Implementar mensajes de error genéricos y utilizar páginas de error personalizadas +9. La aplicación debe manejar los errores de la aplicación y no depender de la configuración del servidor +10. Liberar adecuadamente la memoria asignada cuando ocurran condiciones de error +11. La lógica de manejo de errores asociada con los controles de seguridad debe denegar el acceso por defecto + +#### Referencias + +* [Guía de Revisión de Código: Manejo de Errores][review] de OWASP +* [Manejo Inadecuado de Errores][handle] de OWASP +* [Top 10 Controles Proactivos][proactive10] de OWASP ---- +Traducción de versión [original en inglés][release060210]. -[release060210]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/10-handle-errors-exceptions.md +La Guía para Desarrolladores OWASP es un esfuerzo comunitario; si hay algo que necesita cambiarse, +[cree un issue][issue060210] o [edítelo en GitHub][edit060210]. -\newpage +[release060210]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/10-handle-errors-exceptions.md +[cserror]: https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet +[csproactive-c10]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c10-handle-all-errors-and-exceptions +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[edit060210]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/10-handle-errors-exceptions.md +[handle]: https://owasp.org/www-community/Improper_Error_Handling +[issue060210]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/10-handle-errors-exceptions +[proactive10]: https://top10proactive.owasp.org/ +[review]: https://owasp.org/www-project-code-review-guide/ + +\newpage \ No newline at end of file diff --git a/release-es/06-design/02-web-app-checklist/toc.md b/release-es/06-design/02-web-app-checklist/toc.md index 25055851..8a21346d 100644 --- a/release-es/06-design/02-web-app-checklist/toc.md +++ b/release-es/06-design/02-web-app-checklist/toc.md @@ -3,7 +3,7 @@ title: Lista de verificación de aplicaciones web layout: col-document tags: Guía del Desarrollador OWASP -contributors: +contributors: Roxana Calderon document: Guía del Desarrollador OWASP order: 46200 permalink: /release-es/diseño/lista_verificación_web/ @@ -22,25 +22,46 @@ permalink: /release-es/diseño/lista_verificación_web/ } -![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){: .image-right } +![Logo de la guía del desarrollador](../../../assets/images/dg_logo_bbd.png "Guía del Desarrollador OWASP"){: .image-right } -### 4.2 Lista de verificación de aplicaciones web +### 4.2 Lista de verificación para aplicaciones web -No hay traducción de esta página, consulte [versión original en inglés][release0602]. +Las listas de verificación son un recurso valioso para los equipos de desarrollo. +Proporcionan estructura para establecer buenas prácticas y procesos, +y también son útiles durante las revisiones de código y actividades de diseño. -Sections: +Las listas de verificación que siguen son listas generales categorizadas para seguir los controles enumerados en el +proyecto [Top 10 Controles Proactivos de OWASP][proactive10]. +Estas listas de verificación proporcionan sugerencias que ciertamente deben adaptarse a +los requisitos y el entorno específicos de un proyecto; no están destinadas a seguirse en su totalidad. -4.2.1 [Definir requisitos de seguridad](01-define-security-requirements.md) -4.2.2 [Aprovechar los frameworks y librerías](02-frameworks-libraries.md) -4.2.3 [Asegurar el acceso a la base de datos](03-secure-database-access.md) -4.2.4 [Codificar y escapar caracteres especiales en datos](04-encode-escape-data.md) -4.2.5 [Validar todas las entradas](05-validate-inputs.md) -4.2.6 [Implementar identidad digital](06-digital-identity.md) -4.2.7 [Hacer respetar los controles de acceso](07-access-controls.md) -4.2.8 [Proteger los datos en todas partes](08-protect-data.md) -4.2.9 [Implementar registro y monitoreo de seguridad](09-logging-monitoring.md) -4.2.10 [Manejar todos los errores y excepciones](10-handle-errors-exceptions.md) +Probablemente el mejor punto de partida para una lista de verificación es el proporcionado por el [Estándar de Verificación de Seguridad de Aplicaciones (ASVS)][asvs]. +El ASVS puede utilizarse para proporcionar un marco para una lista de verificación inicial, según el nivel de verificación de seguridad, +y esta lista de verificación inicial del ASVS puede ampliarse utilizando las siguientes secciones de la lista. + +Secciones: + +4.2.1 [Lista de verificación: Definir requisitos de seguridad](01-define-security-requirements.md) +4.2.2 [Lista de verificación: Aprovechar marcos y bibliotecas de seguridad](02-frameworks-libraries.md) +4.2.3 [Lista de verificación: Acceso seguro a la base de datos](03-secure-database-access.md) +4.2.4 [Lista de verificación: Codificar y escapar datos](04-encode-escape-data.md) +4.2.5 [Lista de verificación: Validar todas las entradas](05-validate-inputs.md) +4.2.6 [Lista de verificación: Implementar identidad digital](06-digital-identity.md) +4.2.7 [Lista de verificación: Aplicar controles de acceso](07-access-controls.md) +4.2.8 [Lista de verificación: Proteger datos en todas partes](08-protect-data.md) +4.2.9 [Lista de verificación: Implementar registro y monitoreo de seguridad](09-logging-monitoring.md) +4.2.10 [Lista de verificación: Manejar todos los errores y excepciones](10-handle-errors-exceptions.md) ---- +Traducción de versión [original en inglés][release0602]. + +La Guía para Desarrolladores de OWASP es un esfuerzo comunitario; si hay algo que necesita cambios, +[cree un issue][issue0602] o [edítelo en GitHub][edit0602]. [release0602]: https://github.com/OWASP/www-project-developer-guide/blob/main/release/06-design/02-web-app-checklist/toc.md +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit0602]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/toc.md +[issue0602]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/00-toc +[proactive10]: https://owasp.org/www-project-proactive-controls/ + +/newpage \ No newline at end of file diff --git a/release/06-design/02-web-app-checklist/01-define-security-requirements.md b/release/06-design/02-web-app-checklist/01-define-security-requirements.md index a7b3f545..0d7ec39f 100644 --- a/release/06-design/02-web-app-checklist/01-define-security-requirements.md +++ b/release/06-design/02-web-app-checklist/01-define-security-requirements.md @@ -24,43 +24,43 @@ and use the lists below as suggestions for a checklist that has been tailored fo #### 1. System configuration 1. Restrict applications, processes and service accounts to the least privileges possible -1. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -1. Remove all unnecessary functionality and files -1. Remove test code or any functionality not intended for production, prior to deployment -1. The security configuration store for the application should be available in human readable form to support auditing -1. Isolate development environments from production and provide access only to authorized development and test groups -1. Implement a software change control system to manage and record changes to the code both in development and production +2. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +3. Remove all unnecessary functionality and files +4. Remove test code or any functionality not intended for production, prior to deployment +5. The security configuration store for the application should be available in human readable form to support auditing +6. Isolate development environments from production and provide access only to authorized development and test groups +7. Implement a software change control system to manage and record changes to the code both in development and production #### 2. Cryptographic practices 1. Use peer reviewed and open solution cryptographic modules -1. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system -1. Cryptographic modules must fail securely -1. Ensure all random elements such as numbers, file names, UUID and strings are generated +2. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system +3. Cryptographic modules must fail securely +4. Ensure all random elements such as numbers, file names, UUID and strings are generated using the cryptographic module approved random number generator -1. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard -1. Establish and utilize a policy and process for how cryptographic keys will be managed -1. Ensure that any secret key is protected from unauthorized access -1. Store keys in a proper secrets vault as described below -1. Use independent keys when multiple keys are required -1. Build support for changing algorithms and keys when needed -1. Build application features to handle a key rotation +5. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard +6. Establish and utilize a policy and process for how cryptographic keys will be managed +7. Ensure that any secret key is protected from unauthorized access +8. Store keys in a proper secrets vault as described below +9. Use independent keys when multiple keys are required +10. Build support for changing algorithms and keys when needed +11. Build application features to handle a key rotation #### 3. File management 1. Do not pass user supplied data directly to any dynamic include function -1. Require authentication before allowing a file to be uploaded -1. Limit the type of files that can be uploaded to only those types that are needed for business purposes -1. Validate uploaded files are the expected type by checking file headers rather than by file extension -1. Do not save files in the same web context as the application -1. Prevent or restrict the uploading of any file that may be interpreted by the web server. -1. Turn off execution privileges on file upload directories -1. When referencing existing files, use an allow-list of allowed file names and types -1. Do not pass user supplied data into a dynamic redirect -1. Do not pass directory or file paths, use index values mapped to pre-defined list of paths -1. Never send the absolute file path to the client -1. Ensure application files and resources are read-only -1. Scan user uploaded files for viruses and malware +2. Require authentication before allowing a file to be uploaded +3. Limit the type of files that can be uploaded to only those types that are needed for business purposes +4. Validate uploaded files are the expected type by checking file headers rather than by file extension +5. Do not save files in the same web context as the application +6. Prevent or restrict the uploading of any file that may be interpreted by the web server. +7. Turn off execution privileges on file upload directories +8. When referencing existing files, use an allow-list of allowed file names and types +9. Do not pass user supplied data into a dynamic redirect +10. Do not pass directory or file paths, use index values mapped to pre-defined list of paths +11. Never send the absolute file path to the client +12. Ensure application files and resources are read-only +13. Scan user uploaded files for viruses and malware #### References From a52873d13c2a0fbca2705abeab1acef93abf8a85 Mon Sep 17 00:00:00 2001 From: roxana-calderon-owasp Date: Mon, 17 Mar 2025 23:58:37 -0400 Subject: [PATCH 4/4] fix for numbered points in lists --- .../02-frameworks-libraries.md | 24 ++--- .../03-secure-database-access.md | 26 ++--- .../04-encode-escape-data.md | 14 +-- .../06-digital-identity.md | 94 +++++++++---------- .../07-access-controls.md | 26 ++--- .../02-web-app-checklist/08-protect-data.md | 36 +++---- .../09-logging-monitoring.md | 30 +++--- .../10-handle-errors-exceptions.md | 20 ++-- 8 files changed, 135 insertions(+), 135 deletions(-) diff --git a/release/06-design/02-web-app-checklist/02-frameworks-libraries.md b/release/06-design/02-web-app-checklist/02-frameworks-libraries.md index 7f2cf31a..96af1b8b 100644 --- a/release/06-design/02-web-app-checklist/02-frameworks-libraries.md +++ b/release/06-design/02-web-app-checklist/02-frameworks-libraries.md @@ -52,18 +52,18 @@ In addition consider the following extra checks for frameworks and libraries. #### 1. Security Frameworks and Libraries 1. Ensure servers, frameworks and system components are running the latest approved versions and patches -1. Use libraries and frameworks from trusted sources that are actively maintained and widely used -1. Review all secondary applications and third party libraries to determine business necessity -1. Validate safe functionality for all secondary applications and third party libraries -1. Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA) -1. Proactively keep all third party libraries and components up to date -1. Reduce the attack surface by encapsulating the library and expose only the required behavior into your software -1. Use tested and approved managed code rather than creating new unmanaged code for common tasks -1. Utilize task specific built-in APIs to conduct operating system tasks -1. Do not allow the application to issue commands directly to the Operating System -1. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files -1. Restrict users from generating new code or altering existing code -1. Implement safe updates using encrypted channels +2. Use libraries and frameworks from trusted sources that are actively maintained and widely used +3. Review all secondary applications and third party libraries to determine business necessity +4. Validate safe functionality for all secondary applications and third party libraries +5. Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA) +6. Proactively keep all third party libraries and components up to date +7. Reduce the attack surface by encapsulating the library and expose only the required behavior into your software +8. Use tested and approved managed code rather than creating new unmanaged code for common tasks +9. Utilize task specific built-in APIs to conduct operating system tasks +10. Do not allow the application to issue commands directly to the Operating System +11. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files +12. Restrict users from generating new code or altering existing code +13. Implement safe updates using encrypted channels #### References diff --git a/release/06-design/02-web-app-checklist/03-secure-database-access.md b/release/06-design/02-web-app-checklist/03-secure-database-access.md index 8f1f0fef..f25c20d4 100644 --- a/release/06-design/02-web-app-checklist/03-secure-database-access.md +++ b/release/06-design/02-web-app-checklist/03-secure-database-access.md @@ -23,28 +23,28 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Secure queries 1. Use Query Parameterization to prevent untrusted input being interpreted as part of a SQL command -1. Use strongly typed parameterized queries -1. Utilize input validation and output encoding and be sure to address meta characters -1. Do not run the database command if input validation fails -1. Ensure that variables are strongly typed -1. Connection strings should not be hard coded within the application -1. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted +2. Use strongly typed parameterized queries +3. Utilize input validation and output encoding and be sure to address meta characters +4. Do not run the database command if input validation fails +5. Ensure that variables are strongly typed +6. Connection strings should not be hard coded within the application +7. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted #### 2. Secure configuration 1. The application should use the lowest possible level of privilege when accessing the database -1. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database -1. Close the database connection as soon as possible -1. Turn off all unnecessary database functionality -1. Remove unnecessary default vendor content, for example sample schemas -1. Disable any default accounts that are not required to support business requirements +2. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database +3. Close the database connection as soon as possible +4. Turn off all unnecessary database functionality +5. Remove unnecessary default vendor content, for example sample schemas +6. Disable any default accounts that are not required to support business requirements #### 3. Secure authentication 1. Remove or change all default database administrative passwords -1. The application should connect to the database with different credentials for every trust distinction +2. The application should connect to the database with different credentials for every trust distinction (for example user, read-only user, guest, administrators) -1. Use secure credentials for database access +3. Use secure credentials for database access #### References diff --git a/release/06-design/02-web-app-checklist/04-encode-escape-data.md b/release/06-design/02-web-app-checklist/04-encode-escape-data.md index 5ef4da8a..710aa5dc 100644 --- a/release/06-design/02-web-app-checklist/04-encode-escape-data.md +++ b/release/06-design/02-web-app-checklist/04-encode-escape-data.md @@ -28,12 +28,12 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Character encoding and canonicalization 1. Apply output encoding just before the content is passed to the target system -1. Conduct all output encoding on a trusted system -1. Utilize a standard, tested routine for each type of outbound encoding -1. Specify character sets, such as UTF-8, for all outputs -1. Apply canonicalization to convert unicode data into a standard form -1. Ensure the output encoding is safe for all target systems -1. In particular sanitize all output used for operating system commands +2. Conduct all output encoding on a trusted system +3. Utilize a standard, tested routine for each type of outbound encoding +4. Specify character sets, such as UTF-8, for all outputs +5. Apply canonicalization to convert unicode data into a standard form +6. Ensure the output encoding is safe for all target systems +7. In particular sanitize all output used for operating system commands #### 2. Contextual output encoding @@ -41,7 +41,7 @@ Contextual output encoding of data is based on how it will be utilized by the ta The specific methods vary depending on the way the output data is used, such as HTML entity encoding. 1. Contextually encode all data returned to the client from untrusted sources -1. Contextually encode all output of untrusted data to queries for SQL, XML, and LDAP +2. Contextually encode all output of untrusted data to queries for SQL, XML, and LDAP #### References diff --git a/release/06-design/02-web-app-checklist/06-digital-identity.md b/release/06-design/02-web-app-checklist/06-digital-identity.md index 88fab3fa..53a1c376 100644 --- a/release/06-design/02-web-app-checklist/06-digital-identity.md +++ b/release/06-design/02-web-app-checklist/06-digital-identity.md @@ -25,68 +25,68 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Authentication 1. Design access control authentication thoroughly up-front -1. Force all requests to go through access control checks unless public -1. Do not hard code access controls that are role based -1. Log all access control events -1. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts +2. Force all requests to go through access control checks unless public +3. Do not hard code access controls that are role based +4. Log all access control events +5. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts #### 2. Passwords 1. Require authentication for all pages and resources, except those specifically intended to be public -1. All authentication controls must be enforced on a trusted system -1. Establish and utilize standard, tested, authentication services whenever possible -1. Use a centralized implementation for all authentication controls -1. Segregate authentication logic from the resource being requested and +2. All authentication controls must be enforced on a trusted system +3. Establish and utilize standard, tested, authentication services whenever possible +4. Use a centralized implementation for all authentication controls +5. Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control -1. All authentication controls should fail securely -1. Administrative and account management must be at least as secure as the primary authentication mechanism -1. If your application manages a credential store, use cryptographically strong one-way salted hashes -1. Password hashing must be implemented on a trusted system -1. Validate the authentication data only on completion of all data input -1. Authentication failure responses should not indicate which part of the authentication data was incorrect -1. Utilize authentication for connections to external systems that involve sensitive information or functions -1. Authentication credentials for accessing services external to the application should be stored in a secure store -1. Use only HTTP POST requests to transmit authentication credentials -1. Only send non-temporary passwords over an encrypted connection or as encrypted data -1. Enforce password complexity and length requirements established by policy or regulation -1. Enforce account disabling after an established number of invalid login attempts -1. Password reset and changing operations require the same level of controls as account creation and authentication -1. Password reset questions are deprecated, see [Choosing and Using Security Questions Cheat Sheet][csquestions] as to why -1. If using email based resets, only send email to a pre-registered address with a temporary link/password -1. Temporary passwords and links should have a short expiration time -1. Enforce the changing of temporary passwords on the next use -1. Notify users when a password reset occurs -1. Prevent password re-use -1. The last use (successful or unsuccessful) of a user account should be reported to the user +6. All authentication controls should fail securely +7. Administrative and account management must be at least as secure as the primary authentication mechanism +8. If your application manages a credential store, use cryptographically strong one-way salted hashes +9. Password hashing must be implemented on a trusted system +10. Validate the authentication data only on completion of all data input +11. Authentication failure responses should not indicate which part of the authentication data was incorrect +12. Utilize authentication for connections to external systems that involve sensitive information or functions +13. Authentication credentials for accessing services external to the application should be stored in a secure store +14. Use only HTTP POST requests to transmit authentication credentials +15. Only send non-temporary passwords over an encrypted connection or as encrypted data +16. Enforce password complexity and length requirements established by policy or regulation +17. Enforce account disabling after an established number of invalid login attempts +18. Password reset and changing operations require the same level of controls as account creation and authentication +19. Password reset questions are deprecated, see [Choosing and Using Security Questions Cheat Sheet][csquestions] as to why +20. If using email based resets, only send email to a pre-registered address with a temporary link/password +21. Temporary passwords and links should have a short expiration time +22. Enforce the changing of temporary passwords on the next use +23. Notify users when a password reset occurs +24. Prevent password re-use +25. The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login -1. Change all vendor-supplied default passwords and user IDs or disable the associated accounts -1. Re-authenticate users prior to performing critical operations -1. If using third party code for authentication inspect the code carefully +26. Change all vendor-supplied default passwords and user IDs or disable the associated accounts +27. Re-authenticate users prior to performing critical operations +28. If using third party code for authentication inspect the code carefully to ensure it is not affected by any malicious code #### 3. Cryptographic based authentication 1. Use the server or framework's session management controls -1. Session identifier creation must always be done on a trusted system -1. Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers -1. Set the domain and path for cookies containing authenticated session identifiers +2. Session identifier creation must always be done on a trusted system +3. Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers +4. Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site -1. Logout functionality should fully terminate the associated session or connection -1. Logout functionality should be available from all pages protected by authorization -1. Establish a session inactivity timeout that is as short as possible, +5. Logout functionality should fully terminate the associated session or connection +6. Logout functionality should be available from all pages protected by authorization +7. Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements -1. Disallow persistent logins and enforce periodic session terminations, even when the session is active -1. If a session was established before login, close that session and establish a new session after a successful login -1. Generate a new session identifier on any re-authentication -1. Do not allow concurrent logins with the same user ID -1. Do not expose session identifiers in URLs, error messages or logs -1. Implement appropriate access controls to protect server side session data +8. Disallow persistent logins and enforce periodic session terminations, even when the session is active +9. If a session was established before login, close that session and establish a new session after a successful login +10. Generate a new session identifier on any re-authentication +11. Do not allow concurrent logins with the same user ID +12. Do not expose session identifiers in URLs, error messages or logs +13. Implement appropriate access controls to protect server side session data from unauthorized access from other users of the server -1. Generate a new session identifier and deactivate the old one periodically -1. Generate a new session identifier if the connection security changes from HTTP to HTTPS, +14. Generate a new session identifier and deactivate the old one periodically +15. Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication -1. Set the `secure` attribute for cookies transmitted over an [TLS][tls] connection -1. Set cookies with the `HttpOnly` attribute, +16. Set the `secure` attribute for cookies transmitted over an [TLS][tls] connection +17. Set cookies with the `HttpOnly` attribute, unless you specifically require client-side scripts within your application to read or set a cookie value #### References diff --git a/release/06-design/02-web-app-checklist/07-access-controls.md b/release/06-design/02-web-app-checklist/07-access-controls.md index c858946e..5d9dda5a 100644 --- a/release/06-design/02-web-app-checklist/07-access-controls.md +++ b/release/06-design/02-web-app-checklist/07-access-controls.md @@ -24,24 +24,24 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Authorization 1. Design access control / authorization thoroughly up-front -1. Force all requests to go through access control checks unless public -1. Deny by default; if a request is not specifically allowed then it is denied -1. Apply least privilege, providing the least access as is necessary -1. Log all authorization events +2. Force all requests to go through access control checks unless public +3. Deny by default; if a request is not specifically allowed then it is denied +4. Apply least privilege, providing the least access as is necessary +5. Log all authorization events #### 2. Access control 1. Enforce authorization controls on every request -1. Use only trusted system objects for making access authorization decisions -1. Use a single site-wide component to check access authorization -1. Access controls should fail securely -1. Deny all access if the application cannot access its security configuration information -1. Segregate privileged logic from other application code -1. Limit the number of transactions a single user or device can perform in a given period of time, +2. Use only trusted system objects for making access authorization decisions +3. Use a single site-wide component to check access authorization +4. Access controls should fail securely +5. Deny all access if the application cannot access its security configuration information +6. Segregate privileged logic from other application code +7. Limit the number of transactions a single user or device can perform in a given period of time, low enough to deter automated attacks but above the actual business requirement -1. If long authenticated sessions are allowed, periodically re-validate a user's authorization -1. Implement account auditing and enforce the disabling of unused accounts -1. The application must support termination of sessions when authorization ceases +8. If long authenticated sessions are allowed, periodically re-validate a user's authorization +9. Implement account auditing and enforce the disabling of unused accounts +10. The application must support termination of sessions when authorization ceases #### References diff --git a/release/06-design/02-web-app-checklist/08-protect-data.md b/release/06-design/02-web-app-checklist/08-protect-data.md index 71714942..3da2c41a 100644 --- a/release/06-design/02-web-app-checklist/08-protect-data.md +++ b/release/06-design/02-web-app-checklist/08-protect-data.md @@ -25,28 +25,28 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Data protection 1. Classify data according to the level of sensitivity -1. Implement appropriate access controls for sensitive data -1. Encrypt data in transit -1. Ensure secure communication channels are properly configured -1. Avoid storing sensitive data when at all possible -1. Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification -1. Purge sensitive data when that data is no longer required -1. Store application-level secrets in a secrets vault -1. Check that secrets are not stored in code, config files or environment variables -1. Implement least privilege, restricting access to functionality, data and system information -1. Protect all cached or temporary copies of sensitive data from unauthorized access -1. Purge those temporary copies of sensitive data as soon as they are no longer required +2. Implement appropriate access controls for sensitive data +3. Encrypt data in transit +4. Ensure secure communication channels are properly configured +5. Avoid storing sensitive data when at all possible +6. Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification +7. Purge sensitive data when that data is no longer required +8. Store application-level secrets in a secrets vault +9. Check that secrets are not stored in code, config files or environment variables +10. Implement least privilege, restricting access to functionality, data and system information +11. Protect all cached or temporary copies of sensitive data from unauthorized access +12. Purge those temporary copies of sensitive data as soon as they are no longer required #### 2. Memory management 1. Explicitly initialize all variables and data stores -1. Check that any buffers are as large as specified -1. Check buffer boundaries if calling the function in a loop and protect against overflow -1. Specifically close resources, don't rely on garbage collection -1. Use non-executable stacks when available -1. Properly free allocated memory upon the completion of functions and at all exit points -1. Overwrite any sensitive information stored in allocated memory at all exit points from the function -1. Protect shared variables and resources from inappropriate concurrent access +2. Check that any buffers are as large as specified +3. Check buffer boundaries if calling the function in a loop and protect against overflow +4. Specifically close resources, don't rely on garbage collection +5. Use non-executable stacks when available +6. Properly free allocated memory upon the completion of functions and at all exit points +7. Overwrite any sensitive information stored in allocated memory at all exit points from the function +8. Protect shared variables and resources from inappropriate concurrent access #### References diff --git a/release/06-design/02-web-app-checklist/09-logging-monitoring.md b/release/06-design/02-web-app-checklist/09-logging-monitoring.md index 6e20f7e5..1fd85ee3 100644 --- a/release/06-design/02-web-app-checklist/09-logging-monitoring.md +++ b/release/06-design/02-web-app-checklist/09-logging-monitoring.md @@ -24,25 +24,25 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Security logging 1. Log submitted data that is outside of an expected numeric range. -1. Log submitted data that involves changes to data that should not be modifiable -1. Log requests that violate server-side access control rules -1. Encode and validate any dangerous characters before logging to prevent log injection attacks -1. Do not log sensitive information -1. Logging controls should support both success and failure of specified security events -1. Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords -1. Use a cryptographic hash function to validate log entry integrity +2. Log submitted data that involves changes to data that should not be modifiable +3. Log requests that violate server-side access control rules +4. Encode and validate any dangerous characters before logging to prevent log injection attacks +5. Do not log sensitive information +6. Logging controls should support both success and failure of specified security events +7. Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords +8. Use a cryptographic hash function to validate log entry integrity #### 2. Security logging design 1. Protect log integrity -1. Ensure log entries that include untrusted data will not execute as code in the intended log viewing interface or software -1. Restrict access to logs to only authorized individuals -1. Utilize a central routine for all logging operations -1. Forward logs from distributed systems to a central, secure logging service -1. Follow a common logging format and approach within the system and across systems of an organization -1. Synchronize across nodes to ensure that timestamps are consistent -1. All logging controls should be implemented on a trusted system -1. Ensure that a mechanism exists to conduct log analysis +2. Ensure log entries that include untrusted data will not execute as code in the intended log viewing interface or software +3. Restrict access to logs to only authorized individuals +4. Utilize a central routine for all logging operations +5. Forward logs from distributed systems to a central, secure logging service +6. Follow a common logging format and approach within the system and across systems of an organization +7. Synchronize across nodes to ensure that timestamps are consistent +8. All logging controls should be implemented on a trusted system +9. Ensure that a mechanism exists to conduct log analysis #### References diff --git a/release/06-design/02-web-app-checklist/10-handle-errors-exceptions.md b/release/06-design/02-web-app-checklist/10-handle-errors-exceptions.md index 196adcec..46a789e4 100644 --- a/release/06-design/02-web-app-checklist/10-handle-errors-exceptions.md +++ b/release/06-design/02-web-app-checklist/10-handle-errors-exceptions.md @@ -25,18 +25,18 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Errors and exceptions 1. Manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code -1. Ensure that all unexpected behavior is correctly handled inside the application -1. Ensure that error messages displayed to users do not leak critical data, +2. Ensure that all unexpected behavior is correctly handled inside the application +3. Ensure that error messages displayed to users do not leak critical data, but are still verbose enough to enable the proper user response -1. Ensure that exceptions logs give enough information for support, QA, forensics or incident response teams -1. Carefully test and verify error handling code -1. Do not disclose sensitive information in error responses, for example +4. Ensure that exceptions logs give enough information for support, QA, forensics or incident response teams +5. Carefully test and verify error handling code +6. Do not disclose sensitive information in error responses, for example system details, session identifiers or account information -1. Use error handlers that do not display debugging or stack trace information -1. Implement generic error messages and use custom error pages -1. The application should handle application errors and not rely on the server configuration -1. Properly free allocated memory when error conditions occur -1. Error handling logic associated with security controls should deny access by default +7. Use error handlers that do not display debugging or stack trace information +8. Implement generic error messages and use custom error pages +9. The application should handle application errors and not rely on the server configuration +10. Properly free allocated memory when error conditions occur +11. Error handling logic associated with security controls should deny access by default #### References