Todos están familiarizados con la inyección SQL. Es un método de ataque común. Los atacantes ingresan a algunos fragmentos SQL extraños en la información del formulario o URL de la interfaz, como las declaraciones "o '1' = '1'", que pueden invadir aplicaciones con una verificación de parámetros insuficiente. Por lo tanto, necesitamos hacer un trabajo en nuestra aplicación para evitar tales métodos de ataque. En algunas aplicaciones con alta seguridad, como el software bancario, a menudo utilizamos el método para reemplazar todas las declaraciones SQL con procedimientos almacenados para evitar la inyección de SQL. Por supuesto, esta es una forma muy segura, pero es posible que no necesitemos este método rígido en nuestro desarrollo diario.
Como un marco semiautomático de la capa de persistencia, el marco mybatis debe ser escrito manualmente por nosotros mismos. En este momento, por supuesto, es necesario prevenir la inyección de SQL. De hecho, MyBatis 'SQL es una estructura con la función "entrada + salida", similar a una función, como sigue:
<Select id = "getBlogById" resultType = "Blog" parametertype = "int"> <br> select id, título, autor, contenido de Blog Where id =#{id} </select> Aquí, Parametertype indica el tipo de parámetro de entrada, y resultType indica el tipo de parámetro de salida. En respuesta a lo anterior, si queremos prevenir la inyección de SQL, naturalmente tenemos que trabajar duro en la entrada de parámetros. La parte resaltada en el código anterior es la parte donde los parámetros de entrada están empalmados en SQL. Después de pasar los parámetros, imprima la instrucción SQL ejecutada y verá que SQL se ve así:
Seleccione ID, Título, Autor, Contenido de Blog Where ID =?
No importa qué parámetros se ingresen, el SQL impreso es así. Esto se debe a que MyBatis permite la función de precompilación. Antes de ejecutar SQL, el SQL anterior se enviará a la base de datos para la compilación. Durante la ejecución, puede usar el SQL compilado directamente y reemplazar el marcador de posición "?". Debido a que la inyección de SQL solo puede funcionar en el proceso de compilación, este método puede evitar el problema de la inyección SQL.
¿Cómo logra MyBatis previa a la compilación de SQL? De hecho, en la parte inferior del marco, la clase PreparationStatement en JDBC está funcionando. PreparationStatement es una subclase de declaración con la que estamos muy familiarizados. Su objeto contiene declaraciones SQL compiladas. Este enfoque "listo" no solo mejora la seguridad, sino que también mejora la eficiencia al ejecutar un SQL varias veces, porque SQL se ha compilado y no es necesario compilarlo al ejecutar nuevamente.
Dicho esto, ¿podemos evitar la inyección de SQL usando mybatis? Por supuesto que no, consulte el siguiente código:
<Select id = "OrderBlog" resultType = "Blog" Parametertype = "Map"> Seleccione ID, Título, Autor, Contenido de Blog Order by $ {OrderParam} </select> Después de una observación cuidadosa, el formato del parámetro en línea ha cambiado de "#{xxx}" a $ {xxx}. Si asignamos el parámetro "OrderParam" a "ID" e imprimemos el SQL, parece esto:
Seleccione ID, Título, Autor, Contenido de Blog Order por ID
Obviamente, esto no puede evitar la inyección de SQL. En MyBatis, los parámetros en el formato "$ {xxx}" participarán directamente en la compilación SQL, evitando así ataques de inyección. Sin embargo, cuando se trata de nombres de tabla dinámicas y nombres de columnas, solo podemos usar formatos de parámetros como "$ {xxx}", por lo que necesitamos procesar manualmente dichos parámetros en el código para evitar la inyección.
Conclusión: al escribir declaraciones de mapeo myBatis, intente usar el formato "#{xxx}". Si tiene que usar parámetros como "$ {xxx}", debe hacer un buen trabajo manualmente filtrado para evitar ataques de inyección SQL.
Lo anterior es el contenido completo del marco de la capa de persistencia Java myBatis evita la inyección de SQL que el editor le trae. Espero que todos apoyen a Wulin.com más ~