时间戳

首页 > 解决方案 > 存储的 xss 安全威胁

java - 存储的 xss 安全威胁

问题描述

我们正在努力进行安全预防，并在下面的代码中buffer提供存储的 XSS 攻击......下面是我们从Checkmark工具获得的信息。

方法test从数据库中获取数据，用于buffer element. 然后，该元素的值在没有经过适当过滤或编码的情况下流经代码，最终在 method 中显示给用户test。这可能会启用存储的跨站点脚本攻击。

private void test(HttpServletResponse response, SessionInfo sessionInfo, String applicationName, String resourceName, String resourcePath, String domainAddress, String siteAddress, String fileNames) throws KatalystServletException, IOException, FSException
{
    InputStream in = resourceFile.getInputStream();
    ZipOutputStream zipOut = null;
    try {
        byte[] buffer = new byte[8 * 1024];
        int bytesRead = 0;
        while ((bytesRead = in.read(buffer)) != -1) {
            zipOut.write(buffer, 0, bytesRead);
        }
    } finally {
        in.close();
        zipOut.flush();
    }
}

标签： javasecurityxsscheckmarxsecure-coding

解决方案

这是该问题的解决方案，也是Checkmarx 在 Java 中标记的HRA_JAVA_CGI_STORED_XSS或存储的 XSS漏洞的解决方案。

对于使用 byte[] 数组作为缓冲区的任何 Java 文件操作，Checkmarx 都会标记此问题。

在写入任何输出流之前，您需要消毒您的手（悲伤的脸）以及您的字节数组。您可以使用 ESAPI 的验证器功能来解决此问题。

将 ESAPI jar 添加到您的项目中

   <dependency>
        <groupId>org.owasp.esapi</groupId>
        <artifactId>esapi</artifactId>
        <version>2.2.2.0</version>
    </dependency>

import org.owasp.esapi.*;

在写入 OutputStream 之前，在您的情况下是 ZipOutputStream 我们需要使用 getValidFileContent(String context,byte[] input, int maxBytes, boolean allowNull) 过滤字节数组缓冲区

此方法检查任何文件结尾漏洞、文件损坏攻击或其他入侵攻击（我找不到关于它们的太多信息，如果我找到更多信息会更新。）

https://javadoc.io/doc/org.owasp.esapi/esapi/2.2.2.0/org/owasp/esapi/Validator.html#getValidFileContent-java.lang.String-byte:A-int-boolean-

private void test(HttpServletResponse response, SessionInfo sessionInfo, String applicationName, String resourceName, String resourcePath, String domainAddress, String siteAddress, String fileNames) throws KatalystServletException, IOException, FSException
{
    InputStream in = resourceFile.getInputStream();
    ZipOutputStream zipOut = null;
    try {
        byte[] buffer = new byte[8 * 1024];
        int bytesRead = 0;
        while ((bytesRead = in.read(buffer)) != -1) {

      // HERE IS THE MAGIC LINE
      buffer=ESAPI.validator().getValidFileContent("blah blah",buffer,8192,true);
      //TADA

            zipOut.write(buffer, 0, bytesRead);
        }
    } finally {
        in.close();
        zipOut.flush();
    }
}

我在使用 Util 方法时遇到了类似的问题，它在 8 个地方被标记。在此修复后，所有问题均已解决。

我还建议使用 try catch finally 块并关闭“finally”部分中的 InputStreams 和 OutputStreams，或者您可以使用“Try with Resources”。

未关闭这些流在另一个 CodeScan 中被标记为“资源匮乏” - 未释放的资源可能导致系统速度变慢并导致其他内存组件饥饿。

推荐阅读