管中窥豹——框架下的SQL注入 Java篇

管中窥豹——框架下的SQL注入 Java篇

背景

  • SQL注入漏洞应该算是很有年代感的漏洞了,但是现在依然活跃在各大漏洞榜单中,究其原因还是数据代码的问题。
  • SQL 语句在DBMS系统中作为表达式被解析,从存储的内容中取出相应的数据, 而在应用系统中只能作为数据进行处理
  • 各个数据库系统都或多或少的对标准的SQL语句进行了扩展
    • Oracle的PL/SQL
    • SQL Server的存储过程
    • Mysql也作了扩展(PS:不过我不知道这扩展叫什么名字
  • 既然问题很清楚是什么了,大佬们的解决方案也不会慢——预编译和ORM框架
    从我目前来感觉来看,就是封装,把你可能用到的语句封装起来,明确你数据的位置,再根据SQL语句的语法防止数据影响到真正的语义

ORM框架与预编译

预编译

  • 预编译的指令方式用起来多少有点繁琐,大部分都会采用相关的ORM框架来解决问题,但是多少需要了解,另外呢,再尝试编写sql的转义器的时候,我估计我还得读读这些底层的实现作为参考,原因嘛,自然是场景几乎一致,老司机的东西肯定比我拍脑袋的强(PS:实际上我需要的太简单了,预编译对不同类型均有不同的处理)。

    JAVA

// Java.sql 包
PreparedStatement preparedStatement=connection.prepareStatement("SELECT * FROM users WHERE name =?;"); // ?号为占位符,表示此处有输入的变量
preparedStatement.setString(1,name); // 通过set的方式设置变量

C

涉及的类,分别是sqlParameter、DataAdapter、

// 参考:https://www.cnblogs.com/wangwangwangMax/p/5551614.html
public string Getswhere() 
        {
            StringBuilder sb = new StringBuilder();
            sb.Append("select ID,username,PWD,loginname,qq,classname from Users  where 1=1");
            //获取到它的用户名
            string username = TxtUserName.Text.Trim();
            if (!string.IsNullOrEmpty(username))
            {
                //sb.Append(string.Format("and username='{0}'", username));
                //防SQL注入,通过@传参的方式
                sb.Append(string.Format("and username=@username"));
                //怎么把值传进去,通过sqlParameter数组
                //SqlParameter[] para = new SqlParameter[]
                //{
                //    //创建一个SqlParameter对象(第一个传名称,第二个传值)
                //    new SqlParameter("@username",username)
                //};
                // para[0]表示数组对象的第一个里面添加
                //para[0] = new SqlParameter("@username",username);
                 para.Add(new SqlParameter("@username", username));
            }
            if(ddlsclass.SelectedIndex>0)
            {
                //sb.Append(string.Format("and ClassName='{0}'", ddlsclass.SelectedValue));
                sb.Append(string.Format("and ClassName=@ClassName"));
                //para[1] = new SqlParameter("@ClassName",ddlsclass.SelectedValue);
                para.Add(new SqlParameter("@ClassName", ddlsclass.SelectedValue));
            }
            return sb.ToString();
        }

ORM框架

Java

  • Java下目前基本上都是采用了mybatis框架进行处理了吧,反正我目前接触到的都是这个。

    mybatis
  • 在java代码调用mapper的方法,实现数据库查询,框架将查询的结果映射到xml文件中配置的结果集上,详细的底层原理可以查看图片下方的原文链接。
    管中窥豹——框架下的SQL注入 Java篇_第1张图片

    参考:https://blog.csdn.net/luanlouis/article/details/40422941

  • 当然除了xml配置文件的方式,还支持注解,不过目前接触到的主流都是xml,偶尔有在代码中看到几行简单查询的注解。
    一般而言${}表示动态拼接——容易导致SQL注入,#{}表示参数绑定——不会导致SQL注入 (后文会尝试从mybatis框架上看看到底什么区别)
  • xml文件一个个去写,其实也是蛮大的工作量,当然大佬们已经想到这个问题了,基本上都会采用相关的插件来生成一个能满足基本需求的xml文件、mapper类以及实体类(处理输入和输出)
    目前我接触到的有两个
    • mybatis-generator (maven的插件)
    • idea mybatis-generator (idea的插件)
  • mybatis-generator (maven的插件)
  • 需要配置 generatorConfig.xml (包含了jdbc的账号和密码,一般会放在resouces目录下)
    PS: 可以关注的信息泄露的点
  • 生成的实体类包括 tableName 和tableNameExample
    tableNameExample作为查询的条件输入类,tableName主要用于结果输出类,两者在功能上做了分离
 /**
     * This method was generated by MyBatis Generator.
     * This method corresponds to the database table asset_group
     *
     * @mbg.generated Fri Aug 10 18:44:32 CST 2018
     */
    List selectByExample(AssetGroupExample example);

    /**
     * This method was generated by MyBatis Generator.
     * This method corresponds to the database table asset_group
     *
     * @mbg.generated Fri Aug 10 18:44:32 CST 2018
     */
    AssetGroup selectByPrimaryKey(Integer id);
  • tableNameExample作为条件的实现,依赖了动态参数(字段名动态), 下文会探讨这样做会不会有什么问题
    
      
        
          
            
              
                
                  and ${criterion.condition}
                
                
                  and ${criterion.condition} #{criterion.value}
                
                
                  and ${criterion.condition} #{criterion.value} and #{criterion.secondValue}
                
                
                  and ${criterion.condition}
                  
                    #{listItem}
                  
                
              
            
          
        
      
    
idea mybatis-generator (idea的插件)
  • idea是商用的IDE,我先放个图看看
    管中窥豹——框架下的SQL注入 Java篇_第2张图片

  • 与上文的不同,该插件生成的实体类只有两个,但是mapper和xml均生成了两组,有继承关系
tableNameBaseMapper 和 tableNameMapper  

(代码里没有体现,实现在使用的时候有,新增的sql语句可以放到tableNameMapper里,看起来比较清爽,点开basemapper对应的xml文件就知道了)

  • 实体类中封装了内部类,用于构造复杂的查询条件
    管中窥豹——框架下的SQL注入 Java篇_第3张图片

  • xml文件也写的完全不一样,因为没有采用动态的方式,所以每个xml都很大。 估计设计上分离就是因为这个原因,如果也在这个文件里,可能会找不到...

            
            
                `ID` = #{ID} and
            
            
            
                
                    `ID` in
                    
                        #{item}
                     and
                
            
                
                    (
                    
                        `NAME` like concat('%',#{item},'%')
                    
                    ) and
                
                
                    (
                    
                        `NAME` like concat(#{item},'%')
                    
                    ) and
                
               
                
                    `CREATE_TIME` >= #{cREATETIMESt} and
                
                
                    `CREATE_TIME` <= #{cREATETIMEEd} and
                
            
        
  • mapper里封装的方法
    默认生成的以[query|update]{EntityName}[Limit1]? 以及query|update构成的方法名称

python

  • django 自带的ORM框架
  • Flask flask_sqlalchemy

    C

  • 简单搜了下花样比较多...就不写了

mybatis框架解析原理

  • SqlSessionFactoryBuilder.build 入口
    • 生成DefaultSqlSessionFactory ,调用xmlconfigbuilder进行初始化
    • XMLConfigBuilder (org.apache.ibatis.builder.xml)
      • 负责解析mapper的配置文件,其中mapperParser.parse();函数会对配置的主体部分(sql语句、mapper节点下的内容)进行解析
      • 解析完成后,将Sql节点存放到 Map sqlFragments 结构上;
      • 进一步的解析调用buildStatementFromContext进一步解析
      • 最终生成了MappedStatement存储在configuration对象中
  • 调用SqlSessionFactory.opensession,默认生成DefaultSqlSession,调用其方法进行查询等操作

    MappedStatement ms = configuration.getMappedStatement(statement); // 取出之前生成的mappedstatement
        return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER); // 调用执行器,执行  默认将parameter封装成数组, 其他根据其类型支持collection 和 list
        // 执行器最终会调用preparestatement 通过预编译完成
    • MappedStatement的getBoundSql方法
    DynamicContext context = new DynamicContext(configuration, parameterObject); // 包装输入的参数parameterObject
     rootSqlNode.apply(context); // 实际上在这个阶段完成SQL预计动态拼接的,同时会调用OGNL表达式获取相关值,根据不同类型的SQLNode不同的拼接方式,文本是直接添加,其他的部分可能调用ognl表达式获取值
    // ....
    SqlSource sqlSource = sqlSourceParser.parse(context.getSql(), parameterType, context.getBindings()); // 参数拼接的函数
    • #{}类型 -> 转化调用java的预编译
    // parse(...) #{}形式的参数处理,
     GenericTokenParser parser = new GenericTokenParser("#{", "}", handler);
         /*
      转化成固定的返回 ?  用于预编译 
      */
      String sql = parser.parse(originalSql);
      return new StaticSqlSource(configuration, sql, handler.getParameterMappings());
    
    
    // Class: GenericTokenParser
    // parse(String)
    public String parse(String text) {
      if (text == null || text.isEmpty()) {
        return "";
      }
      // search open token
      int start = text.indexOf(openToken, 0);
      // ..... 
      while (start > -1) {
        if (start > 0 && src[start - 1] == '\\') {
          // this open token is escaped. remove the backslash and continue. 如果存在反斜杠的转义自动掠过
          // ..
        } else {
          // found open token. let's search close token.
          if (expression == null) {
            expression = new StringBuilder();  // 实际上就是处理完一些特殊符号后#{}中间的内容
          } else {
            expression.setLength(0);
          }
          builder.append(src, offset, start - offset);
          offset = start + openToken.length();
          int end = text.indexOf(closeToken, offset);
          while (end > -1) {
            if (end > offset && src[end - 1] == '\\') {
              // this close token is escaped. remove the backslash and continue.   如果存在反斜杠的转义自动掠过
              // .....
          }
          if (end == -1) {
            // close token was not found.  
            builder.append(src, start, src.length - start);
            offset = src.length;
          } else {
            /*
              转化成固定的返回 ?  用于预编译
             // SqlSourceBuilder
              public String handleToken(String content) {
              parameterMappings.add(buildParameterMapping(content));
              return "?";
              }
    
              根据之前声明的参数类型映射prepare相应的set函数,例如setString
            */
            builder.append(handler.handleToken(expression.toString()));
            offset = end + closeToken.length();
          }
        }
        start = text.indexOf(openToken, offset);
      }
      if (offset < src.length) {
        builder.append(src, offset, src.length - offset);
      }
      return builder.toString();
    }
    
    // // \t\n\r\f 会被替换成空格,重构sql语句
    //  org.apache.ibatis.executor.statement
    // class: PreparedStatementHandler : instantiateStatement(connection)
     String sql = boundSql.getSql();
      if (mappedStatement.getKeyGenerator() instanceof Jdbc3KeyGenerator) {
        String[] keyColumnNames = mappedStatement.getKeyColumns();
        if (keyColumnNames == null) {
          return connection.prepareStatement(sql, PreparedStatement.RETURN_GENERATED_KEYS);
        } else {
          return connection.prepareStatement(sql, keyColumnNames);
        }
      } else if (mappedStatement.getResultSetType() != null) {
        return connection.prepareStatement(sql, mappedStatement.getResultSetType().getValue(), ResultSet.CONCUR_READ_ONLY);
      } else {
        return connection.prepareStatement(sql);  // jdbc的预编译
      }

    PS: 后续有时间再去了解底层的实现。

常见的安全问题

信息泄露/拒绝服务风险

  • 提供空值或者空的对象,导致查询空值条件失效,实现了全库查询,可能造成信息泄露或者DOS风险。
    • idea生成的例子如下:
     
                  `ID` = #{ID} and
              
    
    • maven generator插件生成的代码由于没有强制的判定,似乎不会造成该风险(仅限select语句)
  • SQL注入风险

  • #{}采用了jdbc的预编译不存在风险,但是${}在构建语句的过程是需要进行表达式的计算的是动态拼接到语句中,如果直接采用这种方式存在SQL注入的风险。
  • 在预编译中各个类型都有相应的set函数,还有一些的函数,例如setInternal, 对于输入的变量不做任何处理,如果直接拼接了变量到其中也会存在相应的安全风险
  • 对于maven上的generator插件而言,生成的mapper.xml大致如下:
  • 其中 order by就存在注入的风险,语句如下:
    • mysql 如下:
    IF(1=1,1,(select+1+from+information_schema.tables))
    updatexml(1,if(1=1,1,user()),1)
    (CASE+WHEN+(1=1)+THEN+name+ELSE+price+END)
    • oracle如下:
    CASE WHEN (ASCII(SUBSTRC((SELECT NVL(CAST(USER AS VARCHAR(4000)),CHR(32)) FROM DUAL),3,1))>96) THEN DBMS_PIPE.RECEIVE_MESSAGE(CHR(71)||CHR(106)||CHR(72)||CHR(73),1) ELSE 7238 END) 
    
    order by CASE WHEN 1=1 THEN 1 ELSE 0 END DESC
    • mssql:
      • https://github.com/incredibleindishell/exploit-code-by-me/blob/master/MSSQL%20Error-Based%20SQL%20Injection%20Order%20by%20clause/Error%20based%20SQL%20Injection%20in%20%E2%80%9COrder%20By%E2%80%9D%20clause%20(MSSQL).pdf
  • 另外还有一处如下:

    
    
      
        
          
            
              
                
                
                  and ${criterion.condition}
                
                
                  and ${criterion.condition} #{criterion.value}
                
                
                  and ${criterion.condition} #{criterion.value} and #{criterion.secondValue}
                
                
                  and ${criterion.condition}
                  
                    #{listItem}
                  
                
              
            
          
        
      
    
  

不过生成的相关example类的时候已经封装了各种方法,只要不去直接调用addCriterion去尝试对字段名(函数的第一个参数)进行动态设置,不存在安全风险,如下:


        public Criteria andIdIsNull() {
            addCriterion("ID is null");
            return (Criteria) this;
        }

        public Criteria andIdIsNotNull() {
            addCriterion("ID is not null");
            return (Criteria) this;
        }

        public Criteria andIdEqualTo(Integer value) {
            addCriterion("ID =", value, "id");
            return (Criteria) this;
        }

        public Criteria andIdNotEqualTo(Integer value) {
            addCriterion("ID <>", value, "id");
            return (Criteria) this;
        }

        public Criteria andIdGreaterThan(Integer value) {
            addCriterion("ID >", value, "id");
            return (Criteria) this;
        }
  • idea的generator插件生成的mapper中不存在注入的风险,但是也没有提供order by的封装,可能会需要人工去编写相关的语句,在此时就要关注可能存在的注入风险。

删库风险

  • 与第一条可能比较像,但是风险不太一样,单独拉了一条。
  • 我们看generator插件生成的xml文件中关于delete方法的声明(PS:idea生成的mapper中没有关于delete方法的声明)

    
    delete from vulnerability_details
    
      
    
  
  • _parameter是mybatis的内置变量,代表整个输入的对象,如果对象为null,就会造成删库,但是貌似这种情况条件有一点苛刻。
  • 不过对于目前的应用系统而言,delete方式应该处于被弃用的状态,除了针对账号注销的这类场景。

OGNL引入可能带入的后门问题

  • 在mybatis的框架中动态参数实际上是采用OGNL表达式进行处理
package org.apache.ibatis.ognl
  • 通过getValue定位的相关函数如下:
    管中窥豹——框架下的SQL注入 Java篇_第4张图片

  • 那么可知支持OGNL表达式有以下这些标签或者属性:
    • if/when标签的test属性
    • foreach标签的collection属性
    • #{}或者${}中间的变量部分
    • bind标签的value属性(由name和value组成的变量会注入到context中)

    • 注: 参考以下动态节点对应的相关类
      map.put("trim", new TrimHandler());
      map.put("where", new WhereHandler());
      map.put("set", new SetHandler());
      map.put("foreach", new ForEachHandler());
      map.put("if", new IfHandler());
      map.put("choose", new ChooseHandler());
      map.put("when", new IfHandler());
      map.put("otherwise", new OtherwiseHandler());
      map.put("bind", new BindHandler());
      handleToken,方法
  • 尝试过程
    • 选择以下payload进行尝试
      @java.lang.Runtime@getRuntime().exec('calc')
    • 在相关位置添加OGNL表达式后测试以下几点
      1. 在加载配置时能否触发代码
      2. 在执行语句的能否触发代码
      3. 在已经启用的应用程序中动态插入能否触发代码(PS:实际测试过程均不行,但是针对不同应用场景下,可能存在热加载的问题)
    • if/when标签的test属性
      • 情况1 触发代码
      • 情况2 触发代码
      • 情况3 无法触发
      • PS: when标签放在默认语句的最后一行无法触发,但是第一行却可被触发
    • foreach标签的collection属性
      • 情况1 触发代码
      • 情况2 触发代码
      • 情况3 无法触发
      • PS: 由于返回的对象不一定是一个iterable,日志中会有相关的错误提示。影响正常请求的访问
    • bind标签的value属性
      • 情况1 触发代码
      • 情况2 触发代码
      • 情况3 无法触发
    • #{}或者${} PS: #{}无法触发 (会调用get/set方法,没有使用ognl)
      • 情况1 触发代码
      • 情况2 触发代码
      • 情况3 无法触发
    • 补充测试,在原来目录下直接添加一个mapper文件查看,是否会被加载
      • 不会自动加载

解决方案

  • 通用情况
    • 对数据进行非空、非null的判断,避免一些条件被规避
    • 框架有些地方没办法转换成相应合适的预编译,有条件还是需要去配置一个全局的过滤器
  • 针对idea的生成器
    • 需要对条件进行分析,哪些的必要条件,哪些不是。必要条件必须对空值和null值判断,可以去修正自动生成的mapper
  • 针对maven插件的生成器
    • 避免直接调用addCriterion函数,第一个参数避免由外部输入,如果有必要可以通过枚举类结合switch case控制
    • orderByClause属性设置时,注意避免外部输入。如果有必要进行动态设置。那么需要采用枚举类结合switch case控制或者对输入的数据进行过滤,仅保留字母数字下划线逗号,至于递增还是递减的控制,通过switch case 控制后拼接字符串常量。
  • 后门问题
    • 框架实现的机制,没有办法修复。

总结

  • mybatis的框架梳理的还比较乱,有机会再理理。

参考

  • Mybatis解析动态sql原理分析.

你可能感兴趣的:(管中窥豹——框架下的SQL注入 Java篇)