我在多个地方的项目中遇到了这个安全漏洞。我没有任何白名单来检查这个漏洞的每一次出现。我想使用ESAPI调用对文件名执行基本黑名单检查。我已经读过,我们可以使用ESAPI的SafeFile对象,但无法弄清楚如何以及在何处。
以下是我提出的几个选项,请告诉我哪一个可以解决?
ESAPI.validator().getValidInput()
或
ESAPI.validator().getValidFileName()
答案 0 :(得分:1)
黑名单是一个不赢的场景。这只能保护您免受已知的威胁。您在此处使用的任何代码扫描工具都将继续报告此漏洞...因为黑名单 是一个漏洞。请参阅OWASP:
中的此说明这种策略,也称为“否定”或“黑名单”验证 积极验证的弱替代品。基本上,如果你不这样做 期望看到%3f或JavaScript或类似字符,拒绝 包含它们的字符串这是一个危险的策略,因为这个集合 可能的坏数据可能是无限的。采用这种策略 意味着你必须保持“已知坏”列表 永远的字符和模式,你将按照定义 不完全保护。
此外,字符编码和操作系统也是一个问题。假设我们接受上传* .docx文件。以下是需要考虑的不同角落情况,对于您的投资组合中的每个应用程序,这都是。
\
,Linux中为/
。)
一个。在系统的文件/目录路径中,空格也被区别对待。netcat.exe
重命名为foo.docx
,您的应用程序是否会检查上传的文件是否包含exe文件的magic numbers?如果这是针对贵公司产品组合的多个应用程序,那么明确说明这一点是您的道德责任,然后您的公司需要提出app / by / app白名单。
就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.
答案 1 :(得分:0)
如果目录路径是静态的并且只有文件名是外部控制的,则以下代码片段可以解决 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];