不带PreparedStatements标准API的SQL转义

问题描述

我必须转义参数以避免sql注入问题。我有一个很大的CriteriaBuilder sql,可以在其中找到下一个

Expression<Integer> containsFunction = cb.function("CONTAINS",Integer.class,joinParty.get(MyEntity_.name),cb.literal(sb.toString())
);

此“ sb”是sqli所在的StringBuilder。无论如何,在此“ DEFINEMERGE”歌剧中有一个不常见的句子(对我来说是未知的),它带有以下自变量:

StringBuilder sb = new StringBuilder("DEFINEMERGE(((NEAR((");
for (int i = 0; i < nameValues.length; i++) {
    sb.append("{").append(nameValues[i]).append("}");
    if(i + 1 < nameValues.length) {
        sb.append(",");
    }
}
sb.append("),0)),(").append(nameValues[0]).append(" AND {").append(nameValues[1]).append("})");
if(nameValues.length > 3) {
    sb.append(",(").append(nameValues[1]).append(" AND {").append(nameValues[2]).append("})");
    if(nameValues.length == 4) {
        sb.append(",(").append(nameValues[2]).append(" AND {").append(nameValues[3]).append("})");
    }
}
sb.append("),AND,MIN)");

问题在于,某些nameValue的内部带有“(”,这会破坏sql在这种情况下,我不确定什么是最佳化此值的最佳方法,因为此CONTAINS使用sql String文字而不是条件对象。

这是预期的生成sql

CONTAINS(
    table.name,'DEFINEMERGE (
        (
            (NEAR( (?,{?},{?}),FALSE)),(? AND {?} and {?})
        ),min 
    )',1
)

这是生成查询的示例(为公司隐私和安全起见,表和字段的隐藏真实名称)也具有参数bind数组:

SELECT 
    COUNT(t0.<VALUE>) 
FROM 
    SCHEME.<TABLE_NAME> t0 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t2 ON (t2.<VALUE> = t0.<VALUE>) 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t6 ON (t6.<VALUE> = t2.<VALUE>) 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t7 ON (t7.<VALUE> = t6.<VALUE>) 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t8 ON (t8.<VALUE> = t7.<VALUE>) 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t3 ON (t3.<VALUE> = t2.<VALUE>) 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t4 ON (t4.<VALUE> = t3.<VALUE>) 
    LEFT OUTER JOIN SCHEME.<TABLE_NAME> t5 ON (t5.<VALUE> = t4.<VALUE>),SCHEME.<TABLE_NAME> t11,SCHEME.<TABLE_NAME> t10,SCHEME.<TABLE_NAME> t9,SCHEME.<TABLE_NAME> t1 
WHERE 
    ((((((((((((((((t0.<VALUE> IN (?)) AND (t0.<VALUE> IN (?))) AND (t6.<VALUE> = ?)) AND (t3.<VALUE> IN (?))) AND ((t2.<VALUE> IS NULL) OR (t2.<VALUE> = t9.<VALUE>))) AND (t0.<VALUE> = ?)) AND (CONTAINS(t1.<VALUE>,?) > ?)) AND (t0.<VALUE> IN (?))) AND (t1.<VALUE> = ?)) AND t0.<VALUE> IN (SELECT t12.<VALUE> FROM SCHEME.<TABLE> t14 LEFT OUTER JOIN SCHEME.<TABLE> t16 ON (t16.<VALUE> = t14.<VALUE>),SCHEME.<TABLE> t13,SCHEME.<TABLE> t12,SCHEME.<TABLE> t15 WHERE ((((((t13.<VALUE> IN (?)) AND (t14.<VALUE> IN (?))) AND (t14.<VALUE> <= ?)) AND ((t14.<VALUE> IS NULL) OR (t14.<VALUE> >= ?))) AND (t16.<VALUE> = ?)) AND (((t14.<VALUE> = t13.<VALUE>) AND (t12.<VALUE> = t13.<VALUE>)) AND (t15.<VALUE> = t14.<VALUE>))))) AND (t9.<VALUE> IN (?))) AND (t11.<VALUE> IN (?))) AND (t0.<VALUE> = t11.<VALUE>)) AND (t9.<VALUE> <= ?)) AND ((t9.<VALUE> IS NULL) OR (t9.PARO_DA_END_VALIDITY >= ?))) AND (((t9.<VALUE> = t0.<VALUE>) AND (t1.<VALUE> = t0.<VALUE>)) AND (t10.<VALUE> = t9.ROTY_ID_ENGAGED_ROLE_SPEC)))

    bind => [1,INDI,1,DEFINEMERGE(((NEAR(({(name},{name)}),((name AND {name)})),MIN),2020-09-07 00:00:00.0,2020-09-07 00:00:00.0]

解决方法

不幸的是,没有保证可以逃脱SQL的方法,因为确实没有'SQL'这样的东西。有方言,这是正确逃避工作所需的信息。那么,您想逃避什么? “ SQL”不是一个可行的答案。可行的答案是“ postgres的SQL”,“ MySQL的SQL”,“ Oracle的SQL”等。SQL更像是一个概念,而不是直接的规范(虽然有实际的规范,但它包含的内容比您想象的要少得多,并且每一项SQL方言打破了规范,并为其添加了很多内容。

这就是为什么通常的建议是:真的,不,您不能做您想做的,如果想逃避这些事情,必须通过.setX上的PreparedStatement方法来进行。

从您的问题看来,您的数据库中似乎有实际的SQL语句作为字符串文字,这本身就是一个奇怪的情况,并且很容易导致严重的安全问题,因此虽然您可能不想听到它,此设计需要彻底的修改,而且听起来其他代码会抢占此SQL,然后逐字运行它。

Java有一会儿这样的事情(eval),并且由于eval是一件令人震惊的事情,因此发生了大量的安全漏洞。现在还存在使用标头禁止网站上javascript中的eval的方法,浏览器会处理其中出现的URL中的位,这很糟糕-现代安全准则要求您完全禁用此功能,而您不能如果需要,可以真正依靠它来正常工作。

鉴于手动转义SQL是个坏主意,我怀疑那里有没有可用的库。您的JDBC驱动程序(可以钻研那些类并检查网站!)很有可能具有实用程序的方法;鉴于每种方言都有不同的规则,这很有意义:每个SQL引擎都有不同的JDBC驱动程序。显然,如果您的JDBC驱动程序附带了SQL转义工具,则它是该特定引擎的正确选择。

如果找不到,在大多数SQL方言中转义的最简单方法是将允许的字符列入白名单,并对不在白名单中的每个字符进行转义。白名单应该只包含绝对,绝对安全的内容(az,0-9,也许是_,-。列表中应该没有看起来像是引号或反斜杠的内容,而我避免使用$只是因为它通常用于变量替换,这在SQL中不是问题,但是比您的生产服务器拥有更好的安全性。

其余的可以逃脱。例如,在postgres中,您将输入以下字符串:

Joe's bar & Grill

进入

E'Joe\u0027s bar \u0026 Grill'

E的意思是:带转义符的字符串。该算法检查每个字符并复制到白名单上的所有内容。引号和&符不在上面,所以它们被\u0000代替,其中零是字符的十六进制编码(s.charAt(i)的值,转换为整数,打印为十六进制数字) >

这应该涵盖了您的所有基础,但是请注意,(叹气)转义字符串完全不属于SQL规范,这是事后证明。