Java 配置esapi以缓解XSS SQLI{GET/POST data}的完美方法

我们有一个jaxrs服务，不幸的是执行了原始查询，没有准备好的语句。我们使用ESAPI来缓解XSS、SQLI。如下所示：

private String mitigateSQLI(String value) {

        Encoder instance = ESAPI.encoder();
        Codec c = new MySQLCodec(MySQLCodec.Mode.ANSI);

        return instance.encodeForSQL(c, value);
    }

    private String mitigateXSS(String value) {
        if (value == null)
            return null;

        // Use the ESAPI library to avoid encoded attacks.
        value = ESAPI.encoder().canonicalize(value);

        // Avoid null characters
        value = value.replaceAll("\0", "");

        // Clean out HTML
        Document.OutputSettings outputSettings = new Document.OutputSettings();
        outputSettings.escapeMode(EscapeMode.xhtml);
        outputSettings.prettyPrint(false);
        value = Jsoup.clean(value, "", Whitelist.none(), outputSettings);

        return value;
    }

以及带有默认配置的ESAPI.properties文件

尽管如此，我们仍然在某些场景中面临SQLI，因为我们知道查询是连接和形成的

---

想知道缓解这些问题的最佳方式/配置。方法可以是ESAPI属性或这些ESAPI可用的方法。

需要注意的是，ESAPI的SQLi编解码器的设计意图是在妥协后的场景中提供紧急支持，以便为您赢得时间，用

PreparedStatement

或类似的语句重写易受攻击的查询。OWASP不能保证，因为各种RDBMS实现中存在的特殊语言怪癖通常不是公共知识。并不是说ESAPI根本不会保护您——但它永远不会像

PreparedStatement

那样好。我只希望得到部分缓解

---

我还建议不要使用Jsoup代替

Validator.getValidSafeHTML（）

。Jsoup将尝试“纠正”无效的HTML，而在输入验证和安全HTML的上下文中，这会变得非常复杂

不要逃避选择。如表中以粗体引用的

主要防御：

• 选项1：使用准备好的语句（带参数化查询）
• 选项2：使用存储过程
• 选项3:白名单输入验证
• 选项4:转义所有用户提供的输入

附加防御：

• 另外：强制执行最低特权
• 另外：执行白名单输入验证作为次要防御

---

根据应用程序需求配置ESAPI.properties非常重要。当不使用Prepared语句时，必须在服务器端转义输入。对于Java，Apache的StringEscapeUtils完成了这项工作。

谢谢，ESAPI是否可以处理POST请求？例如，JSON作为POST数据。@Manasi ESAPI验证输入字符串的GET或POST。我假设您一定创建了HTTP拦截器来捕获GET/POST数据。离开拦截器和/或servlent filters@Manasi，安全问题在该级别上是无法解决的！您的答案应该是公认的答案，并且来自ESAPI的一位共同领导。ESAPI的SQL编解码器（全部）只是权宜之计。我宁愿删除我的答案，因为我没有看到你的答案，但这取决于你。我想我的答案和你的答案是一致的！