请求参数导致使用preparedstatement的SQL注入答案

【问题标题】：Request Parameter is causing SQL Injection with the preparedstatement请求参数导致使用preparedstatement的SQL注入
【发布时间】：2021-08-21 22:23:37
【问题描述】：

我看到了一个 SQL 注入

SELECT count(id) FROM user  WHERE code= 67 AND user.postal_code like  UPPER('%AL%')

我将其设置为

 private int loaddGrantees(Long code, String value)
    {
     DBConnectionManager dBConnectionManager = null;
     Connection conn = null;
     PreparedStatement pstmt = null;
     ResultSet rs = null;
     dBConnectionManager = new DBConnectionManager();
     conn = dBConnectionManager.getConnectionObject(XXX,XXX);
     string sql =  SELECT count(id) FROM user  WHERE code= ? AND user.postal_code LIKE UPPER(?);
      pstmt = conn.prepareStatement(sql);
      pstmt.setLong(1, code);
      pstmt.setString(2, "%" +value+ "%");
       rs = pstmt.executeQuery();
            while (rs.next()) {
                 number = rs.getInt(1);
             }
     return number;
}

从 HTTPRequest 我看到值来自 String value= request.getParameter("Val");

我可以知道如何避免这里为 postal_code 注入 sql，我看到 code 参数没有从 httpRequest 中检索到

> Vulnerability says:
> 
> /XX/XX/XXX/XX/XX/6769/XX/AL/XX page of the application has been found
> to be vulnerable to a SQL Injection attack in the path parameter
> :value.
> 
> The source code that uses this path parameter in the page is:
> 
> loadGrantees(Person.java:5036)
> org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery();
> 
>     ...   }   ... }
> 
> This code has generated the following query in order to interact with
> the database, using the path parameter value: Note: AL represents the
> value which I am passing in the preparedstatement
> 
> SELECT count(id) FROM user  WHERE code= ? AND user.postal_code LIKE
> UPPER(?); The path parameter searchString in the URL
> /XX/XX/XXX/XX/XX/6769/XX/AL/XX can be modified to contain SQL syntax
> hence changing the query structure, causing unexpected application
> behavior which could lead to information theft, privileges escalation
> and unauthorized actions performed by the attacker.

【问题讨论】：

我已在编辑中删除它实际上“？”周围没有单引号
我试过这样它总是抱怨 requestparams
UPPER('?') 实际上是一个带问号的字符串文字，因此您的案例中只有一个 bund 变量。不需要引号，因为它们表示字符串文字，但绑定变量将其类型保留在其中
是的，如果我将它设置为字符串作为preparedstatement 仍然为什么它会导致SQL 注入我需要在设置时添加更多内容吗？
请提供足够的代码来完整准确地描述您正在做的事情。至少，我们需要查看sql、code 和value 的特定值，这些值与所提供的Java 语句一起重现了该问题，并且我们需要查看您得出正在发生注入的结论的基础。

标签： java sql spring prepared-statement sql-injection

【解决方案1】：

漏洞报告似乎在抱怨用户指定的value 参数包含% 或_ 字符的可能性，这将被LIKE 运算符解释为通配符而不是文字。如果这不是故意的，那么它可能确实为恶意用户提供了造成伤害的机会，或者至少可以提取您不打算让他们获取的数据，但这不是传统意义上的代码注入。（强制性 XKCD：https://xkcd.com/327/）

如果您必须从用户输入形成LIKE 表达式的右手运算符（请考虑您是否真的需要），并且您不打算允许用户使用% 或_ as 通配符中的通配符，那么你有几个选择。其中包括：

在服务器端验证参数以确保它不包含任何% 或_ 字符，如果包含则拒绝它。理想情况下，也执行客户端验证。
根据您使用的 DBMS 的适当语法，使用 value 参数转义出现的任何 % 或 _ 字符。这很讨厌，因为它引入了 DBMS 依赖性，并且依赖于驱动程序和数据库不够聪明，无法识别您在做什么（以免它逃脱转义）。这是使用准备好的语句通常可以避免的那种混乱。
确保应用程序可以安全地容纳提供包含通配符的值的用户，用作通配符，并告诉您的漏洞扫描程序填充它。

【讨论】：