• 聊聊SQL注入


    SQL注入问题

    • 概述:

      • 首先SQL注入是一个非常危险的操作,很可能被一些不怀好意的人钻空导致我们系统出现异常等状况,比如数据库遭到破坏或被入侵。
    • 直接原因:

      • 在页面中有数据交互的地方,攻击者构造sql语句,使web服务器执行恶意命令访问数据库。
    • 根本原因:服务端没有严格检验用户数据导致SQL注入漏洞,像使用JDBC的Statement语句添加SQL语句,如下:

      • 由于我们的JDBC在对数据库进行操作时,需要客户端传入一些参数。我们在日常中的处理是将字符串参数作为SQL语句进行拼接,但是加入客户端传入SQL语句关键字恶意篡改SQL语句就会改变服务端SQL语义发生系统异常。严重时就会导致系统和数据库破坏,这时的攻击方式就叫SQL注入了。

      • 实例:模拟登录请求传入用户id和密码参数,使用字符串拼接导致的SQL注入。

        • 拼接SQL语句,就会出现SQL注入的安全问题,拼接代码如下:

          String sql = "select * from user where username='" + uid + "' and password='" + passwd + "'";
        • 若此时传入参数如下:永真式万能密码 或 封号结束注释后面条件验证(只能说人的脑洞真大哈哈),还有更奇葩的像 Union 注入

          params.put("uid", "malongfei");
          params.put("passwd", "111' or '1' = '1");
          // 或者
          params.put("uid", "malongfei'; -- ")
          // 或者
          params.put("uid", "malongfei'; # ")
        • 此时JDBC还没意识到安全问题,依旧将以上参数拼接到我们的SQL原语中,如下:

          select * from user where uid = 'malongfei' and passwd = '111' or '1' = '1';
          select * from user where uid = 'malongfei'; -- ' and passwd = '111' or '1' = '1';
          select * from user where uid = 'malongfei'; # ' and passwd = '111' or '1' = '1';
    • 预防SQL注入:使用PreparedStatement代替Statement可以有效防止SQL注入。

      • PreparedStatement利用预编译的机制将sql语句的主干和参数分别传输给数据库服务器,这样即使参数中携带数据库关键字,也不能作为SQL中真正的关键字而起作用。
      // 后端登录验证密码接口的SQL语句
      select * from user where uid = ? and passwd = ?;
      • 设置黑名单也可提前预防,单纯针对于用户输入中含有SQL关键字的拦截方法,比如在注册账号时,用户名和密码中不能含有SQL语句关键字;
      • 或者说在进行SQL拼接时加入逻辑处理,对传入参数含有SQL关键字的进行报输入异常。
    • PreparedStatementStatment 区别:

      1. 语法不同:PreparedStatement 使用预编译的sql,而 Statment 使用静态的sql
      2. 效率不同: PreparedStatement 具有 sql缓存区,效率比 Statment 高
      3. 安全性不同:PreparedStatement 可以有效防止sql注入,而 Statment 不能

    Mybatis对SQL注入的预防处理

    • 出现SQL注入问题的原因和上面一样,都是由于拼接SQL导致的,只不过方式不同。

      • Mybatis接收参数处理有两种语法:#{}${}#使用预编译,$使用拼接SQL方式。
      • 这里需要注意的是:使用#运算符,Mybatis会将传入的参数当成一个字符串,在进行变量替换时会加上引号!
    • mybatis 出现SQL注入实例:

      • 模糊查询时,如下实例:

        • 采用 #{} 的话程序会报异常。最后替换成 like "'name'"

          select * from users where name like '%#{name}%'
        • 常人看了既然#{}报错那么我用${},正中SQL注入的下怀,这个时候倘若我们的服务端 Java 代码没有对传入参数进行拦截处理,SQL注入条件满足!

          select * from users where name like '%${name}%'
        • 正确SQL写法,需要使用 concat函数 来进行连接参数(concat为mysql函数,连接参数产生字符串)

          select * from users where name like concat('%',#{name}, '%')
    • 补充:

      • in 之后的多个参数在mybatis中也不能采用 #{} 或者 ${} ,需要使用动态SQL语法中 foreach 循环遍历

        select * from users where id in
        <foreach collection="ids" item="item" open="("separatosr="," close=")">
        #{item}
        foreach>
      • order by 之后也不能使用 #{},他也会将字段改为字符串形式,加上引号后就不能正常排序,所以我们需要考虑 ${} 的方式,但是在后台代码中一定要进行数据参数的校验等手段,防止SQL注入.

  • 相关阅读:
    【机器学习】python机器学习使用scikit-learn对模型进行微调:按特征贡献大小保留最重要k个特征的transform
    计算机专业毕业设计演示视频(论文+系统)_kaic
    基于注解管理bean(功能分析、注解和扫描、扫描组件、bean的id)
    UE必学系列(基础篇完结)
    【QT】QT Designer控件随窗口大小自适应
    STM32 UART串口printf函数应用及浮点打印代码空间节省 (HAL)
    「小邓观点」你应该知道的 Windows LDAP 绑定安全漏洞
    SAP UI5 应用开发教程之一百零六 - 如何提高 SAP UI5 应用路由 url 的可读性试读版
    react:handleEdit={() => handleEdit(user)} 和 handleEdit={handleEdit(user)}有啥区别
    PHP Web 开发基础
  • 原文地址:https://www.cnblogs.com/malongfeistudy/p/16745900.html