Page.IsPostBack 的安全實現？

Question

根據我之前關於ASP.net 的默認 Page.IsPostBack 實現是否安全的問題（它不是；它可以被偽造...... HTTP 動詞甚至不必是 POST，）； 我剛在想？ 肯定有更好的方法來實現它。 我們能想出一個 Page,IsPostBack 實現，當它是真的時？ 幾乎可以保證表明該頁面是實際的 ASP.net 回發，如果只想進行一次安全檢查（例如是否會根據用戶的角色顯示某些內容），這一點很重要。 並且只有在我們不處理 ASP.net 回發時才想這樣做。

關於如何做到這一點，我的第一個想法是在屬性中實現檢查代碼，因此我可以在Page_Load中編寫類似這樣的內容：

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

有沒有辦法安全地實施_isPostBack ？ 也許在 ViewState 中存儲一些難以或不可能通過 jerry-rig 偽造回發的東西？ 隨機字符串？

Answer 1

幾年前我有一個項目，我們對代碼進行了一些滲透測試。 他們指出了默認情況下IsPostback不檢查 http 動詞的事實。 為了解決這個問題，我創建了一個抽象的頁面 class ，它有自己的IsPostback實現，它隱藏了默認的實現：

Public Class ProjectPage : System.Web.UI.Page

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

End Class

這允許您對 http 動詞進行測試，但您也可以輕松擴展該方法以進行其他檢查。

Answer 2

好的，這就是我認為的解決方案： Page.IsPostBack已經足夠安全，只要啟用了事件驗證。 讓我在下面解釋我的推理，如果我有什么問題，我很樂意任何人添加評論。

為了將欺騙回發發布到 ASP.net 並觸發控件的OnClick事件，啟用事件驗證，客戶端必須發送__EVENTVALIDATION表單字段。 此字段包含一個唯一生成的字符串，它基本上告訴 ASP.net 控制該頁面的回發事件可能源自哪個。 如果您嘗試欺騙已設置.Visibility = false的按鈕的回發，您將看到事件驗證錯誤消息。 所以，看起來你不能直接欺騙隱藏控件的點擊。

欺騙您已呈現的頁面上現有按鈕之一的回發怎么樣（即您確實有權查看/單擊它）？ 好吧，您可以將回發發送到頁面，但您需要提交有效的__VIEWSTATE否則您只會收到“狀態信息無效”錯誤。 為了獲得有效的__VIEWSTATE ，您已經需要將頁面加載為非回發，對嗎？ 這意味着安全檢查代碼將至少執行一次，隱藏適當的控件並將其記錄在__VIEWSTATE中。 因此，當您發布欺騙回發時，是的，它會導致Page.IsPostBack為真，但這沒關系，因為提交的__VIEWSTATE已經在之前的非回發頁面加載時生成，以隱藏您應該隱藏的內容'無權訪問...因此，您可以欺騙回發，但只能通過傳遞先前由非回發頁面加載生成的__VIEWSTATE 。

因此，由於這些事實，只將安全檢查代碼放在Page.IsPostBack == false塊中應該是安全的。 這必須始終運行一次，然后才能將有效的回發提交到 ASP.net 服務器。 還是我錯過了什么？

Answer 3

cookie 是一種更好的機制來滿足您的需求。 cookie 是一個只能由服務器生成的令牌，並為令牌持有者提供某些聲明，例如最近登錄以及擁有某些權限和/或偏好。 其中一些功能內置在 FormsAuthentication 中。 您可以實現自己的 cookie 機制，但您應該研究安全 cookie 協議，因為有幾個不明顯的安全注意事項。

好處是您不必在每次請求時都向數據庫發送 go，您只需信任它。 這也可能是抵御某些 DoS 攻擊的好策略，因為您可以將應用分層，以便應用服務器前面的專用設備也驗證令牌並拋出無效請求。

如果不允許 cookies，您可以將令牌作為 url 的一部分（如 formsauth 允許的那樣）或作為回發中的表單字段發送。 但是，一旦您遇到了生成適當令牌的麻煩，那么管理工作就比 cookies 恕我直言。