20221106日常记录-奇安信源代码扫描代码注入、海豚调度2.0.5-condition节点使用

奇安信的扫描，真是无力吐槽，没问题的也能扫描出来，按照修复建议修复完也没效果…

SQL注入

SQL注入是一种数据库攻击手段。攻击者通过向应用程序提交恶意代码来改变原SQL语句的含义，进而执行任意SQL命令，达到入侵数据库乃至操作系统的目的。在Mybatis Mapper Xml中，#变量名称创建参数化查询SQL语句,不会导致SQL注入。而$变量名称直接使用SQL指令，会导致SQL注入攻击。

例如：以下代码片段采用$变量名称动态地构造并执行了SQL查询。

<!--select user information by name-->
<select id="queryByUserName" resultMap="userResultMap" parameterType="String">
    select * from db_user where user_name=${username}
</select>
1
2
3
4

用户调用以下命令时：

String username = request.getParameter("name");
user.queryByUserName(username);
1
2

如果攻击者能够替代username中的任意字符串，它们可以使用下面的关于username的字符串进行SQL注入,‘Tom’ OR ‘1’='1
当其注入到命令时，命令就会变成：select * from db_user where user_name ='Tom' OR '1'='1'

调度的传参是没问题的，不知道为什么会被扫描出来：

直接提交为不是问题：

Mybatis 变量传参

• # :会把传入的数据都当成一个字符串来处理，会在传入的数据上面加一个双引号来处理，一般用于前端输入，防止sql注入
• $: 则是把传入的数据直接显示在sql语句中，不会添加双引号。一般用于固定的值，比如后台拼接固定的表名等

海豚调度2.0.5 condition

最近业务提了个问题比如A->B->C,任务A失败的时候，希望工作流的状态为成功，乍一听感觉要求很无礼呀，当然最终还是被业务说服了，大概场景就是，就是任务A失败时候可能就是没数据而已，是正常的，对业务没什么影响，只有当有数据时候能A->B->C依次执行就行了，所以不希望整个工作流实例是失败状态。
首先就想到了condition节点，可以根据上游节点状态，决定成功执行哪一个分支，失败执行哪一个分支，这个地方还有个坑，不管成功失败都会执行成功的分支，解决方法就是，不管前置任务有几个，自定义参数都不能为空，必须定义一下。算是一个可以的优化的点，前置任务一个的时候，成功就是成功，不存在相互组合（比a成功且b失败视为成功）

跨站脚本

这个也挺头疼，首先请求已经做了拦截，不会有跨站脚本风险，后端返回数据呢？比如返回不合适的数据格式，前端都校验过了，数据库怎么还会有不合适的数据呢？当然处于安全考虑，返回前端的数据，做一下过滤也不是不可以，问题是过滤完，只有一部分不再被扫描到。
类型: 安全缺陷

反射型XSS是指应用程序通过Web请求获取不可信赖的数据，并在未检验数据是否存在恶意代码的情况下，将其发送给用户。反射型XSS一般可以由攻击者构造带有恶意代码参数的URL来实现，在构造的URL地址被打开后，其中包含的恶意代码参数被浏览器解析和执行。这种攻击的特点是非持久化，必须用户点击包含恶意代码参数的链接时才会触发。

例如：下面JSP代码片段的功能是从HTTP请求中读取输入的用户名(username)并显示到页面。

<%
String name= request.getParameter("username"); %>
...
姓名: <%= name%>
...
1
2
3
4
5

如果name里有包含恶意代码，那么Web浏览器就会像显示HTTP响应那样执行该代码，应用程序将受到反射型XSS攻击。

存储型XSS是指应用程序通过Web请求获取不可信赖的数据，并且在未检验数据是否存在XSS代码的情况下，将其存入数据库。当程序下一次从数据库中获取该数据时，致使页面再次执行XSS代码。存储型XSS可以持续攻击用户，在用户提交了包含XSS代码的数据存储到数据库后，每当用户在浏览网页查询对应数据库中的数据时，那些包含XSS代码的数据就会在服务器解析并加载，当浏览器读到XSS代码后，会当做正常的HTML和JS解析并执行，于是发生存储型XSS攻击。

例如：下面JSP代码片段的功能是根据一个已知用户雇员ID（id）从数据库中查询出该用户的地址，并显示在JSP页面上。

<%
...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from users where id =" + id);
String address = null;
if (rs != null) {
    rs.next();
    address = rs.getString("address");
}
%>
家庭地址: <%= address %>
1
2
3
4
5
6
7
8
9
10
11

如果address的值是由用户提供的，且存入数据库时没有进行合理的校验，那么攻击者就可以利用上面的代码进行存储型XSS攻击。

调度代码都是returnDataList返回值这一块没有校验，进入returnDataList，添加校验

一定进入到最底层进行校验，否则无效，但是加完之后，还是有很多会被扫描出来，明天再试试看，或者有解决经验的欢迎讨论

20221108 更新：XSS处理在确保不存在风险并且没有管理员权限设置方法白名单又不想一个一个提交审计没有问题的情况下，可以通过伪代码通过扫描，一般写两层方法就可以了，至于有何意义…