BIGD3 UNIRFIRMES

Para evitar “security misconfiguration”, conviene…. Endurecer por entorno y deshabilitar funciones no utilizadas. Mantener valores por defecto del servidor en producción. Controlar exposición de métodos HTTP y de paneles administrativos. Permitir listados de directorio para facilitar soporte de usuarios.

Buenas prácticas frente a “logging and monitoring failures” son…. Definir eventos relevantes y alertas que faciliten respuesta. Limitar registros a errores críticos para ahorrar espacio. Asegurar integridad y retención adecuada de logs. Evitar correlación para no generar falsos positivos.

Para reducir “software and data integrity failures”…. Firmar artefactos y verificar integridad en el pipeline. Descargar dependencias sin verificar su procedencia. Restringir deserialización y validar fuentes de actualización. Ejecutar scripts de build con privilegios globales innecesarios.

¿Qué áreas cubre la arquitectura de seguridad de aplicaciones web mencionada en las ideas clave?. Solo configuración de DNS, CDN y caché del navegador. Servidores y BDD, aplicación (autenticación, sesiones, autorización), comunicaciones y seguridad física. Únicamente rendimiento del frontend y balanceo de carga. Exclusivamente controles de escritorio del usuario final.

¿Qué objetivo persigue el “diseño seguro” en una aplicación web?. Incorporar controles de seguridad desde el diseño y requisitos. Trasladar todos los controles a la red perimetral. Sustituir autenticación por identificación basada en IP. Eliminar trazabilidad para mejorar tiempos de respuesta.

¿Qué enfoque recomiendan los proyectos de OWASP citados para el diseño?. Validación solo de formularios del perfil de usuario. Estándares de verificación, guías de codificación y cheatsheets aplicables. Cifrado únicamente de recursos estáticos públicos. Uso de métricas UX para decidir políticas de acceso.

¿Qué función cumple un estándar como OWASP ASVS en el ciclo de vida?. Generar automáticamente código seguro desde modelos UML. Servir como lista de verificación de requisitos y controles de seguridad. Reemplazar completamente las pruebas funcionales de la aplicación. Actuar como proxy inverso para filtrar tráfico en producción.

¿Qué aspecto es central en la autenticación según el diseño seguro?. Autogenerar contraseñas en el cliente y almacenarlas en local. Apoyarse en mecanismos del framework y proteger credenciales y flujos. Usar parámetros GET para acelerar validación del servidor. Permitir sesiones sin expiración para mejorar experiencia.

¿Qué principio guía la gestión de sesiones en la arquitectura de seguridad?. Desactivar expiración para evitar cierres de sesión involuntarios. Identificadores robustos, expiración adecuada y protección contra fijación. Reutilizar el mismo identificador en todos los dispositivos. Almacenar tokens en parámetros de la URL para trazabilidad.

¿Qué rol tiene la autorización en la capa de aplicación?. Delegar decisiones de acceso a scripts en el navegador. Restringir acciones y datos según roles y políticas declaradas. Validar solo la sintaxis de formularios antes de persistir. Mapear uno a uno cada usuario con privilegios de administrador.

¿Qué objetivo cubre la “seguridad de las comunicaciones entre servidores”?. Permitir tráfico en texto claro para facilitar depuración. Proteger integridad y confidencialidad en tránsitos entre componentes. Deshabilitar controles de certificados para reducir latencia. Evitar balanceo de carga y redundancia de servicios.

¿Qué elemento de “seguridad física” es relevante para la aplicación?. Protección de instalaciones, personal y documentación asociada. Deshabilitar copias de seguridad para reducir superficie. Exigir que los usuarios firmen cada petición HTTP. Permitir acceso libre a racks para tiempos de respuesta óptimos.

¿Qué aportan las “Secure Coding Practices” y “Cheat Sheet Series”?. Herramientas para reemplazar auditorías de seguridad. Guías prácticas para implementar controles concretos y evitar fallos comunes. Plantillas de interfaz para unificar estilos visuales. Mecanismos de caché para mejorar disponibilidad.

¿Qué utilidad tiene “ESAPI” en el contexto de OWASP?. Proporcionar librerías de apoyo a controles de seguridad en aplicaciones. Ofrecer servicios de CDN para contenido estático. Generar automáticamente certificados de servidor firmados. Indexar APIs públicas para descubrimiento de endpoints.

¿Qué papel juega el “Testing Guide” de OWASP?. Definir patrones de UI para accesibilidad. Orientar pruebas de seguridad sistemáticas a lo largo del SSDLC. Sustituir la revisión de código por validadores automáticos. Eliminar la necesidad de requisitos de seguridad.

¿Qué decisión de diseño favorece la autorización robusta?. Compartir cuentas entre servicios para simplificar. Separar funciones por capas y aplicar políticas por recurso y acción. Permitir que el cliente decida permisos para acelerar respuesta. Eliminar controles para roles de lectura por ser no críticos.

¿Qué control de sesión reduce la fijación de sesión?. Regenerar el identificador tras autenticación y cambios de privilegio. Incluir el identificador en la URL para facilitar marcadores. Mantener el mismo identificador en todo el ciclo de vida. Forzar que el identificador sea predecible para auditoría.

¿Qué elección mejora la seguridad en comunicaciones de backend?. Migrar a texto claro en redes internas por simplicidad. Uso de canales cifrados con verificación de certificados entre servicios. Desactivar verificación para permitir autoservicio de endpoints. Encadenar servicios mediante redireccionamientos sin control.

¿Qué beneficio aporta incorporar “Proactive Controls” desde el inicio?. Omitir monitoreo y auditoría en la fase de operación. Prevenir fallos comunes con prácticas prioritarias aplicadas temprano. Reemplazar la autenticación por firma de logs. Evitar pruebas de penetración por considerarlas redundantes.

¿Qué decisión apoya la trazabilidad en la arquitectura?. Definir eventos, retención e integridad de logs desde el diseño. Guardar solo errores críticos sin contexto temporal. Descartar identificadores de usuario en registros por privacidad. Centralizar logs únicamente en equipos de desarrollo.

¿Qué relación hay entre diseño seguro y “insecure design”?. El primero evita cifrado para reducir complejidad; el segundo lo impone. El primero incorpora controles desde requisitos; el segundo carece de ellos. El primero usa autenticación local; el segundo, federada. El primero elimina roles; el segundo los multiplica.

¿Qué relación hay entre diseño seguro y “insecure design”?. Usar cuentas compartidas para tareas de mantenimiento. Endurecer configuraciones y limitar exposición de servicios. Deshabilitar auditorías para reducir almacenamiento. Exponer paneles administrativos a Internet para soporte.

¿Qué práctica se alinea con el diseño seguro de autorización?. Confiar en el ocultamiento de botones en la interfaz. Verificar permisos en servidor para cada acción sensible. Reutilizar decisiones de acceso entre usuarios por caché. Conceder permisos amplios por defecto para evitar bloqueos.

La arquitectura de seguridad mencionada incluye servidores, aplicación, comunicaciones y seguridad física. Verdadero. Falso.

El diseño seguro propone incorporar controles desde requisitos y no solo en implementación. Verdadero. Falso.

ASVS es una guía de pruebas automatizadas de rendimiento de frontends. Verdadero. Falso.

Las Secure Coding Practices y las Cheat Sheets ayudan a implementar controles concretos. Verdadero. Falso.

ESAPI es una librería que apoya la implementación de controles de seguridad. Verdadero. Falso.

El Testing Guide de OWASP elimina la necesidad de pruebas a lo largo del SSDLC. Verdadero. Falso.

La autorización robusta se implementa en servidor verificando permisos por acción y recurso. Verdadero. Falso.

Regenerar el identificador tras autenticación ayuda a prevenir fijación de sesión. Verdadero. Falso.

La seguridad de comunicaciones entre servidores busca confidencialidad e integridad del tránsito. Verdadero. Falso.

Endurecer configuraciones de servidores y BDD es irrelevante si el frontend ya valida entradas. Verdadero. Falso.

Proyectos OWASP útiles para diseño seguro incluyen…. ASVS para verificación de controles. Guías de UI para estilos responsive. Secure Coding Practices y Cheat Sheet Series. Herramientas de CDN para distribución de contenido.

En autenticación y sesiones, buenas prácticas son…. Usar mecanismos del framework y proteger flujos y credenciales. Exigir credenciales por GET para facilitar auditoría. Regenerar identificadores y establecer expiración adecuada. Almacenar tokens en URL para permitir marcadores.

En autorización dentro de la aplicación conviene…. Verificar permisos por recurso y acción en servidor. Delegar autorización al navegador para reducir carga. Separar responsabilidades por capas y roles. Compartir cuentas de servicio entre múltiples sistemas.

Para comunicaciones seguras entre servidores se recomienda…. Cifrar canales y verificar certificados entre componentes. Usar texto claro en redes internas por confianza implícita. Limitar exposición de endpoints y paneles administrativos. Deshabilitar registro de eventos de transporte.

Para soportar trazabilidad y respuesta a incidentes es clave…. Definir eventos relevantes, integridad y retención de logs. Registrar únicamente métricas de rendimiento sin contexto. Centralizar y monitorear alertas útiles para operación. Omitir registros en producción para mejorar latencia.

¿Qué propósito cumple el identificador de sesión en una aplicación web?. Permitir que el navegador almacene hojas de estilo en caché. Asociar las peticiones del usuario con su estado autenticado. Sustituir la autenticación por validaciones de formulario. Generar automáticamente roles según la IP de origen.

¿Qué práctica fortalece la resistencia frente a fijación de sesión?. Mantener el mismo token desde antes y después del inicio de sesión. Regenerar el identificador de sesión al autenticarse y al elevar privilegios. Incluir el token de sesión en la URL para facilitar marcadores. Compartir el token entre pestañas por simplicidad de usuario.

¿Qué característica debe tener un identificador de sesión robusto?. Aleatoriedad suficiente y entropía adecuada para evitar predicción. Longitud corta y formato legible por operadores humanos. Codificación en Base64 del nombre de usuario para trazabilidad. Inclusión del horario local para sincronización del cliente.

¿Qué control ayuda a mitigar secuestro de sesión por XSS?. Deshabilitar por completo las cookies de la aplicación. Marcar cookies como HttpOnly y sanear salidas en vistas. Usar GET para enviar credenciales con cifrado del lado cliente. Permitir iframes anidados para compatibilidad amplia.

¿Qué medida reduce el riesgo de repetición de solicitudes con sesión válida?. Enviar credenciales en cada parámetro de consulta. Confiar en el encabezado Referer como verificación principal. Usar tokens antifalsificación y verificación de origen en peticiones sensibles. Permitir reintentos ilimitados de formularios sin controles adicionales.

¿Qué política de expiración de sesión es recomendable?. Mantener sesiones indefinidas en clientes confiables. Establecer tiempo de inactividad y vida máxima razonables. Renovar la sesión solo cuando el usuario cierre el navegador. Vencer la sesión únicamente si cambia la dirección IP.

¿Qué decisión incrementa la confidencialidad de la cookie de sesión?. Almacenar el token en almacenamiento local para control granular. Asegurar la cookie con atributo Secure y transporte cifrado. Permitir acceso a la cookie desde scripts para telemetría. Cambiar el nombre de la cookie en cada pantalla de la aplicación.

¿Qué validación debe hacer la autorización antes de conceder una acción?. Verificar que el usuario haya visto la página anterior. Confirmar que el cliente use el navegador corporativo. Comprobar que el rol del usuario permita la operación sobre el recurso. Aceptar la acción si la petición proviene de la red interna.

¿Qué enfoque evita confiar en el cliente para decisiones de autorización?. Ocultar botones en la interfaz sin verificar en el servidor. Evaluar permisos en el servidor para cada operación sensible. Delegar reglas de acceso a un script de ruteo del navegador. Embutir el rol dentro del HTML para simplificar validaciones.

¿Qué metadato no debe incluirse dentro del token de sesión?. Un identificador opaco que referencie el estado en servidor. La contraseña del usuario cifrada con una clave fija. Una marca temporal de emisión para control de caducidad. Un identificador único para correlación de eventos.

¿Qué ayuda a limitar el uso indebido de una sesión robada?. Eliminar cualquier registro de auditoría de inicios de sesión. Detectar anomalías y cerrar sesión ante actividad inusual. Permitir múltiples inicios desde ubicaciones simultáneas sin alerta. Aceptar tokens reutilizados tras varios días de inactividad.

¿Qué es fundamental al invalidar sesión en cierre de sesión?. Dejar el token en el cliente para acelerar futuros accesos. Borrar el estado de servidor y expirar la cookie de sesión. Reutilizar el token si el usuario vuelve en menos de una hora. Mantener la sesión con permisos de solo lectura indefinida.

¿Qué relación existe entre autenticación, sesión y autorización?. Autorización ocurre antes de crear cualquier sesión. Autenticación emite sesión; autorización decide qué puede hacer el usuario. Sesión reemplaza la autenticación y elimina la autorización. Autorización crea tokens que el usuario convierte en contraseña.

¿Qué lista consulta la aplicación para decidir acceso a recursos?. Tabla de rutas públicas del navegador. Historial del usuario en el dispositivo. Lista de control de acceso con reglas por recurso y acción. Registro de errores del servidor web.