我的项目在多个地方都面临这个安全漏洞。我没有任何白名单可以在每次出现此缺陷时进行检查。我想使用 ESAPI 调用对文件名执行基本的黑名单检查。我读过我们可以使用 ESAPI 的 SafeFile 对象，但不知道如何以及在哪里。
以下是我想出的几个选项，请告诉我哪一个可行？
ESAPI.validator().getValidInput() 或 ESAPI.validator().getValidFileName()
【问题讨论】：
黑名单是一个没有成功的方案。这只能保护您免受已知 威胁。您在此处使用的任何代码扫描工具都会继续报告该漏洞……因为黑名单是漏洞。请参阅OWASP: 的此注释
这种策略，也称为“否定”或“黑名单”验证是一种 积极验证的弱替代方案。本质上，如果你不 希望看到 %3f 或 JavaScript 或类似字符，拒绝 包含它们的字符串。这是一个危险的策略，因为集合 可能的不良数据可能是无限的。采用这种策略 意味着您将必须维护“已知不良”列表 字符和模式永远存在，而你将根据定义拥有 保护不完整。
此外，字符编码和操作系统也使这成为一个问题。假设我们接受 *.docx 文件的上传。以下是需要考虑的不同极端情况，适用于您投资组合中的每个应用程序。
\，在 linux 中为 /。）
一种。跨系统的文件/目录路径中的空格也有不同的处理方式。netcat.exe 重命名为 foo.docx，您的应用程序是否真的会检查正在上传的文件是否包含 exe 文件的 magic numbers？如果这是针对您公司的产品组合的多个应用程序，那么您有义务明确说明这一点，然后您的公司需要提出一个应用程序/按/应用程序白名单。
就 ESAPI 而言，您可以将Validator.getValidInput() 与一个正则表达式一起使用，该正则表达式是您想要拒绝的所有文件的 OR，即。在validation.properties 中，您会执行以下操作：Validator.blackListsAreABadIdea=regex1|regex2|regex3|regex4
请注意，黑名单的解析惩罚也更高......每个输入字符串都必须针对黑名单中的每个正则表达式运行，正如 OWASP 指出的那样，它可以是无限的。
同样，正确的解决方案是让您投资组合中的每个应用程序团队为其应用程序构建一个白名单。如果这真的不可能（我对此表示怀疑），那么您需要确保您已向管理层明确说明此处引用的风险，并且您拒绝继续使用黑名单方法，直到您有书面文件公司选择承担风险。当黑名单失败并将您告上法庭时，这将保护您免于承担法律责任。
[编辑]
您正在寻找的方法称为HTTPUtilites.safeFileUpload()listed here as acceptance criteria，但由于我在上面发布的困难，这很可能从未实现过。黑名单是非常为应用程序定制的。最好的方法是 HTTPUtilities.getFileUploads() 方法，它使用在 ESAPI.properties 中定义的列表，位于 HttpUtilities.ApprovedUploadExtensions 键下
但是，默认版本需要自定义，因为我怀疑您是否希望您的用户将 .class 文件和 dll 上传到您的系统。
另请注意：此解决方案是 whitelist 而不是 blacklist.
【讨论】：
如果目录路径是静态的并且只有文件名是外部控制的，则以下代码 sn-p 可以解决 CWE ID 73 问题：
//'DIRECTORY_PATH' is the directory of the file
//'filename' variable holds the name of the file
//'myFile' variable holds reference to the file object
File dir = new File(DIRECTORY_PATH);
FileFilter fileFilter = new WildcardFileFilter(filename);
File[] files = dir.listFiles(fileFilter);
File myFile = null ;
if(files.length == 1 )
myFile = files[0];
【讨论】：