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

发布于 2024-10-26 22:24:28 字数 1224 浏览 1 评论 0原文

我已经读过 通过 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;
    }

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

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

该函数成功显示一条咆哮消息,表明标题已创建,并显示一个带有加密记录 id 的链接作为 url 的查询字符串以查看详细信息创建的标题。

现在最紧迫的问题是,

  1. 这足够安全吗?我缺少什么?
  2. 我怎样才能使这个过程更安全、更快?

I already read
Securing AJAX Requests via GUID
and
Securing an ajax request
. Now let me explain my scenario, below would be code snippet that may aid at explaining in the subject matter.

[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;
    }

and below is the javascript call to send in the parameters. btnCreateTitle_click is the click event of the button client side. txtTitle is the textbox accepting the title name. Validators are created on the page to validate the textbox too.CreateTitle is a page method i call using scriptmanager

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

the function success shows a growl message that title was created and shows a link with encrypted record id as query string to the url to view the details of created title.

Now the burning question,

  1. IS this secure enough? What am i missing?
  2. How could i make the process more secure and faster?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

苦行僧 2024-11-02 22:24:28

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

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

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

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

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

希望这有帮助,

While it is trivial to restrict any method to authenticated and authorised users, when you expose db id's in query strings you do open the possibility that an authenticated and authorised user may seek to access records that they aught not. This is particularly so when the db id's are integers or some other easily guessed identifier. Using Guids as db ids may mitigate the risk of this, though not absolutely.

What you always need to remember is DO NOT TRUST INPUT. Security through obscurity (ie encryption etc) is not a reliable technique. Your service should always verify the the current user is allowed to retrieve the records they have requested. Sometimes this is known as row level security. This can only be done programmatically.

eg instead of only determining that someone is authorised to view a record, you need to verify that they have rights in fact to access the record they are requesting.

This means you need some way of relating records to an authenticated user.

BTW: any HTTP request is validated for potentially dangerous input.

Hope this helps,

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文