CVE-2025-63943 — Inyección SQL en Grocery Store Management System 1.0

Descripción general

Se identificó una vulnerabilidad de Inyección SQL de alta severidad en el componente search_products.php de Grocery Store Management System 1.0, una aplicación web basada en PHP/MySQL creada por anirudhkannan.
El problema surge de una validación de entrada inadecuada y de la construcción insegura de consultas SQL utilizando el parámetro scost controlado por el usuario. Esta falla permite a los atacantes manipular la lógica SQL subyacente, lo que potencialmente conduce a la exposición de datos sensibles, alteración de datos o compromiso total de la base de datos.

---

Producto afectado

• Nombre: Grocery Store Management System
• Vendedor: anirudhkannan
• Versión: 1.0
• Repositorio:
  https://github.com/anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN-/tree/master
• Archivo afectado:
  Grocery/search_products.php

---

Descripción de la vulnerabilidad

La vulnerabilidad existe debido a la concatenación directa de entrada de usuario no validada en consultas SQL.
El parámetro POST scost, diseñado para representar un valor numérico de costo de producto, se incrusta en la cláusula WHERE de SQL sin:

• Saneamiento de entrada
• Aplicación de tipos
• Consultas parametrizadas
• Uso de sentencias preparadas

Esto permite a un atacante inyectar expresiones booleanas SQL arbitrarias, alterando el comportamiento de la consulta y extrayendo contenidos de la base de datos mediante técnicas de inyección SQL basada en booleanos.

La vulnerabilidad es explotable a través de una solicitud POST estándar a search_products.php. Cuando se proporcionan expresiones maliciosas, el backend devuelve diferencias de respuesta medibles (variaciones TRUE/FALSE), lo que confirma que la entrada del usuario influye en la lógica SQL.

---

Causa raíz

• Falta de validación en el lado del servidor del campo de entrada scost
• Uso directo de concatenación de cadenas para construir consultas SQL
• Ausencia de sentencias preparadas en la ruta de código afectada
• Sin filtrado ni listas blancas para campos de entrada numéricos

Estas condiciones permiten colectivamente a los atacantes modificar la lógica SQL prevista.

---

Severidad e impacto

Esta vulnerabilidad está clasificada como Alta debido a su baja complejidad de ataque, la ausencia de requisitos de autenticación y el impacto total de lectura/escritura en la base de datos.

Los impactos potenciales incluyen:

• Exposición de datos sensibles: Los atacantes pueden extraer datos de productos, usuarios o del sistema.
• Modificación o eliminación de datos: El SQL inyectado puede alterar o eliminar registros de la base de datos.
• Omisión de autenticación (posible): Si se utiliza en otras partes de la lógica de consulta de la aplicación.
• Compromiso total de la base de datos: Dependiendo de los privilegios y la configuración de la base de datos.
• Inestabilidad del sistema: Las consultas maliciosas podrían interrumpir el comportamiento normal de la aplicación.

---

Puntuación CVSS v3.1 (Evaluación preliminar)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Vector de ataque (AV): Red
• Complejidad de ataque (AC): Baja
• Privilegios requeridos (PR): Ninguno
• Interacción del usuario (UI): Ninguna
• Alcance (S): Sin cambios
• Confidencialidad (C): Alta
• Integridad (I): Alta
• Disponibilidad (A): Alta

Severidad estimada: Alta (9.8)

---

Resumen de explotación

La vulnerabilidad puede explotarse mediante valores manipulados enviados al parámetro scost.
Los atacantes pueden:

• Influir en la lógica booleana
• Provocar respuestas condicionales
• Enumerar estructuras de la base de datos
• Extraer información sensible

(Los payloads detallados se omiten intencionalmente para evitar su uso indebido.)

---

Mitigación y recomendaciones

Para desarrolladores / vendedores

Para remediar la vulnerabilidad:

1. Implementar sentencias preparadas / consultas parametrizadas
2. Aplicar una validación de entrada estricta — asegurar que scost solo acepte valores numéricos
3. Rechazar caracteres sospechosos — filtrar operadores, comillas, comentarios y símbolos de expresiones
4. Aplicar permisos de base de datos con privilegios mínimos
5. Auditar el código en busca de patrones similares en otras partes de la aplicación

Para usuarios

Hasta que haya un parche disponible:

• Restringir el acceso público a la aplicación
• Usar un firewall o WAF para bloquear solicitudes maliciosas
• Supervisar los registros en busca de comportamiento inusual relacionado con SQL

---

Referencias

• Inyección SQL de OWASP: https://owasp.org/www-community/attacks/SQL_Injection
• CWE-89 — Neutralización incorrecta de elementos especiales en comandos SQL