CompTIA SY0-701: Seguridad de Aplicaciones y Web — Guía de estudio
Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.
Las aplicaciones modernas se encuentran en la intersección de la lógica de negocio, los datos sensibles y la entrada de usuarios no confiables. Debido a que las interfaces de usuario web y móviles están expuestas a todo internet, representan una de las superficies de ataque más grandes y explotadas de forma más consistente en cualquier empresa. Defenderlas requiere controles por capas que comienzan con la forma en que se escribe el código y se extienden a través de protecciones en tiempo de ejecución, verificación de integridad y pruebas continuas.
Ataques de inyección
La inyección sigue siendo la vulnerabilidad web arquetípica. Ocurre cada vez que una aplicación concatena entradas no confiables en un intérprete —una consulta SQL, un comando de shell, un filtro LDAP, un analizador XML o un motor de plantillas— sin separar adecuadamente el código de los datos. En una inyección de SQL (SQLi), un atacante manipula una consulta para que la base de datos ejecute lógica controlada por el atacante. Un patrón vulnerable clásico en PHP se ve así:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
Enviar admin' OR '1'='1 transforma la consulta en una tautología que devuelve todas las filas. Variantes más avanzadas incluyen la extracción basada en UNION (' UNION SELECT credit_card FROM payments--), la inferencia ciega booleana o basada en tiempo (' AND SLEEP(5)--), y la exfiltración fuera de banda a través de callbacks de DNS. La solución definitiva son las consultas parametrizadas o las sentencias preparadas, que envían la plantilla de la consulta y sus parámetros a la base de datos como estructuras separadas:
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
La inyección de comandos sigue el mismo patrón, pero apunta al shell del sistema operativo. Código como os.system("ping " + host) permite a un atacante enviar 8.8.8.8; cat /etc/passwd y ejecutar comandos arbitrarios. La remediación requiere evitar por completo la invocación del shell, usar APIs que aceptan arreglos de argumentos (subprocess.run(["ping", host], shell=False)), y aplicar una validación estricta mediante listas de permitidos (allow-lists) a cualquier valor que deba llegar a un shell.
Cross-Site Scripting y CSRF
El Cross-Site Scripting (XSS) es la inyección de scripts maliciosos en páginas renderizadas por una aplicación confiable, provocando que el navegador de la víctima ejecute código del atacante dentro del origen del sitio. El XSS reflejado rebota los payloads desde un parámetro vulnerable; el XSS almacenado persiste el payload en la base de datos y lo entrega a cada visitante; el XSS basado en DOM ocurre completamente en el JavaScript del lado del cliente que escribe datos no confiables en innerHTML, document.write o receptores (sinks) similares. Las consecuencias van desde el secuestro de sesión y el registro de pulsaciones de teclas (keylogging) hasta la toma de control total de la cuenta a través de acciones forzadas.
El Cross-Site Request Forgery (CSRF) es un ataque distinto pero complementario. Abusa de la inclusión automática de cookies del navegador para engañar a un usuario autenticado y hacer que envíe una solicitud no deseada —por ejemplo, un formulario oculto en un sitio malicioso que hace un POST a bank.com/transfer. Las defensas incluyen tokens sincronizadores (valores aleatorios por sesión incrustados en los formularios y verificados en el lado del servidor), el atributo de cookie SameSite=Lax o SameSite=Strict, y requerir reautenticación para acciones sensibles. A menudo se confunden XSS y CSRF, pero XSS ejecuta código en el navegador de la víctima, mientras que CSRF simplemente hace que el navegador emita una solicitud; notablemente, un ataque de XSS exitoso puede anular la mayoría de las defensas contra CSRF.
Codificación segura: validación de entradas vs. codificación de salidas
Dos controles que se confunden con frecuencia, pero que resuelven problemas diferentes. La validación de entradas asegura que los datos se ajusten a la estructura esperada —longitud, tipo, juego de caracteres, rango, formato— antes de que la aplicación actúe sobre ellos. Debe realizarse en el servidor, utilizando listas de permitidos (allow-lists) siempre que sea posible (^[A-Za-z0-9_]{3,20}$ para un nombre de usuario). La validación del lado del cliente con JavaScript es solo una característica de usabilidad; puede ser omitida con cualquier proxy HTTP y nunca debe ser el límite de seguridad.
La codificación de salidas asegura que los datos se rendericen de forma segura en cualquier contexto al que fluyan. La misma cadena que es una entrada perfectamente válida puede necesitar un tratamiento diferente dependiendo de dónde termine: el contexto del cuerpo HTML requiere codificación de entidades HTML (< → <), el contexto de atributo requiere codificación de atributo entrecomillado, el contexto de JavaScript requiere escapado \xHH, y las URL requieren codificación de porcentaje (percent-encoding). Un nombre de usuario como O'Brien es una entrada legítima, pero debe codificarse como O'Brien cuando se coloca en HTML. La validación de entradas no puede reemplazar la codificación de salidas, y la codificación no puede reemplazar la validación: abordan problemas diferentes en puntos distintos del ciclo de vida de los datos.
El fortalecimiento adicional incluye cabeceras de Content Security Policy (CSP) para restringir las fuentes de los scripts, los flags HttpOnly y Secure en las cookies de sesión, y APIs parametrizadas en cada límite de confianza.
WAFs y protecciones para la carga de archivos
Un firewall de aplicaciones web (WAF) inspecciona el tráfico HTTP y bloquea las solicitudes que coinciden con patrones maliciosos conocidos: firmas de SQLi, payloads de XSS, secuencias de path traversal, anomalías de protocolo. Desplegado como un proxy inverso (ModSecurity con el OWASP Core Rule Set, AWS WAF, Cloudflare, F5), proporciona un valioso parcheo virtual (virtual patching) cuando se descubre una vulnerabilidad antes de que el código pueda ser corregido. Sin embargo, un WAF es un control compensatorio, no un sustituto de la codificación segura. Los atacantes sofisticados suelen eludir los WAFs mediante trucos de codificación, contaminación de parámetros HTTP (HTTP parameter pollution) y fragmentación de payloads.
La carga de archivos merece una atención especial porque combina contenido no confiable con almacenamiento en el lado del servidor y, a menudo, ejecución. Las protecciones incluyen validar el tipo de archivo inspeccionando los magic bytes en lugar de confiar en la extensión o en la cabecera Content-Type, almacenar los archivos cargados fuera del web root, renombrar los archivos con identificadores generados por el servidor (para prevenir el directory traversal a través de nombres de archivo manipulados), escanear con un antivirus antes del almacenamiento, y servir el contenido cargado por el usuario desde un dominio separado para prevenir la ejecución de scripts del mismo origen (same-origin).
Escenario práctico: inyección SQL que lleva a un compromiso total de la base de datos
El endpoint de búsqueda de productos de una empresa minorista aceptaba un parámetro category que se concatenaba directamente en una consulta SQL sin sanitización. Un investigador de seguridad descubrió que al enviar ' UNION SELECT table_name,null,null FROM information_schema.tables-- se devolvía una lista de todas las tablas de la base de datos en la respuesta. Solicitudes posteriores extrajeron la tabla customers, obteniendo 1,2 millones de registros que incluían nombres, direcciones de correo electrónico y contraseñas con hash de bcrypt. El atacante también descubrió un procedimiento almacenado que podía ser invocado mediante inyección SQL para escribir archivos en la raíz web, lo que permitió el despliegue de un webshell y el compromiso total del servidor. La vulnerabilidad había estado presente durante tres años y había pasado desapercibida en dos pruebas de penetración anteriores porque los evaluadores solo habían probado el formulario de inicio de sesión, no el endpoint de búsqueda. La lección: las pruebas de inyección deben cubrir cada parámetro en cada endpoint, no solo las rutas de autenticación obvias.
← Respuesta a Incidentes · Todos los dominios · Seguridad de Cloud →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →