请求参数导致 prepared 语句的 SQL 注入

Request Parameter is causing SQL Injection with the preparedstatement

提问人:Juke 提问时间:6/4/2021 最后编辑:Juke 更新时间:6/4/2021 访问量:699

问:

我看到一个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”);

我能否知道如何避免在这里进行 sql 注入postal_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.

       
java sql spring 准备语句 sql 注入

评论

0赞 Juke 6/4/2021
我已经在编辑中删除了它,实际上“?
0赞 Juke 6/4/2021
我试过这种方式,它总是抱怨requestparams
0赞 astentx 6/4/2021
UPPER('?')实际上是一个带有问号的字符串文字,因此在您的情况下只有一个 bund 变量。不需要引号,因为它们表示字符串文字,但 bind 变量将其类型保留在其中
0赞 Juke 6/4/2021
是的,如果我将其设置为字符串作为 preparedstatement,为什么它会导致 SQL 注入,我在设置时是否需要添加更多内容?
0赞 John Bollinger 6/4/2021
请提供足够的代码来完整准确地描述您正在做的事情。至少,我们需要查看 、 的特定值,并结合所呈现的 Java 语句重现该问题,并且我们需要查看您得出注入正在发生的结论的依据。sqlcodevalue

答:

0赞 John Bollinger 6/4/2021 #1

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

如果您必须从用户输入中形成表达式的右手运算符(请考虑是否真的需要它),并且您不打算允许用户在该输入中使用 or 通配符作为通配符,那么您有一些替代方法。其中包括:LIKE%_

  1. 在服务器端验证参数以确保它不包含任何 OR 字符,如果包含,则拒绝它。理想情况下,还要执行客户端验证。%_

  2. 根据您正在使用的 DBMS 的相应语法,修改参数以转义出现的任何字符或字符。这很讨厌,因为它引入了 DBMS 依赖性,并且依赖于驱动程序和数据库不够聪明来识别您正在执行的操作(以免它逃脱转义)。这是使用预准备语句通常可以避免的那种混乱。value%_

  3. 确保应用程序可以安全地容纳提供包含 wilcards 的值的用户,以用作通配符,并告知漏洞扫描程序将其填充。