我正在努力修复我的应用程序中的Veracode问题。 Veracode在下面的代码中突出了“文件名或路径的外部控制(CWE ID 73)”的缺陷。
Thread.currentThread().getContextClassLoader().getResourceAsStream(lookupName)
如何验证参数?如果我需要使用下面的ESAPI验证,那么我应该在getValidFileName()方法中传递的确切参数是什么。目前我传递的参数如下。
ESAPI.validator().getValidFileName(lookupName, lookupName,
ESAPI.securityConfiguration().getAllowedFileExtensions(), false);
纠正我是否遵循正确的方法解决此问题。
答案 0 :(得分:1)
好的,问题是您允许用户控制该文件路径。想象一下它在UNIX机器上,然后输入:
../../../../../../../etc/shadow
无论为运行该用户的用户授予何种用户权限,都可以向该用户公开Thread
。我不知道您的应用程序正在进行什么处理,但危险在于您需要阻止用户控制该lookup
变量。
您正在进行的调用与ValidatorTest.java
中的单个测试一致,这绝对是代表我们的代码覆盖率的缺陷。
现在,很有可能即使您使用此调用,Veracode仍可能会标记它:ESAPI.properties
中的默认文件列表需要为您的用例截断,或者您必须为特定用例的合法文件扩展名创建自己的Validator规则。
这会带来下一位:There's a lot of mischief that can happen in regards to file uploads.
简而言之,实际安全的文件上传需要的不仅仅是ESAPI目前提供的,不幸的是,这只是一次扩展检查。在您的特定情况下,请确保您尝试一些目录遍历攻击。并使用该OWASP链接来帮助分析您的应用程序。
鉴于OP希望清除Veracode中的问题,您可能希望链接几个电话:
ESAPI.validator().getValidDirectoryPath()
和ESAPI.Validator.getValidFileName()
但请确保您已在validator.properties中正确截断了HttpUtilities.ApprovedUploadExtensions
中的扩展名列表,因为默认列表过于宽松,至少在我们发布2.1.0.2之前。
我必须强调的是,即使使用此特定组合 ,ESAPI也绝对没有阻止用户将“netcat.exe”重命名为“puppies.xlsx”并绕过验证检查 ,这就是为什么在这个答案的第一部分咆哮。
ESAPI的文件验证不安全,它完全没有任何优势。
正确执行此操作需要更多工作,而不仅仅是使用1-2次调用ESAPI。
免责声明:在撰写本文时,我是ESAPI的项目联合负责人。
答案 1 :(得分:0)
如果这些文件存储在服务器端,则可以使用硬编码值。 (即:在HashMap中)。
另一种解决方案是使用自定义验证器(来自veracode页):
// GOOD Code
String extension = request.getParameter("extension");
File f = new File(buildValidAvatarPath(extension))
@FilePathCleanser
public String buildValidAvatarPath(extension) {
String[] allowedExtensions = new String[]{"jpg","gif","png"};
String extension = "png"; // Default extension
for (String allowedExtension: allowedExtensions) {
if (allowedExtension.equals(request.getParameter("extension"))) {
extension = request.getParameter("extension");
}
}
// See "Note on authorization"
User user = getCurrentUser();
if (!userMayAccessFile(user, path)) {
throw new AuthorizationException("User may not access this file", user);
}
File(configPath + "avatar." + extension)
return path;
}