AppSec y APIs
Definiciones en lenguaje claro del tema appsec y apis.
Account takeover
En seguridad de aplicaciones, el account takeover es el desenlace en el que un atacante acaba controlando la cuenta de un usuario legítimo. No es una técnica concreta, sino el punto en el que convergen varias, y es el término que usa un informe cuando el negocio necesita el impacto y no el mecanismo.
Atributos de seguridad de las cookies (Cookie security attributes)
Los atributos de seguridad de las cookies son las marcas que el servidor pone junto a una cookie para limitar cómo la guarda y cuándo la envía el navegador. En seguridad de aplicaciones los que importan son Secure, HttpOnly y SameSite, más el ámbito que fijan Domain y Path y los prefijos de nombre __Host- y __Secure-, que son los que hacen ese ámbito exigible.
Autorización rota a nivel de función (BFLA)
En seguridad de APIs, la autorización rota a nivel de función es un fallo por el que la API comprueba que quien llama está autenticado, pero no que su rol tenga permiso para invocar esa operación concreta. El endpoint existe, el token es válido, y un usuario corriente llega a una función administrativa con solo llamarla.
Broken object level authorisation (BOLA)
En seguridad de APIs, la broken object level authorisation (BOLA) es el fallo de no comprobar que quien llama tiene derecho sobre el objeto concreto que nombra su petición. Es la primera entrada del OWASP API Security Top 10 y, en una prueba de API, el defecto que más veces deja a la vista los registros de otro tenant.
Bug (error de software)
Un bug es un defecto en el código de un programa que hace que se comporte de forma distinta a la prevista. No es un ataque ni una acción maliciosa: es un error involuntario. Y es el punto de partida de casi cualquier vulnerabilidad que no venga de una configuración floja o de una credencial robada.
Captcha
Un CAPTCHA es una prueba diseñada para distinguir si lo que hay al otro lado de un formulario es una persona o un programa automatizado.
Clickjacking
El clickjacking es un ataque en el que una página en la que la víctima confía se carga de forma invisible dentro de una página que controla el atacante, de modo que un clic dirigido a la página visible se entrega a la que está oculta. La víctima ejecuta una acción real y autenticada sin saber qué aplicación la ha recibido.
Command injection
En seguridad de aplicaciones, la command injection es un defecto por el que una entrada controlada por el usuario llega a un shell del sistema y se interpreta como parte de la línea de comandos en vez de como dato. El atacante añade sus propias instrucciones a la que la aplicación pretendía ejecutar, y el sistema operativo ejecuta las dos.
Condición de carrera (Race condition)
En seguridad de aplicaciones, una condición de carrera es un fallo en el que el resultado depende del orden en que se procesan peticiones concurrentes, porque una comprobación y la acción que autoriza no son atómicas. Enviar la misma petición muchas veces en paralelo hace que la aplicación actúe sobre un estado que ya ha invalidado.
Content Security Policy (CSP)
En seguridad web, la Content Security Policy (CSP) es una cabecera de respuesta que le dice al navegador de qué orígenes puede una página cargar script, estilos, marcos y demás recursos. Es un control de contención: no impide que ocurra una inyección, limita lo que el contenido inyectado tiene permitido hacer.
Cross-site request forgery (CSRF)
En seguridad de aplicaciones web, el cross-site request forgery (CSRF) es un ataque que hace que el navegador de un usuario con la sesión abierta envíe una petición que cambia estado a un sitio que confía en su cookie de sesión. El usuario no tiene que pulsar nada en el sitio atacado: la petición viaja sobre credenciales que el navegador adjunta por sí solo.
Cross-site scripting (XSS)
En seguridad de aplicaciones web, el cross-site scripting (XSS) es un defecto que permite a un atacante ejecutar su propio JavaScript en el navegador de otro usuario, dentro de la frontera de confianza de tu sitio. El navegador no sabe distinguir el script inyectado del tuyo, así que el script hereda la sesión de ese usuario, sus cookies y todo lo que la aplicación le deja hacer.
DAST
En seguridad de aplicaciones, DAST es dynamic application security testing: sondear una aplicación en marcha desde fuera con peticiones preparadas y juzgar las respuestas. No ve el código fuente, así que encuentra lo que es alcanzable de verdad, y eso es a la vez su ventaja y su límite.
Desbordamiento de búfer (Buffer overflow)
El desbordamiento de búfer ocurre cuando un programa escribe en un área de memoria temporal más datos de los que caben, y sobrescribe lo que hay al lado. Es una de las formas más antiguas de conseguir que una máquina ejecute instrucciones ajenas.
Deserialización insegura (Insecure deserialisation)
En seguridad de aplicaciones, la deserialización insegura es un fallo por el que una aplicación reconstruye objetos a partir de datos que controla un atacante, y esa reconstrucción en sí ejecuta código. El atacante no entrega una carga que la aplicación vaya a interpretar más tarde: el acto de leer la entrada es ya la explotación.
Fallo de lógica de negocio (Business logic flaw)
En seguridad de aplicaciones, un fallo de lógica de negocio es un defecto en lo que la aplicación permite, no en cómo está programada. Todas las peticiones están bien formadas y todos los controles técnicos funcionan; el atacante se limita a usar el flujo de trabajo en un orden, una cantidad o una combinación que los diseñadores nunca contemplaron, y la aplicación acepta.
Fijación de sesión (Session fixation)
En seguridad de aplicaciones web, la fijación de sesión es un ataque en el que el atacante fija o averigua un identificador de sesión antes de que la víctima se autentique, y la aplicación conserva ese mismo identificador después del inicio de sesión. El atacante presenta entonces el identificador y está dentro de la sesión autenticada sin haber sabido nunca la contraseña.
Inyección de entidades externas XML (XXE)
La inyección de entidades externas XML es una vulnerabilidad por la que una aplicación interpreta XML suministrado por el atacante con un analizador que resuelve entidades externas. La declaración que va dentro del documento le dice al analizador que traiga un fichero local o una URL, y el analizador obedece, convirtiendo la subida de un documento en la revelación de un fichero o en una petición hecha por el servidor.
Inyección SQL (SQL injection)
En seguridad de aplicaciones, la inyección SQL es un fallo por el que una entrada cambia el significado de la consulta que construye la aplicación, en vez de leerse como dato dentro de ella. Las consultas parametrizadas arreglan el caso común, pero los identificadores como la tabla, la columna o el orden no se pueden parametrizar, y el SQL dinámico dentro de un procedimiento almacenado reconstruye el mismo problema.
Mala configuración de CORS (CORS misconfiguration)
En seguridad de APIs y web, una mala configuración de CORS es un conjunto de cabeceras de cross-origin resource sharing que da permiso a un sitio hostil para leer respuestas autenticadas de tu servicio. CORS relaja la política del mismo origen; mal configurado, retira la frontera que impide que el script de un sitio llegue a los datos de otro.
Mass assignment
El mass assignment es un defecto de API en el que un framework enlaza los campos de una petición entrante directamente sobre un objeto interno, de manera que quien llama puede fijar propiedades que la interfaz no ofreció nunca. Añadir un campo como role o isAdmin a una actualización de perfil por lo demás legítima es todo el ataque.
OWASP API Security Top 10
En seguridad de APIs, el OWASP API Security Top 10 es una lista de concienciación aparte que cubre las vulnerabilidades que aparecen específicamente en las interfaces de programación. Existe porque las APIs fallan de otra manera que las páginas web: el grafo de objetos queda expuesto de forma directa, y la mayoría de sus entradas son problemas de autorización y no de inyección.
OWASP Top 10
En seguridad de aplicaciones, el OWASP Top 10 es un documento de concienciación que se actualiza cada cierto tiempo y que enumera las categorías de fallo de aplicación web que el proyecto considera más importantes. Es un conjunto de categorías que conviene conocer, publicado por una fundación sin ánimo de lucro. No es una norma, ni una certificación, ni un alcance de prueba.
Rate limiting
En seguridad de aplicaciones y de APIs, el rate limiting es el control que pone tope a cuántas peticiones puede hacer un cliente en una ventana de tiempo, para que los ataques por adivinación, la enumeración y el abuso le cuesten tiempo al atacante. No decide si una petición está permitida: decide cada cuánto se puede hacer la pregunta.
Redirección abierta (Open redirect)
Una redirección abierta es un fallo por el que una aplicación manda al visitante a una URL sacada de un parámetro sin comprobarla contra una lista de destinos permitidos. Por sí sola no filtra nada, y por eso se descarta muchas veces; su valor para un atacante viene de aquello con lo que se encadena.
Referencia directa a objeto insegura (IDOR)
En pruebas de web y de API, una referencia directa a objeto insegura (IDOR) es un fallo por el que la aplicación toma un identificador directamente de la petición y lo usa para recuperar o modificar un registro sin comprobar que quien llama es su dueño. Cambiar un número en una URL devuelve los datos de otra persona.
SAST
En seguridad de aplicaciones, SAST es el análisis estático de seguridad de aplicaciones: analizar el código fuente, el bytecode o los binarios en busca de vulnerabilidades sin ejecutar el software. Lee el código como lo hace un compilador, sigue cómo se mueven los datos desde donde entran hasta donde se usan, e informa de los caminos que parecen inseguros.
Secuestro de sesión (Session hijacking)
En seguridad web y de identidad, el secuestro de sesión es el robo y la reutilización del token que demuestra que un usuario ya ha iniciado sesión. El atacante no llega a conocer la contraseña y no se enfrenta nunca al formulario de acceso: presenta la sesión robada y la aplicación le trata como al usuario que la creó.
Seguridad de GraphQL (GraphQL security)
En seguridad de APIs, la seguridad de GraphQL es el conjunto de controles que necesita una API en la que quien decide la forma de cada respuesta es el cliente y no el servidor. Un solo endpoint, un esquema tipado y consultas compuestas por el cliente rompen varias premisas de las que dependen las herramientas de seguridad para REST y quienes revisan REST.
Server side template injection (SSTI)
El server side template injection es una vulnerabilidad en la que la entrada del usuario se concatena dentro de una plantilla que el servidor renderiza después, de forma que esa entrada se evalúa como sintaxis de plantilla en vez de tratarse como dato. Como los motores de plantillas exponen objetos del lenguaje, suele escalar de evaluar expresiones a la ejecución remota de código.
Server-side request forgery (SSRF)
En seguridad web y cloud, el server-side request forgery (SSRF) es un defecto por el que un atacante consigue que la aplicación envíe una petición HTTP a su elección desde la posición de red de la propia aplicación. La petición llega con la dirección de origen del servidor y con sus credenciales, así que alcanza servicios internos que nunca se pensaron para estar expuestos.
Shadow API
Una shadow API es una interfaz viva y alcanzable pero ausente del inventario que la organización defiende: sin documentar, olvidada tras una migración, o funcionando todavía desde una versión que se suponía retirada. Está autenticada y monitorizada al nivel que rigiera el día en que se construyó, que suele ser ninguno.
STRIDE
STRIDE es una regla mnemotécnica de modelado de amenazas que se usa en las revisiones de diseño seguro. Nombra seis modos de fallo sobre los que razonar en cada componente de un sistema: suplantación, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Cada uno es la negación de una propiedad de seguridad que el diseño debería sostener.
Subdomain takeover
En pruebas externas, un subdomain takeover es lo que ocurre cuando un registro DNS sigue apuntando a un recurso de cloud o de alojamiento que ya no existe, de forma que cualquiera puede registrar ese recurso y servir contenido desde tu nombre de dominio. El dominio sigue resolviendo; aquello a lo que resuelve es ahora de otro.