Page.IsPostBack的安全实现？

如何解决Page.IsPostBack的安全实现？

| 继我先前关于ASP.net的默认Page.IsPostBack实现是否安全的问题（不是；它可以被伪造……HTTP谓词甚至不必是POST！）之后，我在考虑;当然必须有更好的方法来实施它？我们能否提出Page.IsPostBack实现，当它为true时，几乎可以保证指示该页面是实际的ASP.net回发吗？如果仅要进行一次安全检查（例如是否根据用户角色显示某些内容），并且仅在我们不处理安全问题时才进行检查，这一点很重要。 ASP.net回发。关于如何执行此操作的第一个想法是在属性中实现检查代码，因此可以在Page_Load中编写如下内容：

if (!_isPostBack)
{
    // Do security check
    if (userIsNotAuthorized)
    {
        btnViewReports.Visible = false;
        btnEditDetails.Visible = false;
        // etc.
    }
}

有没有办法安全地实施“ 2”？也许在ViewState中存储一些很难或不可能伪造回发的东西吗？随机字符串？

解决方法

几年前，我有一个项目，其中对代码进行了一些渗透测试。他们举报了默认情况下IsPostback不检查http动词的事实。为了解决这个问题，我创建了一个抽象的Page类，其自己的实现IsPostback实现了默认的实现：

Public Class ProjectPage : System.Web.UI.Page

    public new bool IsPostBack()
    {
        return (Page.IsPostBack && Request.HttpMethod.ToUpper() == \"POST\");
    }

End Class

这使您可以对http动词进行测试，但是您可以轻松地将该方法扩展为进行其他检查。 , 好的，这是我认为的解决方案：只要启用了事件验证，Page.IsPostBack已经足够安全。让我在下面解释我的理由，如果我遇到了问题，我很乐意为任何人添加评论。为了将欺骗回发发布到ASP.net并触发控件的“ 6”事件，并启用事件验证，客户端必须发送“ 7”表单字段。该字段包含一个唯一生成的字符串，该字符串基本上告诉ASP.net，该控件控制该页面可能源自的回发事件。如果您尝试欺骗已设置了.Visibility = false的按钮的回发，则会看到事件验证错误消息。因此，您似乎无法直接欺骗隐藏控件的单击。欺骗已呈现页面上现有按钮之一的回发（即，您确实有权查看/单击它）怎么办？好吧，您可以将回发发送到页面，但是您需要提交有效的“ 9”，否则您将收到“状态信息无效”错误。为了获得有效的“ 9”，您已经需要以非回发的方式加载页面，对吗？这意味着安全检查代码将至少执行一次，隐藏适当的控件并将其记录在“ 9”中。因此，当您发布欺骗性回发时，是的，它将导致Page.IsPostBack为真，但这并不重要，因为在先前的非回发页面加载中已经生成了所提交的__VIEWSTATE以隐藏您不应该的内容\无法访问...，因此，您可以欺骗回发，但只能传递先前由非回发页面加载生成的ѭ9。因此，由于这些事实，仅将安全检查代码放在“ 15”块中应该是安全的。必须先运行一次，然后才能将有效的回发提交到ASP.net服务器。还是我错过了什么？ , Cookie是满足您需求的更好的机制。 Cookie是只能由服务器生成的令牌，并为令牌的持有者担保某些声明，例如最近登录以及具有某些权限和/或首选项。其中一些功能内置在FormsAuthentication中。您可以实现自己的cookie机制，但由于存在一些非显而易见的安全注意事项，因此您应该研究安全cookie协议。这样做的好处是您不必在每次请求时都访问数据库，只需信任它即可。这也可能是抵御某些DoS攻击的好策略，因为您可以对应用程序进行分层，以使应用程序服务器前面的专用设备也可以验证令牌并抛出无效请求。如果不允许cookie，则可以将令牌作为URL的一部分，formsauth允许或作为回发中的表单字段发送。但是，一旦您遇到了生成适当令牌的麻烦，那么要管理cookie，然后是IMHO。