PARCIAL 2 Flashcards
Distintas técnicas para distintos momentos del SDLC:
- Modelado de amenazas.
- Inspecciones y revisiones manuales.
- Revisión de código.
- Pruebas de penetración.
Cuando nos referimos al riesgo de “Diseño inseguro”, podemos afirmar que:
-La gestión de los requerimientos no es parte del diseño inseguro.
-Es posible identificar fallas de diseño analizando el código fuente de la aplicación.
-El diseño inseguro es la fuente de las otras 10 categorías.
-Establecer un ciclo de desarrollo seguro es una forma de mitigar el diseño inseguro.
Establecer un ciclo de desarrollo seguro es una forma de mitigar el diseño inseguro.
Cuando nos referimos al riesgo “Pérdida de Control de Acceso”, podemos afirmar que:
Se da cuando debido a una falla, no se cumple la política de acceso a los activos.
Un ejemplo de pérdida de control de acceso es eludir un control de acceso modificando un parámetro en la URL.
Un ejemplo es una inyección de SQL.
Un ejemplo es el uso de un componente obsoleto.
Se da cuando debido a una falla, no se cumple la política de acceso a los activos.
Un ejemplo de pérdida de control de acceso es eludir un control de acceso modificando un parámetro en la URL.
El OWASP Top 10 se basa exclusivamente en datos estadísticos recopilados de análisis realizados desde 2017. (v, f)
Falso
Cuando nos referimos a “Falsificación de Solicitudes del Lado del Servidor (SSRF)”, es correcto afirmar que;
-Las fallas de SSRF incluyen los pedidos originados en los navegadores de los clientes (Client Side).
-La implementación de reglas de firewall para el tráfico de salida de los servidores hacia Internet contribuye a la mitigación de estas fallas, aunque no las elimina por completo.
-Las fallas de SSRF ocurren cuando una aplicación web está obteniendo un recurso remoto sin validar la URL proporcionada por el usuario.
-Esta categoría es agregada al OWASP Top 10 como resultado de los datos estadísticos y no debido a la encuesta a la comunidad.
Las fallas de SSRF ocurren cuando una aplicación web está obteniendo un recurso remoto sin validar la URL proporcionada por el usuario.
La implementación de reglas de firewall para el tráfico de salida de los servidores hacia Internet contribuye a la mitigación de estas fallas, aunque no las elimina por completo.
Cuando nos referimos a las “Fallas de registro y monitoreo”, es correcto afirmar que:
Se deben generar eventos auditables en cada inicio de sesión (sea exitoso o no).
Las transacciones de alto valor deben de generar registros de logs.
Se debe establecer un mecanismo de generación de alertas ante actividad sospechosas.
Los registros almacenados únicamente de forma local es un tipo de falla de registro y monitoreo.
Se deben generar eventos auditables en cada inicio de sesión (sea exitoso o no).,
Las transacciones de alto valor deben de generar registros de logs.,
Los registros almacenados únicamente de forma local es un tipo de falla de registro y monitoreo.
Se debe establecer un mecanismo de generación de alertas ante actividad sospechosas.,
Cuando nos referimos a las “Inyecciones”, podemos afirmar que:
Utilizando tecnologías de acceso a base de datos como ORM, no es posible que ocurran inyecciones.
Los Cross Site Scripting son partes de las inyecciones.
Un ejemplo es una inyección SQL.
Se producen cuando los datos ingresados no son validados ni sanitizados antes de ser procesados por un intérprete.
Se producen cuando los datos ingresados no son validados ni sanitizados antes de ser procesados por un intérprete.,
Un ejemplo es una inyección SQL.,
Los Cross Site Scripting son partes de las inyecciones.
Cuando nos referimos al riesgo de “Componentes vulnerables y desactualizados”, es correcto afirmar que:
Si una biblioteca alcanzó el fin de su vida útil (end of life) y no posee soporte, no es una debilidad.
Si no se utiliza la última versión liberada de todas las bibliotecas, se está ante una vulnerabilidad.
Para mitigar este riesgo, es necesario identificar las versiones de todo el software de base que permite la ejecución del sistema.
Para mitigar este riesgo, es necesario conocer las versiones de todos los componentes de terceros que integran el sistema.
Para mitigar este riesgo, es necesario conocer las versiones de todos los componentes de terceros que integran el sistema.,
Para mitigar este riesgo, es necesario identificar las versiones de todo el software de base que permite la ejecución del sistema.
Cuando nos referimos a “Fallas de identificación y autenticación”, es correcto afirmar que:
Ocurren cuando no se puede verificar la identidad del tercero que está utilizando el sistema.
El uso de una misma contraseña en múltiples aplicaciones no relacionadas entre sí no constituye un riesgo significativo.
Los problemas asociados con la gestión de sesiones están incluidos en este punto.
Como medida de mitigación, se recomienda implementar un mecanismo de gestión de sesiones propio, en lugar de utilizar el proporcionado por el lenguaje, servidor o plataforma.
Ocurren cuando no se puede verificar la identidad del tercero que está utilizando el sistema.,
Los problemas asociados con la gestión de sesiones están incluidos en este punto.
Sobre los datos que se utilizaron para confeccionar el OWASP Top 10: cualquier organización que desee contribuir puede hacerlo.
(V, F)
Verdadero
Cuando nos referimos a las “Fallas criptográficas”, podemos afirmar que:
Un ejemplo es una inyección SQL.
Sucede cuando se almacenan contraseñas en texto plano en una base de datos.
Se utilizan algoritmos criptográficos antiguos, considerados actualmente débiles es una falla criptográfica.
Se da cuando se utilizan correctamente los mecanismos criptográficos para proteger los datos tanto en tránsito como en reposo.
Se utilizan algoritmos criptográficos antiguos, considerados actualmente débiles es una falla criptográfica.,
Sucede cuando se almacenan contraseñas en texto plano en una base de datos.
OWASP Top 10 como estándar:
A pesar de que su objetivo no es ser un estándar, la industria lo utiliza como tal.
Es un documento de concientización, no un estándar.
Es preferible utilizar otros estándares de verificación de seguridad, como el Estándar de Verificación de Seguridad en Aplicaciones de OWASP (ASVS)..
Es un documento de concientización, no un estándar.,
A pesar de que su objetivo no es ser un estándar, la industria lo utiliza como tal.,
Es preferible utilizar otros estándares de verificación de seguridad, como el Estándar de Verificación de Seguridad en Aplicaciones de OWASP (ASVS)..
Cuando nos referimos al riesgo de “Configuración de Seguridad Incorrecta”, podemos afirmar que:
Para mitigar las configuraciones de seguridad incorrectas, es esencial implementar un proceso de configuración detallado y repetible.
Que se encuentren habilitados los pares de usuarios y contraseñas que se indican en el manual de usuario de a aplicación no es un problema configuración de seguridad incorrecta.
Exponer funciones innecesarias y habilitadas no es un problema de configuración de seguridad incorrecta, ya que es parte del diseño original del software.
Una configuración de seguridad incorrecta puede manifestarse a través de la exposición de rastros de pila (stack traces) u otros mensajes de error que revelen excesiva información.
Una configuración de seguridad incorrecta puede manifestarse a través de la exposición de rastros de pila (stack traces) u otros mensajes de error que revelen excesiva información.,
Para mitigar las configuraciones de seguridad incorrectas, es esencial implementar un proceso de configuración detallado y repetible.
Cuando nos referimos a las “Fallas del software y en la integridad de los datos”, es correcto afirmar que:
El origen de paquetes de terceros no es relevante si son descargados utilizando un gestor de paquetes como NPM o Maven.
Firmar digitalmente el software permite verificar que proviene de un lugar confiable y que no ha sido modificado.
Incluye los accesos indebidos a los procesos de Integración Continua y Despliegue Continuo (CI/CD).
La deserialización insegura no es parte de este punto, sino que es una inyección.
Firmar digitalmente el software permite verificar que proviene de un lugar confiable y que no ha sido modificado.,
Incluye los accesos indebidos a los procesos de Integración Continua y Despliegue Continuo (CI/CD).
Con respecto a la relación entre OWASP Top 10 2021 y los CWE (Common Weakness Enumeration).
Los CWE más comunes se agrupan en los distintos puntos del OWASP Top 10 (lista de los 30 más comunes).
No existe relación alguna.
Los CWE se agrupan en los distintos puntos del OWASP Top 10. Aquellos más prevalentes son los que forman parte del top 10.
Los CWE se agrupan en los distintos puntos del OWASP Top 10. Aquellos más prevalentes son los que forman parte del top 10.
