Desde una perspectiva de seguridad, ¿en qué se diferencian las soluciones dinámicas de tipo SQL y ORM de las arquitecturas de servidor cliente de finales de la década de 1990?

La respuesta depende en gran medida del modelo de amenaza y la arquitectura general del sistema en cuestión. En resumen, siempre hay una compensación compleja entre la superficie de ataque expuesta, la complejidad del código y el rendimiento del sistema.

Un modelo cliente-servidor tradicional de los años 90 con usuarios que interactúan con un software de cliente rico (cliente grueso) en sus estaciones de trabajo, cada uno de ellos accediendo directamente a la base de datos a través de la red se considera obsoleto (durante más de diez años más o menos), muy manejable y difícil de asegurar. Se ha criticado a favor de las aplicaciones de varios niveles, donde algún tipo de middleware funciona como el cliente de la base de datos y los usuarios interactúan con una interfaz web que habla con ese middleware. El ORM y otras capas de abstracción, por supuesto, tienen su código ejecutándose dentro de ese middleware.

Tal enfoque mejora la capacidad de administración, la escalabilidad y reduce en gran medida la superficie de ataque para la base de datos (y los servidores de la base de datos) donde se almacenan los datos críticos (ya que no más que un grupo constante de máquinas de middleware accede a la base de datos en una red separada y lo hacen) no ejecute SQL modificable por el usuario dentro de la base de datos a menos que esté programado explícitamente para hacerlo), pero el middleware y la interfaz se convierten en nuevos objetivos. En la mayoría de los marcos, encontrará algunas contramedidas explícitas o implícitas contra, por ejemplo, la inyección SQL clásica (hacen cumplir las declaraciones preparadas autogeneradas con variables de enlace y varias validaciones para SQL generado automáticamente), pero el middleware en sí mismo puede ser vulnerable a clases de ataques completamente diferentes ( por ejemplo, SSRF viene a mi mente primero). Se requieren varios protocolos de aplicación para conectar el cliente ligero (navegador), el frontend, los niveles de middleware, por lo tanto, el código que los maneja también será el nido de muchas vulnerabilidades (por ejemplo, si uno usa XML, prepárese para un montón de analizador XML errores, etc.).