存储的xss安全威胁

如何解决存储的xss安全威胁

我们正在致力于安全防护，下面的代码buffer正在发出存储的XSS攻击...下面是我们从 checkmark 工具获得的信息。

方法test从数据库中为buffer element获取数据。然后，该元素的值会在代码中流过，而没有经过适当的过滤或编码，最终会以方法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,bytesRead);
        }
    } finally {
        in.close();
        zipOut.flush();
    }
}

解决方法

这里是问题的解决方案，也适用于 HRA_JAVA_CGI_STORED_XSS 或 Stored XSS 由 Checkmarx 在 Java 中标记的漏洞。

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

在写入任何输出流之前，您需要清理双手（悲伤的脸）和字节数组。您可以使用 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,bytesRead);
        }
    } finally {
        in.close();
        zipOut.flush();
    }
}

我在使用 Util 方法时遇到了类似的问题，它在 8 个位置被标记。在这次修复之后，所有这些问题都得到了解决。

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

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