¿Es más seguro usar un prefijo DB para las tablas?

Esto es seguridad a través de la oscuridad . Si bien puede que no le haga daño en todos los casos, por sí solo no proporciona seguridad viable. No confíe en esto como su protección.

Una parábola corta

Digamos que guardas tu dinero en un frasco con la etiqueta MONEY en tu casa. Como sabe que a veces se olvida de cerrar la puerta con llave cuando sale de la casa, vuelve a etiquetar el frasco COOKIES para evitar que un ladrón lo encuentre. ¿Te sentirías más seguro ahora? Claro, un ladrón muy perezoso y tonto podría pasarlo por alto, pero no tendrías que ser un ladrón experto para robar tu dinero. ¿No sería mejor recordar cerrar la puerta con llave?

Volver al mundo informático

Supongamos que tiene una instalación anterior de phpBB con una vulnerabilidad de inyección de SQL. Por defecto, las tablas tienen el prefijo phpbb_ . Cambia esto a obscure_ . ¿Esto te ayudará?

Es posible que un escaneo ingenuo no encuentre nombres de tabla codificados (como phpbb_users con todas las contraseñas) y, por lo tanto, falle. Pero incluso un script kiddie podría ejecutar un script que ejecute SHOW TABLES y encuentre su obscure_users . De hecho, existen herramientas que volcarán automáticamente el contenido de todas sus tablas a través de una vulnerabilidad de inyección SQL.

Conclusion

Entonces, ¿cuál es la lección aquí? Aunque cambiar los prefijos de la mesa (volver a etiquetar el frasco) puede que te proteja del ataque automático más simple y estúpido (el ladrón estúpido y perezoso), aún serías vulnerable a los ataques simples realizados por niños guionistas (un ladrón que busca en tus frascos). Cuando tiene una vulnerabilidad real como la inyección de SQL, la solución es corregir esa vulnerabilidad (bloquear la puerta) y no agregar un velo fino de oscuridad.

Dicho esto, una simple precaución que podría ralentizar algunos ataques podría valer la pena como "defensa en profundidad" si no tiene efectos secundarios dañinos. Simplemente no te sientas seguro solo porque lo implementas.

(Como un addendum, debo decir que ejecutar varias instalaciones en la misma base de datos puede tener implicaciones de seguridad, dependiendo de la situación).

No, es aceite de serpiente.

Cuando alguien encuentra una vulnerabilidad de inyección SQL en una aplicación, no saber los nombres de las tablas es solo un obstáculo muy pequeño. Muchas cargas útiles de inyección de stock (como la contraseña antigua antigua ' OR '1' = '1 ) ni siquiera necesitan saber ningún nombre de tabla. Y si el atacante descubre una forma de volcar datos de tablas arbitrarias, solo tiene que volcar la tabla del sistema INFORMATION_SCHEMA.TABLES (o su equivalente, dependiendo del sistema de base de datos usado) y obtener los nombres de todas las otras tablas.

no es necesariamente el aceite de serpiente tóxico . Ser capaz de tener múltiples instalaciones compartiendo la misma base de datos puede ser una característica legítima (como en un hospedador web de bajo presupuesto que solo le permite usar una única base de datos en su clúster de MySQL) y siempre y cuando solo tenga un al azar el prefijo y los nombres de las tablas aún son legibles por humanos, no afecta mucho al mantenimiento. Pero no agrega mucha seguridad.

En los sistemas basados en DBMS ampliamente adoptados como WordPress, es una práctica común configurar una instancia para usar nombres de tablas como my_fav_prefix_posts en lugar de wp_posts .

¿Por qué? Supuestamente reduce la velocidad de los niños de escritura.

Hace unos años hubo una serie de ataques masivos en las instancias de WordPress. Los criminales cibernéticos no sofisticados (guiones para niños) usaron un software de ataque no sofisticado (guiones) para tocar una gran cantidad de servidores en busca de vulnerabilidades. Cuando los scripts no encontraron la tabla wp_posts , pasaron al siguiente servidor en su lista de ataques. Por supuesto, un par de semanas más tarde, los scripts se volvieron un poco más sofisticados y las instancias de WordPress ya no podían ocultar sus tablas a simple vista.

Supongo que ese es el origen del mito de que los prefijos de base de datos alternativos proporcionan una capa adicional de seguridad. Ellos no.

Yo diría que esto no agrega nada a la seguridad. Pero si no puede (o no quiere) confiar en esquemas para separar sus tablas entre diferentes aplicaciones, el uso de diferentes prefijos permite que diferentes aplicaciones compartan la misma base de datos sin riesgo de conflicto.

Pero no agrega seguridad real.