Me preguntaba cuáles serían algunos de los posibles abusos para una API HTTP que aceptaba consultas de SQL y resultados de conjuntos de resultados. El hecho de que esta sea la definición canónica de inyección SQL no se pierde en mí :)
En mi caso, tengo en mente una aplicación específica de PHP / MySQL que es Magento, una plataforma de comercio electrónico.
Aquí hay algunas medidas de seguridad que he considerado:
- Ruta de URL no estándar: para evitar el análisis masivo, cada instalación tendrá su propia ruta de URL (esto es similar a cómo se maneja el backend de administración de Magento)
- Una clave API de longitud decente
- acceso solo HTTPS
- Acceso de solo lectura a través de un usuario de MySQL de solo lectura.
- Acceso de solo lectura a través de análisis de SQL. Se requeriría un poco menos de configuración si el acceso de solo lectura pudiera implementarse de esta manera. Estaba considerando simplemente analizar las consultas de "INSERT", "UPDATE", "DROP", etc.
- Tablas y campos en lista negra. En su mayor parte, los datos de configuración se almacenan en una tabla llamada
core_config_data, por lo que podrían incluirse en la lista negra. También cosas como los tokens de tarjetas de crédito se pueden almacenar en un campo específico de una tabla específica. En implementaciones muy deficientes, las tarjetas de crédito también se pueden almacenar de forma clara, lo que, por supuesto, debería incluirse en la lista negra. - Acceso a la tabla y al campo de la lista blanca: tal vez, solo permitir el acceso a las tablas y campos de la lista blanca sería un mejor enfoque que una lista negra.
- Hay muchas extensiones de comunidad que también podrían almacenar información confidencial. Sería difícil bloquearlos de forma genérica de forma predeterminada, por lo que creo que una lista blanca podría ser la única opción para resolver esto.
- Algún mecanismo para un número / frecuencia máxima de reintentos
- Otras cosas estándar que se utilizan para asegurar las conexiones SSH, por ejemplo, como una lista blanca de IP, autenticación de clave pública, VPN, etc.
Suponiendo que estas medidas estuvieran vigentes, ¿sería esto tan seguro o más seguro que, digamos, el acceso SSH bloqueado por una lista blanca de IP?
ACTUALIZACIÓN: algunos detalles más específicos de la aplicación, para dar seguimiento a algunas de las preguntas en las respuestas.
- Lo que estoy buscando construir es un módulo Magento que se implementará en la tienda y aceptará consultas SQL para devolver los datos a mi aplicación SaaS. Soy dueño del módulo y de la aplicación SaaS.
- La aplicación en cuestión sería una aplicación SaaS que aprovechó Magento para extraer datos. Por lo tanto, no es una situación a la que solo tengan acceso los empleados de confianza.
- El nivel mínimo de seguridad ideal (desde la perspectiva de la cantidad de configuración) sería no usar un usuario de solo lectura.
- Supongamos que los falsos positivos que se bloquearían no son un problema (Lo sentimos, "Tablas de inserción de Bobby").
ACTUALIZACIÓN 2: Solo quería ampliar un poco más la razón por la que elegí encuadrar esta pregunta en términos de compararla con una conexión SSH con una lista blanca de direcciones IP.
Una conexión SSH para todos los propósitos y propósitos ya es funcionalmente lo mismo que una API de SQL sin formato (y mucho más) en el sentido de que puede SSH y conectarse a MySQl y luego hacer lo que sea. Por lo tanto, creo que si una API SQL es tan segura o más segura que una conexión SSH, puede presentar un nivel de riesgo aceptable.
También, sé que este tipo de pregunta puede ser demasiado subjetiva, por lo que quería encuadrarla de una manera que pudiera tener una respuesta relativamente objetiva, por lo que quise compararla con un escenario SSH específico.