我在多个地方的项目中都面临着这个安全漏洞。我没有任何白名单可以在每次出现此缺陷时进行检查。我想使用 ESAPI 调用对文件名执行基本的黑名单检查。我读过我们可以使用 ESAPI 的 SafeFile 对象,但不知道如何以及在哪里。
以下是我想出的几个选项,请告诉我哪一个可行?
ESAPI.validator().getValidInput()
或者
ESAPI.validator().getValidFileName()
黑名单是一个没有双赢的情况。这只能保护您免受已知威胁。您在这里使用的任何代码扫描工具都会继续报告该漏洞......因为黑名单是一个漏洞。请参阅OWASP的此说明:
这种策略,也称为“否定”或“黑名单”验证,是积极验证的弱替代方案。本质上,如果您不希望看到 %3f 或 JavaScript 或类似字符,请拒绝包含它们的字符串。这是一种危险的策略,因为可能的坏数据集可能是无限的。采用这种策略意味着您将不得不永远维护“已知不良”字符和模式的列表,并且根据定义,您将获得不完整的保护。
此外,字符编码和操作系统也使这成为一个问题。假设我们接受 *.docx 文件的上传。这是要考虑的不同极端情况,这将适用于您投资组合中的每个应用程序。
\
在 Windows 和/
linux 中。)在跨系统的文件/目录路径中,空格的处理方式也不同。netcat.exe
为foo.docx
,您的应用程序是否真的会检查正在上传的文件是否包含exe 文件的幻数?如果这是针对您公司的投资组合的多个应用程序,那么您的道德责任是清楚地说明这一点,然后您的公司需要提出一个应用程序/按/应用程序白名单。
就 ESAPI 而言,您将使用Validator.getValidInput()
一个正则表达式,它是您想要拒绝的所有文件的 OR,即。validation.properties
你会做类似的事情:Validator.blackListsAreABadIdea=regex1|regex2|regex3|regex4
请注意,黑名单的解析惩罚也更高......每个输入字符串都必须针对黑名单中的每个正则表达式运行,正如 OWASP 指出的那样,它可以是无限的。
因此,正确的解决方案是让您投资组合中的每个应用程序团队为其应用程序构建一个白名单。如果这真的不可能(我对此表示怀疑),那么您需要确保您已向管理层明确说明此处引用的风险,并且您拒绝继续使用黑名单方法,直到您获得公司选择接受的书面文件风险。当黑名单失败并将您告上法庭时,这将保护您免于承担法律责任。
[编辑]
您正在寻找的方法在HTTPUtilites.safeFileUpload()
此处被称为验收标准,但由于我在上面发布的困难,这很可能从未实施过。黑名单对应用程序来说是非常定制的。您将得到的最好的方法是使用在键下HTTPUtilities.getFileUploads()
定义的列表的方法ESAPI.properties
HttpUtilities.ApprovedUploadExtensions
但是,需要自定义默认版本,因为我怀疑您是否希望您的用户将.class
文件上传dll
到您的系统。
另请注意:此解决方案是 awhitelist
而不是blacklist.
如果目录路径是静态的并且只有文件名是外部控制的,则以下代码片段可以解决 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];