Entradas

Mostrando las entradas etiquetadas como vulnerabilidad

Vulnerabilidad Web cache deception

Imagen
  www.onlinetis.com La Web Cache Deception es una vulnerabilidad de seguridad que permite a un atacante engañar a un servidor proxy de caché para que almacene una página web privada de un usuario. Esto se logra manipulando la URL de una forma que la haga parecer un recurso estático (como una imagen o un archivo CSS) para el servidor, pero que, en realidad, siga siendo una página dinámica y personalizada para el usuario. 🎭 ¿Cómo funciona el ataque? Este ataque explota un error de configuración en el servidor web o en el proxy de caché. La mayoría de los servidores de caché están configurados para guardar en caché los archivos estáticos (como .css , .js , .jpg ), pero no los recursos dinámicos (páginas de perfil, carrito de compras, etc.). El proceso de ataque consta de los siguientes pasos: El atacante crea una URL maliciosa . Esta URL tiene el formato de una página dinámica, pero con una extensión de archivo estático al final. Por ejemplo: https://ejemplo.com/perfil-de-usuario/mi...

Vulnerabilidad Web LLM attacks

Imagen
  www.onlinetis.com Las vulnerabilidades de Web LLM son un conjunto de riesgos de seguridad que surgen al integrar modelos de lenguaje grandes (LLMs) en aplicaciones web. Estas vulnerabilidades no son solo las tradicionales, sino que también aprovechan la naturaleza de los LLMs para manipular su comportamiento, divulgar información sensible o interactuar de forma no intencionada con los sistemas subyacentes. Tipos de vulnerabilidades clave Las vulnerabilidades de seguridad más comunes en los LLMs, según el OWASP Top 10 for LLM Applications , son: Prompt Injection : 😈 Esta es la vulnerabilidad más conocida. Un atacante puede insertar instrucciones maliciosas en el prompt del usuario para anular las directivas originales del sistema. Puede ser directa (cuando el atacante inserta el comando directamente en el cuadro de texto) o indirecta (cuando el comando malicioso se oculta en un documento o una página web externa que el LLM procesa). Por ejemplo, un chatbot que resume una pág...

Vulnerabilidad API testing

Imagen
  www.onlinetis.com Las pruebas de seguridad de una API (Application Programming Interface) buscan identificar y mitigar vulnerabilidades que podrían ser explotadas por atacantes para obtener acceso no autorizado a datos, manipular el comportamiento de la aplicación o causar una denegación de servicio. A diferencia de las pruebas de una aplicación web tradicional, las pruebas de API se centran en la lógica del negocio y la autenticación, ya que no existe una interfaz de usuario visual. Vulnerabilidades comunes en el testing de APIs El OWASP API Security Project ha identificado las vulnerabilidades más críticas para las APIs. Aquí están algunas de las más comunes: Broken Object Level Authorization (BOLA) : Es una de las vulnerabilidades más críticas. Ocurre cuando un usuario puede acceder a recursos que pertenecen a otro usuario simplemente cambiando el identificador del objeto en la URL. Por ejemplo, si un usuario con ID 100 puede ver su perfil en /api/users/100 , un atacante podrí...

Vulnerabilidad NoSQL injection

Imagen
  www.onlinetis.com La NoSQL injection es una vulnerabilidad de seguridad que se produce cuando una aplicación no sanitiza correctamente la entrada del usuario antes de utilizarla para construir y ejecutar consultas en una base de datos NoSQL. Al igual que la SQL injection, esta vulnerabilidad permite a un atacante inyectar código malicioso en la consulta, alterando su lógica o extrayendo datos sensibles. ¿Cómo funciona? A diferencia de las bases de datos relacionales que utilizan SQL, las bases de datos NoSQL (como MongoDB, CouchDB o Cassandra) no tienen un lenguaje de consulta estandarizado. Sus consultas se construyen a menudo con lenguajes de programación o con objetos JSON. Un ataque de inyección NoSQL se aprovecha de esta flexibilidad. Por ejemplo, en una aplicación que utiliza MongoDB, una consulta de autenticación podría lucir así en el código: JavaScript // La variable "password" viene de la entrada del usuario const query = { username : req.body.username, pas...

Vulnerabilidad Race conditions

Imagen
  www.onlinetis.com Una condición de carrera (race condition) es un fallo de seguridad que ocurre cuando la salida de una aplicación depende de la secuencia o el momento en que se ejecutan múltiples procesos o hilos de ejecución. Si esta secuencia no está controlada, un atacante puede manipular el timing para obtener un resultado inesperado y malicioso. ⏳ ¿Cómo funciona? Este tipo de vulnerabilidad se produce cuando una aplicación realiza varias operaciones que deberían ser atómicas (indivisibles), pero no lo son. Un atacante puede insertar su propia acción entre dos operaciones críticas de la aplicación, alterando el estado del sistema. Un ejemplo clásico es la gestión de transacciones bancarias. Supongamos que una aplicación tiene una función para transferir dinero que sigue estos pasos: Comprobar el saldo : Lee el saldo actual del usuario (ej: 100€). Verificar si hay fondos suficientes : Si el saldo es mayor o igual a la cantidad a transferir (ej: 50€), se procede. Realizar la...

Vulnerabilidad GraphQL API

Imagen
www.onlinetis.com   Una API de GraphQL es una forma de consultar y manipular datos que ofrece un control flexible y eficiente. Sin embargo, su flexibilidad puede introducir vulnerabilidades si no se implementa y configura correctamente. Estas vulnerabilidades suelen centrarse en el acceso excesivo a datos, la sobrecarga del servidor y la falta de control de acceso. Tipos de vulnerabilidades comunes en GraphQL Introspección activada en producción : GraphQL tiene una función llamada "introspección" que permite a los clientes descubrir el esquema completo de la API (tipos de datos, campos, etc.). Si esta función está activada en un entorno de producción, un atacante puede usarla para mapear toda la estructura de la API, identificar datos sensibles y planificar ataques más complejos. Denegación de servicio (DoS) : Debido a que las consultas de GraphQL pueden ser anidadas y complejas, un atacante puede crear una consulta profunda y anidada que sobrecargue el servidor de manera re...

Vulnerabilidad Prototype pollution

Imagen
  www.onlinetis.com La vulnerabilidad de Prototype pollution es un tipo de vulnerabilidad que afecta a lenguajes de programación basados en prototipos, principalmente JavaScript . Ocurre cuando un atacante puede inyectar propiedades en el prototipo base de un objeto ( Object.prototype ), que es el objeto del que heredan todos los demás objetos. Esto puede llevar a la ejecución de código arbitrario, la modificación de la lógica de la aplicación, o la denegación de servicio. 😈 ¿Cómo funciona? En JavaScript, cada objeto tiene una propiedad interna __proto__ que apunta al prototipo del objeto del que hereda. A su vez, el objeto base de toda la jerarquía de herencia es Object.prototype . Un ataque de Prototype pollution explota la falta de validación o la mala implementación en funciones que combinan o manipulan objetos. Un atacante puede enviar datos maliciosos que contienen una clave __proto__ con una propiedad adicional. Por ejemplo, si una aplicación tiene una función que combin...

Vulnerabilidad JWT

Imagen
www.onlinetis.com   Una vulnerabilidad en JWT (JSON Web Token) ocurre cuando una aplicación web implementa de forma incorrecta el uso de estos tokens, permitiendo a un atacante manipular el token para eludir la autenticación, escalar privilegios o acceder a información sensible. A diferencia de las vulnerabilidades en otros componentes, los fallos en JWT no están en el estándar en sí, sino en la forma en que los desarrolladores los implementan. La seguridad de un JWT depende de la correcta validación y manejo de sus tres partes: el encabezado, la carga útil (payload) y la firma. Tipos de vulnerabilidades comunes Un atacante puede explotar un JWT de varias maneras, pero los ataques más comunes se centran en la firma y el algoritmo utilizado: Manipulación del algoritmo (Algorithm Confusion) : Esta es una de las vulnerabilidades más críticas. Los JWT pueden usar algoritmos asimétricos (como RSA) o simétricos (como HMAC). Si una aplicación no valida explícitamente el algoritmo, un ata...