¿Cuál es el método recomendado para escanear variables antes de insertarlas en la base de datos en Java?¿Debo utilizar PreparedStatements para todas las inserciones de mi base de datos en Java?
Según entiendo, puedo usar PreparedStatement.setString() para escapar de los datos, pero PreparedStatement parece poco práctica si no va a ejecutar la misma consulta siempre otra vez .. ¿Hay una mejor manera de hacerlo sin preparando cada consulta?
Sí, utilice declaraciones preparadas para todo.
Se analizan una vez.
Son inmunes a los ataques de inyección SQL.
Son un mejor diseño ya que hay que pensar en su SQL y cómo se utiliza.
Si crees que solo se usan una vez, no estás viendo la imagen completa. Algún día, sus datos o su aplicación cambiarán.
Editar.
¿Por qué declaraciones preparadas hará pensar en su SQL?
al colocar una cadena (o simplemente ejecutar un bloque literal del texto) no va a crear un nuevo PreparedStatement objeto. Simplemente estás ejecutando SQL, se puede hacer de manera muy casual.
Cuando tiene que crear (y guardar) un PreparedStatement, tiene que pensar un poquito más acerca de la encapsulación, la asignación de responsabilidades. La preparación de una declaración es un evento con estado antes de realizar cualquier procesamiento de SQL.
El trabajo adicional es pequeño, pero no es insignificante. Es lo que hace que las personas comiencen a pensar en ORM y en una capa de caché de datos, y cosas así para optimizar su acceso a la base de datos.
Con declaraciones preparadas, acceso a base de datos, es decir, más intencional menos casual.
No diría que es inmune, pero está protegido. – Milhous
@Milhous. Discrepar. Las declaraciones preparadas que usan variables de enlace y texto SQL estático son inmunes. Completamente. –
Está asumiendo que el enlace no tiene errores. No me malinterpreten, todo lo que uso son declaraciones preparadas. – Milhous
Preparar una declaración no es tan caro. Es más seguro que la mayoría de las alternativas.
Nunca se debe construir una consulta SQL sí mismo utilizando la concatenación de cadenas. Nunca debe escaparse manualmente de variables/datos de usuario al construir una consulta SQL. El escape real requerido depende de su base de datos subyacente, y en algún momento alguien se olvidará de escapar.
El punto es este: con declaraciones preparadas, es imposible para crear una declaración inyectable de SQL. Con escape personalizado, es posible. La elección es obvia.
Con "nunca construyas una consulta SQL usando la concatenación de cadenas", presumiblemente estás hablando de la vinculación de las variables de tiempo de ejecución, no de la construcción de la declaración SQL en sí misma. Hay muchos casos en los que el LMD de una consulta debe cambiar en tiempo de ejecución, en cuyo caso, la concatenación de cadenas parece correcta –
he oído el argumento de que PreparedStatement cuesta un poco más de una sobrecarga adicional Declaración llano, y que debe ser seguro si no estoy concatenando la entrada del usuario en mi consulta. Esto puede ser cierto, pero el costo adicional no es mucho y las consultas SQL cambian con el tiempo.Si comienza a usar un Estado de cuenta hoy porque ha demostrado que su consulta es a prueba de inyecciones, se está preparando para el fallo el día en que un programador de mantenimiento cambia el SQL para aceptar la entrada del usuario, pero no lo hace. piense en cambiar esa Declaración a un Estado Preparado. Mi consejo es usar siempre una declaración preparada para evitar problemas antes de que te encuentre.
Mejor aún, no use la API de JDBC directamente, ya que es propensa a errores (por ejemplo, no se pueden limpiar correctamente todos los recursos en todos los casos). Utilice un objeto auxiliar JDBC, como la interfaz JdbcOperations de Spring, que reduce considerablemente el tamaño y el funcionamiento de su código. Si solo usa Spring para esta característica, aún se ha hecho un favor masivo en comparación con el uso de la API de JDBC directamente.
Totalmente de acuerdo con esta. Spring lo hace TAN fácil. También hace que las pruebas sean muy fáciles si usa las cosas transaccionales. – Fortyrunner
Puede seguir adelante y usar Hibernate (u otro ORM): entonces puede (principalmente) evitar mezclar SQL con su código Java por completo. Hay una pequeña curva de aprendizaje con ella (especialmente colecciones), pero hay muchos documentos y tutoriales a su alrededor. Si sus datos existentes ya están estructurados como beans Java, Hibernate puede usarlos: incluso puede generar tablas basadas en sus clases, o puede crear sus beans Java basados en tablas de bases de datos. – monojohnny