【问题标题】:Securing a remote ajax method call保护远程 ajax 方法调用
【发布时间】:2009-02-02 14:58:58
【问题描述】:

我编写了一些 JavaScript 代码来在 asp.net 应用程序中执行 ajax 调用。这会触发一个调用 URL 的方法,在 POST 中发送一些参数。

接收页面处理数据并更新我们的数据库。

我们将向客户提供此代码,以便他们向我们发送我们在每次交易的结账过程中需要的数据。

谁能告诉我是否有办法防止未经授权访问此 URL?否则,不道德的开发人员可能会在不应该的情况下使用此 URL 将数据添加到我们的数据库中。

感谢您的任何指点。


这里的问题是我将向我们的客户提供代码,他们会将其添加到他们的网站。所以我没有选择让他们执行比在他们的网站上添加几行代码更复杂的事情。

不过,代码需要以某种安全的方式向我们的服务器发送数据?

这是不可能的情况,还是我需要在处理完成后执行某种审核?

感谢大家的一些好的建议。

【问题讨论】:

  • 为什么需要用 Javascript 和 AJAX 来做这件事?为什么不直接为您的客户提供服务,然后将他们在服务器端的代码与您的服务集成。这样,您可以选择任何有意义的身份验证机制。

标签: javascript ajax security


【解决方案1】:

您可以使用 SOAP 将用户名/密码与请求一起传递。 SSL 应该用于加密通过网络传输的数据。这是我们使用的一些代码:

这是一个保存随请求发送的凭据的类:

Imports System.Web.Services.Protocols
Public Class ServiceCredentials

Inherits SoapHeader

Private _userName As String
Public Property UserName() As String
    Get
        Return _userName
    End Get
    Set(ByVal value As String)
        _userName = value
    End Set
End Property


Private _password As String
Public Property Password() As String
    Get
        Return _password
    End Get
    Set(ByVal value As String)
        _password = value
    End Set
End Property

Public Sub New()

End Sub

Public Sub NewUserInfo(ByVal ServiceUser As String, ByVal ServicePassword As String)
    Me.UserName = ServiceUser
    Me.Password = ServicePassword

End Sub

在您的 Web 服务的定义中添加一个属性:

    <WebMethod()> _
<SoapHeader("CredentialsHeader")> _
   Function MyWebMethod(ByVal paremetersPassed as String)
   'check permissions here
   If PermissionsValid(CredentialsHeader) then
    'ok!
       .......
   else
       'throw a permission error
  end if
 End Function

然后从那里创建一个函数(在我的示例中为 PermissionsValid)来检查权限:

Function PermissionsValid(byval Credentials as ServiceCredentials) as boolean

    'check Credentials.Username and Credentials.Password here and return a boolean
End Function

这看起来像是一堆工作,但这样一来,当他们发送请求时,您可以对照数据库或您想要的任何其他东西检查它。您还可以在最后轻松关闭用户名。

更简单的方法是限制允许访问服务页面的 IP 地址。但是,您会遇到 IP 地址更改等问题。

顺便说一句,大部分内容都是在我发帖时输入的,因此您可能需要检查代码以确保它可以编译。 :)

【讨论】:

    【解决方案2】:

    像往常一样设置用户登录系统 - 即当用户登录时,将用户名和密码哈希存储在会话或 cookie 中。

    POST 页面或处理程序可以简单地检查所需的凭据 - 如果丢失或不正确,您可以只返回权限错误。

    【讨论】:

      【解决方案3】:

      您应该使用 SSL 保护您的服务

      编辑:我忘记了最“基本”的:HTTP 身份验证(使用登录名/密码) 我找到了一个链接,但它来自 2003 年:http://www-128.ibm.com/developerworks/webservices/library/ws-sec1.html

      编辑 2:正如 cmets 中所说,我认为这里的问题符合 REST Web 服务的目的......我对 asp.net 一无所知,但您应该期待 REST 教程并查看安全替代方案您拥有从 HTTP 身份验证到完整的 WS-Security 实施

      【讨论】:

      • SSL 对流量进行加密,但对授权没有影响。
      • 你不能使用密钥对来签名消息吗?所以消息来源是已知的
      • Vinze,您能详细说明您的建议吗?
      • 嗯,在我看来,这里的问题符合 REST Web 服务的目的...我对 asp.net 一无所知,但您应该期待 REST 教程并查看安全替代方案您拥有从 HTTP 身份验证到完整的 WS-Security 实现
      【解决方案4】:

      您能否检查您的接收页面是否用户已登录,即

      if User.IsAuthenticated
      

      ?

      【讨论】:

        【解决方案5】:

        您的所有客户都在您的域中吗?
        否则,您将无法使用 XMLHttpRequest 对象从他们的站点发送数据。 XHR 受Same Origin Policy 约束。
        您可以在 iframe 中从服务器发布到页面。您需要提示您的用户输入他们的用户名和密码,以便这些详细信息不会暴露在您的脚本中,并且应该通过 ssl 提供目标。

        【讨论】:

          【解决方案6】:

          抱歉,我还没有足够的reupation,所以无法添加 cmets。

          我不完全理解你的问题。您是否在询问您提供用户名/密码的开发人员是否决定滥用网络服务?

          如果是这种情况,您可能希望在系统中包含某种登录。 (事实上​​,无论如何你都应该这样做。)

          您可以在 PermissionsValid 函数期间将条目写入某种日志(文件、事件日志、sql 表等)。这可以显示 IP 地址和传递的用户名以及完成时间的时间戳。这样你就可以看到是否有人试图“入侵”。

          您还可以在验证权限并记录用户发送的数据后在 MyWebMethod 函数中添加一些内容。通过这种方式,您可以知道是谁发送的、何时发送、从何处发送以及发送了什么。如果您想加倍努力,您甚至可以在进行任何更新之前记录数据。这将使您能够回滚任何恶意更改。

          【讨论】:

            【解决方案7】:

            假设如下:

            Browser <-(1)-> ASP/.NET App (`https://123.com/app`) <-(2)-> Web Service (`https://456.com/ws`)
            

            1) 通过证书交换 + 基本身份验证使用 ssl 保护 Web 服务。这样您就知道唯一允许的消费者是 .net 应用程序。

            2) 在 .net 应用程序上创建一个代理,例如 https://123.com/webservicecall,它将您的请求转发到 Web 服务。

            这样,您不会在 Web 应用程序的域之外进行调用,您会知道登录的用户,并且可以保护 ws 端点不被查看和访问。

            但实际上听起来您不应该使用代理,而是使用 ajax 调用 .net 应用程序,然后 .net 应用程序直接调用 Web 服务。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2015-05-12
              • 1970-01-01
              • 2011-05-04
              • 2012-01-17
              • 2017-06-14
              • 1970-01-01
              • 1970-01-01
              • 2023-04-11
              相关资源
              最近更新 更多