SQL交互通常是实际业务开发中业务系统中不可缺少的一部分。类似Mybatis、Hiberasae、

SpringDataJPA等等都提供在Java中，以满足有关数据库交互需求。但由于各种原因，SQL语

句在与应用程序和数据库展开交互时，往往会发生用字符串拼接的形式构建SQL语句的情况。

因此有时在面临大量接口存在SQL注入、迭代困难时，过滤器/拦截器是大多数开发人员的选

择，利用过滤有关的SQL关键字，防止SQL注入被进一步利用。

 

 

对于上面的场景，很多时候需要加检滤镜的设计是否严谨，是否存在漏网之鱼，导致SQL注

入漏洞被黑客利用。前段时间，在审计一个项目时，发现一个SQL注入导致了“越权”，下面

是有关流程。该系统的开发基于SpringMVC，业务主要与简历编辑有关。有关问题界面主要

在简历修改处。一般而言，这种企业修改个人信息，除了修改内容之外，主要传递两个重要

信息：

 

 

目前使用者的身份证明userId。目前使用者的商业编号(以下为简历),resumeId。当您请求接

口业务时，利用获取业务有关的关键参数userid提取当前客户的身份凭证(通常是session)，

关联个人用户身份，然后从前端获取需要修改的resumeId，最后在保存信息以展开SQL交

互时，利用会话在获取的userId与resumeId展开二次关联，确保userId对应的客户只能修改

自己的简历。下面是一个类似的SQL语句：有关代码：

 

 

首个Cantroller，在Cantroller层对客户的输入展开有关封装(这儿是简历的基本信息)，应用

自动关联的处理方法，将客户的输入直接关联到resume对象中，然后利用调用service的u

pdate方法来获取当前客户的update方法，然后利用当前登录会话获取当前客户的userId

，从而更新简历内容：因此整个简历更新过程如上所述，因为当您与SQL交互时，利用

update维护简历表，并利用userId和resumeId限定要更新的行。由于userId与客户会话关

联，因此客户只能更新自己的相应简历，从而防止越权问题。

 

但这里有SQL注入的风险，因为在Mybatis中应用$展开注解。然后再检查是否有有关的防

护措施。此处发现有关的过滤措施，应该是系统注入太多，所以开发了统一的利用过滤对

客户输入展开处理，检查过滤的具体实现。
 

相同的过滤器还会检查以下内容：

 

 

过滤次序获得数据的方法是否全面覆盖。规则内容筛选。此处包含两个过滤器，分别用于

xss和SQL注入的输入检测。由于所有恶意输入都是直接返回到通用报错页面，因此这儿

没有顺序问题导致的filter绕过。