Question

我们的任务是使用IBM AppScan和OWASP ZAP在我们的MVC Web应用程序上运行安全审核扫描。我们已经能够理解并缓解这些工具突出显示的99％的漏洞，但我遇到了一个令我难过的漏洞。在我们的一个项目中，我们有一些实现System.ComponentModel.DataAnnotations.ValidationAttribute的自定义数据验证类。这些类的一般模式是：

[AttributeUsage(AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Parameter)]
public class WhateverAttribute : ValidationAttribute
{
    public Type ServiceType { get; set; }
    public string ServiceValidationMethodName { get; set; }

    protected override ValidationResult IsValid(object value, ValidationContext context)
    {
        if(value == null)
            return ValidationResult.Success;
        var service = DependencyResolver.Current.GetService(ServiceType);
        if(service == null)
            throw new ArgumentNullException("....");
        var instanceType = context.ObjectInstance.GetType();
        var valueType = value.GetType();
        var method = ServiceType.GetMethod(ServiceValidationMethodName, new [] { instanceType, valueType });
        if(method == null)
            throw new ArgumentNullException("....");
        var isValid = (bool)method.Invoke(service, new[] { context.ObjectInstance, value });
        return isValid ? ValidationResult.Success : CreateValidationError(context);
    }
}

AppScan使用“恶意DynamicCode执行”漏洞标记实际调用验证方法的行。我已经对这些互联网进行了一些阅读，并且无法弄清楚在这种情况下使用反射来调用方法是否存在安全风险。是吗？如果是这样，如何减轻它？如果没有，我告诉我的安全团队如何说服他们我们没事？

Answer 1

让我们看一下OWASP explanation 动态代码评估（'Eval Injection'）

噩梦场景是

  $myvar = "varname"; 
  $x = $_GET['arg']; 
  eval("\$myvar = \$x;");

臭名昭着的JavaScript Eval()函数使用字符串参数来完成 UI用户提出的任何问题！

他们提供的其他示例包括两种类型的SQL注入，HTML XSS和使用php Server.Execute()。

这些案件有什么共同之处？它们都是动态环境。最糟糕的是 EXECUTING 传递的参数字符串。

这些与您的代码有什么关系？

大多数情况下，您使用的是Invoke()和DependencyResolver。恐惧的表弟Eval()，在适当的情况下，Invoke()和“未透露的反射”可用于

找一个构造函数作为攻击的一部分

可怕？非常！

这究竟是什么意思？这不完全是“动态代码评估”......

详细信息位于OWASP explanation of Unsafe use of Reflection

如果攻击者可以提供应用程序随后用于确定要实例化哪个类或要调用哪个方法的值，则攻击者可能会创建通过应用程序的控制流路径，而应用程序开发人员并不打算这样做。此攻击媒介可能允许攻击者绕过身份验证或访问控制检查，或以其他方式导致应用程序以意外方式运行。

这种语言故意含糊不清。 “可能允许......攻击者创建控制流路径......或以其他方式导致......以意想不到的方式行事。”但即使你从字面上理解警告，这也不像“动态代码评估”

他们的具体例子：

   String ctl = request.getParameter("ctl");
   Class cmdClass = Class.forName(ctl + "Command");
   Worker ao = (Worker) cmdClass.newInstance();
   ao.doAction(request);

此处的漏洞是Class的实例化，其名称来自UI中的字符串参数。我可以看到，如果有足够的尝试，一个脚本小伙子可以找到一种方法......做......某事......

问：此示例中有什么潜在危险？

答：此类可以是访问属性， UserManager 或访问Cookie工厂。

问：攻击者如何利用它？

A：不知怎的......

我希望你现在变得有点怀疑，因为......这里有一些严重的影响力。

Eval()，Invoke()和doAction()是动态运行时方法的类型，可能很危险。

评估并执行“运行时”。在最糟糕的情况下，他们能够动态创建代码。越有活力，越危险。

如果他们围绕“用户输入”实例化了一个类，那么用户可能“找到一个构造函数来作为攻击的一部分”。

<强>结论：

应用扫描仪寻找烟雾，潜在的麻烦迹象。通常，动态代码是危险的，因此应该标记和检查应该。如果你想要真正安全，不要创造任何东西。当然不要做任何动态！（讽刺）

注意：大多数安全漏洞都是由动态运行时操作引起的。

这里的问题再一次是，App Scanners最好找出可疑的风险，而不是遗漏某些东西。这是一个可疑风险的例子，因为没有人对此有所了解。至少，与SQL注入，Eval注入，XSS等无关。

您的具体示例距离OWASP的“不安全使用反射”的示例还有很长的路要走。没有神奇的字符串评估。

您的代码与“动态代码[执行] ”完全不同。它是动态代码，没有人可以告诉你没有任何危险情况。

但感觉就像一个触手可及。除非我遗漏了某些内容，否则您的代码不会创建名称通过参数字符串传递的对象。

最终注释：Reflection injection上的OWASP页面已被删除，支持“不安全使用反射”。反射注入具有更好的威胁感......但该术语需要更具体的示例，类似于SQL注入。

使用反射在“ValidationAttribute”的实现中调用验证是否存在安全风险？

1 个答案:

这些与您的代码有什么关系？