java - 模型驱动接口(interface)是否会在 struts2 中构成安全漏洞？

Question

背景:我用 ModelDriven 编写了一个 struts2 ActionSupport 类。这是一个 hibernate/spring web 应用程序，在 View (JSP) 中使用 OSIV 和附加实体。

我今天收到了一封来自建筑师的电子邮件，因为我放置了一个物体而“惩罚”我 它通过 ModelDriven<E>界面。他是对的还是什么？显然，这是我正在做的一件严肃的事情，但我没有听从他的话，我真的不想接受他的提议，也不想在此之后去他的办公 table 前拜访他。好家伙。是时候改变职业了。

--- 来自建筑师---

Billy，正如我们之前讨论的那样，您在代码中仍然犯同样的错误 一遍又一遍地。这是你第四次犯这个错误，我很担心 关于你的工作质量。做一次甚至两次是一回事，但是 第四次之后，不知道你是不是听不懂我在说什么。下面就为你一一揭晓。如果您在阅读这封电子邮件后仍不明白，请到我的办公 table 前，我们将讨论一下。这必须立即停止，我想要所有 您的代码在当天结束前重构，更正了这个错误。如果任何代码像 这会渗入生产中，我们将面临严重的安全问题。另请注意，我正在抄袭戴夫，以便发出适当的谴责。我还将向 Dave 建议将您从 III 级开发人员转移到 II 级开发人员。请阅读以下内容并学习它，并按照我的指示重构您的所有代码。

关于绑定(bind)对象:

当一个Struts2的action类标有ModelDriven接口(interface)时，模型 将绑定(bind)到 HTML 页面中的表单元素。例如，如果一个 HTML 表单 有一个名为 userName 的字段和一个操作类定义为:

公共(public)类 UserAction 扩展 ActionSupport 实现 ModelDriven

而 UserModel 是一个 POJO，如下所示:

public class UserModel {
  private String userName;

  public String getUserName() {
      return userName;
  }

  public void setUserName(String userName) { 
      this.userName = userName;
  }
}

提交表单时，只要Action中包含UserModel的实例，struts2 将字段 userName 绑定(bind)到 UserModel.userName，自动填充值。

但是，对于恶意用户来说，这种简单性需要付出高昂的代价。如果声明了一个对象 作为 ModelDriven，最终用户，即浏览用户，可以访问模型图 通过模型 setter 。以这个案例为例:

公共(public)类 UserAction 扩展 ActionSupport 实现 ModelDriven

和...

public class UserModel {
  private String userName;
  private UserEntity userEntity;

  public String getUserName() {
      return userName;
  }

  public void setUserName(String userName) { 
      this.userName = userName;
  }

  pubic UserEntity getUserEntity() {
      return userEntity;
  }
}

和...

@Entity
public class UserEntity {
    private String password;

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }
 }

假设正在使用 OSIV 模式，并且附加了实体 UserEntity。

有一点先见之明或手头有时间的狡猾用户可能会:

/myform?userName=billy&userEntity.password=newpassword

假设实体在 session 结束时被保存，上面的结果会改变 比利的密码。

重点是，对象图可用!

当使用 ModelDriven 并且使用替代方法是一种可怕的方法时，您必须定义 放置在值堆栈上的细粒度模型，然后从模型复制到 发送响应并允许事务提交之前的目标对象。

Answer 1

您的架构师是对的，将可以访问敏感信息的对象放在 ValueStack 上会带来潜在的安全风险。恶意用户确实可以通过上述攻击重置密码。

但是:

既然他是一名架构师，他应该设计出正确验证/限制输入参数的方法。使用 Struts2 中的 ParamsInterceptor 可以很容易地只允许将特定参数传递给操作。因此，糟糕的不是你的工作，而是你的系统架构。 开发人员应该能够专注于实现业务逻辑。基础架构必须由架构师提供。

干杯，

w