Todo mundo está familiarizado com a injeção de SQL. É um método de ataque comum. Os invasores inserem alguns fragmentos SQL estranhos nas informações de formulário ou URL da interface, como declarações "ou '1' = '1'", que podem invadir aplicativos com verificação insuficiente de parâmetros. Portanto, precisamos fazer algum trabalho em nosso aplicativo para evitar tais métodos de ataque. Em algumas aplicações com alta segurança, como software bancário, geralmente usamos o método de substituir todas as instruções SQL por procedimentos armazenados para evitar a injeção de SQL. É claro que isso é uma maneira muito segura, mas podemos não precisar desse método rígido em nosso desenvolvimento diário.
Como uma estrutura de camada de persistência semi-automatizada, a estrutura de Mybatis deve ser escrita manualmente por nós mesmos. Neste momento, é claro, é necessário impedir a injeção de SQL. De fato, o SQL da Mybatis é uma estrutura com função "Input + Output", semelhante a uma função, como segue:
<select id = "getBlogbyId" resultype = "blog" parametertype = "int"> <br> selecione ID, título, autor, conteúdo do blog onde id =#{id} </select> Aqui, o ParameterType indica o tipo de parâmetro de entrada e o resultado do resultado indica o tipo de parâmetro de saída. Em resposta ao acima, se quisermos impedir a injeção de SQL, naturalmente precisamos trabalhar duro para inserir parâmetros. A parte destacada no código acima é a parte em que os parâmetros de entrada são emendados no SQL. Depois de passar nos parâmetros, imprima a instrução SQL executada e você verá que o SQL se parece com o seguinte:
Selecione ID, título, autor, conteúdo do blog onde id =?
Não importa quais parâmetros sejam inseridos, o SQL impresso é assim. Isso ocorre porque o mybatis permite a função de pré -compilação. Antes da execução do SQL, o SQL acima será enviado ao banco de dados para compilação. Durante a execução, você pode usar o SQL compilado diretamente e substituir o espaço reservado "?". Como a injeção de SQL só pode funcionar no processo de compilação, esse método pode evitar o problema da injeção de SQL.
Como os mybatis alcançam a pré-compilação do SQL? De fato, na parte inferior da estrutura, a classe preparada no JDBC está em ação. Preparado, é uma subclasse de afirmação com a qual estamos muito familiarizados. Seu objeto contém instruções SQL compiladas. Essa abordagem "pronta" não apenas melhora a segurança, mas também melhora a eficiência ao executar um SQL várias vezes, porque o SQL foi compilado e não precisa compilar ao executar novamente.
Dito isto, podemos impedir a injeção de SQL usando Mybatis? Claro que não, consulte o seguinte código:
<select id = "orderblog" resultype = "blog" parametertype = "map"> selecione id, título, autor, conteúdo do pedido do blog por $ {orderParam} </leclect> Após uma observação cuidadosa, o formato do parâmetro embutido mudou de "#{xxx}" para $ {xxx}. Se atribuirmos o parâmetro "OrderParam" a "ID" e imprimirmos o SQL, parece assim:
Selecione ID, título, autor, conteúdo da ordem do blog por id
Obviamente, isso não pode impedir a injeção de SQL. Em Mybatis, os parâmetros no formato "$ {xxx}" participarão diretamente da compilação SQL, impedindo assim ataques de injeção. No entanto, quando se trata de nomes dinâmicos de tabela e nomes de colunas, podemos usar apenas formatos de parâmetros como "$ {xxx}", por isso precisamos processar manualmente esses parâmetros no código para evitar a injeção.
Conclusão: Ao escrever declarações de mapeamento mybatis, tente usar o formato "#{xxx}". Se você precisar usar parâmetros como "$ {xxx}", deve fazer um bom trabalho de filtragem para evitar ataques de injeção de SQL.
O exposto acima está o conteúdo completo da estrutura da camada de persistência Java Mybatis impede a injeção de SQL que o editor traz para você. Espero que todos apoiem mais wulin.com ~