Uno de los consejos más comunes con respecto a la protección de WordPress , Magento , y otras piezas de software ampliamente utilizadas es agregar un prefijo a los nombres de las tablas de la base de datos o cambiar el prefijo predeterminado. Por ejemplo, con frecuencia se escucha para cambiar el prefijo wp_ predeterminado para WordPress a algo oscuro, como 1sdf34jSqo8_ .
La pregunta que tengo es esta: ¿No es esto nada más que seguridad por oscuridad? Y si es así, ¿es una buena práctica hacerlo de todos modos?
Los pros y los contras que veo a esto son:
Adventages:
- Muchos ataques de inyección de SQL necesariamente tienen dos pasos: identificar las tablas y luego hacer otra cosa. Esto no evita ataques como enviar una contraseña como
xyz' OR 1=1 --', pero sí evita, por ejemplo, que una consulta comoDROP TABLE foorealmente haga nada, hasta que el atacante de alguna manera aprenda el nombre de la tabla. - Ayuda a mitigar el ataque de día cero de pesadilla en el que realmente existe una vulnerabilidad de SQLi. Un poco de oscuridad es útil en esas situaciones.
- Podría hacer que sea un poco más fácil interceptar y bloquear ciertos ataques a través de mod_security o un WAF. Por ejemplo, si mi prefijo de tabla es
1sdf34jSqo8_y esa cadena aparece en los datos GET o POST, seré muy sospechoso de esa solicitud. Pero entonces, si el atacante tiene esa cadena, es probable que ya esté pwned. Ver ese texto de cualquier persona que aún no se haya autenticado como superusuario es en realidad una alerta directa al buscapersonas, de hecho. - Permite la instalación de múltiples copias de una aplicación en una base de datos, para aquellos casos en que un proveedor de servicios o host le permite tener 1 o 2 bases de datos, pero no limita el número de tablas (lo que nunca tuvo sentido para mí , pero yo divago). * Esto no es realmente un problema de seguridad, es cierto, pero es una de las principales razones por las que las personas habilitan el prefijo de esta manera.
Desventajas:
- Esto es un dolor huge para implementar como desarrollador. Significa que cada referencia de tabla en su código necesita una constante o variable agregada al nombre de la tabla. Los SELECT simples son lo suficientemente malos; Los cambios de esquema y los parches pueden convertirse en pesadillas reales. Esto también rompe la capacidad de muchos IDE para realizar tareas de autocompletado y correcciones ortográficas en sentencias de SQL.
- Gracias a los problemas anteriores, podría decirse que más puede dar lugar a errores y posibles vulnerabilidades debido a que, una vez, alguien de su equipo escribió una declaración como
SELECT * FROM {prefix}foo LEFT JOIN bar ...y olvidó el prefijo en alguna parte. - Obviamente, es al menos una forma de seguridad por oscuridad. Esto conduce a descuidos, exceso de confianza, etc.
- No resuelve ningún problema que las declaraciones preparadas y las listas blancas no solucionen.
Creo que la respuesta aceptada a la pregunta "¿Está bien revelar los nombres de las tablas de la base de datos?" resume muy bien mis pensamientos: usted no pierde nada al revelar nombres de tablas si su base de datos está protegida contra inyecciones. Si hay una brecha en otra capa, como un script malicioso cargado y ejecutado con éxito, entonces (1) el prefijo de la tabla será fácil de descubrir, y (2) de todos modos, será abrumado.
Por lo tanto, la versión corta de la pregunta: ¿es esto realmente algo que los desarrolladores deberían hacer al crear aplicaciones, o es simplemente una mala práctica enmascararse como una capa adicional de seguridad?
EDITAR: Para ser claros, no estoy preguntando si el usuario final debe seguir adelante y cambiar los prefijos para, por ejemplo, la base de datos de una instalación de WordPress. Estoy preguntando si, cuando un desarrollador está creando una aplicación que utiliza una base de datos, el desarrollador debería habilitar este tipo de funcionalidad en primer lugar.