3

我在 asp.net mvc5 中有以下操作方法，我将其定义为 ChildActionOnly：-

[ChildActionOnly]
public ActionResult GetChildRecords(int customerid)

在我看来，我将其称为如下：-

<div>@Html.Action("GetChildRecords", "Customer", new {customerid = Model.CustomerID})</div>

但我有以下问题：-

  1. 我需要在我的子操作方法之前添加 [Authorize] 注释吗？或者我可以肯定，因为它的父母被授权，所以子动作方法也将被授权？

  2. 用户或黑客可以直接调用 ChildActionOnly 吗？

  3. 用户或黑客可以修改 Html.Action 参数吗？例如在下面的 html 中传递不同的 customerid：-

@Html.Action("GetChildRecords", "Customer", new {customerid = Model.CustomerID})

?

4

2 回答 2

3

属性的本质[ChildActionOnly]是保证只用Actionor调用RenderAction，不能直接从浏览器调用。

对于问题1：如果调用动作已经有[Authorize]属性，你不必担心

对于问题 2：黑客（或任何人）无法直接访问它。

对于问题 3：由于他们不能直接调用该操作，我不确定它有什么可担心的。但始终在服务器端验证您获得的任何输入（表单、查询字符串等）。

于 2015-03-09T11:58:26.957 回答
1

我同意@scartag 对问题 2 和 3 的回答：

2 - 它是一个子动作，所以不能直接调用

3 - 攻击者无法干预以修改传递给子操作的参数，因此在父操作中进行初始验证就足够了。但是，这可能会导致封装不佳，因为子操作的某些逻辑可能会泄漏到父操作中。

关于问题 1，我认为授权子行为将是一个很好的纵深防御：

  • 今天，可能所有的父行为都被授权，但未来呢？如果另一个开发人员没有意识到这是假设的，并且在新的未经授权的父操作上使用子操作怎么办？也许您可以使用代码注释来减少这种情况的发生，但为什么要冒险呢？
  • 根据您的应用程序权限模型的复杂性，父级的授权逻辑可能与子级的不同。同样，今天可能不是这种情况，但将来可能会如此。
于 2015-03-09T12:21:51.393 回答