请求参数导致SQL注入带有准备好的语句

Question

我看到一个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注入吗？我看到代码参数没有从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.

Answer 1

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

如果您必须根据用户输入形成LIKE表达式的右侧运算符(请考虑是否确实需要(，并且您不打算允许用户将该输入中的%或_通配符用作通配符，那么您有一些替代方案。其中包括：

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

2. 根据所使用DBMS的适当语法，使用value参数来转义出现的任何%或_字符。这是令人讨厌的，因为它引入了DBMS依赖性，并依赖于驱动程序和数据库不够聪明，无法识别您正在做的事情(以免它逃脱转义(。这是使用事先准备好的语句通常可以避免的混乱。

3. 确保应用程序能够安全地容纳用户提供的值包含wilcards，用作通配符，并告诉您的漏洞扫描程序填充它。