通过经过身份验证的Webforms保护ASP.net中的Ajax请求

Dee*_*ons 5 asp.net security webforms asp.net-ajax nonce

我已经通过GUID保护ajax请求阅读了 保护AJAX 请求 .现在让我解释一下我的场景,下面是可能有助于解释主题的代码片段.

[WebMethod[EnableSession = True]
[ScriptMethod]

    public static string CreateTitle(string strTitleName)
    {
    string strResult = "Custom jSon string";
    if(Session["Authorized"] == "True" && !String.IsNullOrEmpty(strTitleName))
    {
         String strTitle = Server.HtmlEncode(strTitleName);
         InsertRecordInDB(strTitle);
         strResult = "Custom jSOn string" + EncryptMD5("record id");
    }
           return strResult;
    }
Run Code Online (Sandbox Code Playgroud)

以下是在参数中发送的javascript调用.btnCreateTitle_click是按钮客户端的click事件.txtTitle是接受标题名称的文本框.在页面上创建验证器以验证文本框.CreateTitle是我使用scriptmanager调用的页面方法

function btnCreateTitle_Click(evnt){
if(Page.ClientValidate()){
if($get("txtTitle")){
PageMethods.CreateTitle($get("txtTitle").value,success,failure,context);
}}}
Run Code Online (Sandbox Code Playgroud)

函数成功显示创建标题的growl消息,并显示带有加密记录id的链接作为查询字符串到url以查看创建的标题的详细信息.

现在燃烧的问题,

  1. 这足够安全吗?我错过了什么?
  2. 我怎样才能让这个过程更安全,更快捷?

Xha*_*ent 4

虽然将任何方法限制为经过身份验证和授权的用户是微不足道的,但当您在查询字符串中公开数据库 ID 时,您确实打开了经过身份验证和授权的用户可能寻求访问他们不应该访问的记录的可能性。当数据库 ID 是整数或其他一些容易猜到的标识符时尤其如此。使用 Guid 作为数据库 ID 可能会降低这种风险,但并非绝对如此。

您始终需要记住的是不要相信输入。通过模糊性(即加密等)实现安全并不是一种可靠的技术。您的服务应始终验证当前用户是否有权检索他们请求的记录。有时这称为行级安全性。这只能通过编程来完成。

例如,您不仅需要确定某人有权查看记录,还需要验证他们实际上是否有权访问他们所请求的记录。

这意味着您需要某种方式将记录与经过身份验证的用户相关联。

顺便说一句:任何 HTTP 请求都会经过验证是否存在潜在危险的输入。

希望这可以帮助,