【问题标题】:Securing POST data in web application保护 Web 应用程序中的 POST 数据
【发布时间】:2010-11-27 21:52:55
【问题描述】:

我有一个具有基本身份验证的 Web 应用程序 - 用户名、密码、会话和其他内容。但是,我特别需要防止用户欺骗 POST 请求(即使对于已登录的用户)。在我的应用程序中,我在接受 POST 数据之前专门验证用户的会话(还要处理 XSS 和其他东西)。

喜欢:

if(user session exists)
{
    // handle the data POSTed
}

else {
   // ...
}

我将会话 ID 存储在数据库中。还有什么我应该注意的以防止虚假 POST 请求还是足够了?

【问题讨论】:

    标签: security web-applications http-post


    【解决方案1】:

    您可以尝试为每个发布请求生成发布密钥。显示发布请求有效并从您页面上的表单执行的附加参数。

    【讨论】:

      【解决方案2】:

      如果您在用户浏览器中使用 Javascript 构建有效的 POST 请求,则您无法阻止确定的用户向您的服务器提交虚假 POST。用户有一个有效的会话 ID,他可以使用它来发出 POST 请求。他还可以访问所有代码以及代码可以访问以构建请求的所有其他数据。

      您不能依赖浏览器端代码来保护您的系统。必须在服务器上强制执行安全性。例如,对对象的所有操作都应该经过身份验证和授权。

      【讨论】:

      • +1 表示“必须在服务器上实施安全性”。这句话说得再多也不为过。
      【解决方案3】:

      在我当前的应用程序中,我有一些代码被发送到浏览器,然后浏览器回发并且不能修改它。我所做的是将一个秘密字符串附加到该值,获取该完整字符串的 SHA1 校验和,然后要求浏览器发送回该值和校验和。我很确定 .NET 也是这样处理视图状态的。

      【讨论】:

        【解决方案4】:

        如果用户会话是长期存在的,您仍然容易受到XSRF 的影响。您也需要对此采取措施。

        如果您使用 .NET,请查看 AntiForgeryToken,

        http://msdn.microsoft.com/en-us/library/dd492767.aspx

        【讨论】:

        • anti-forgery-token 仅仅意味着该页面是从以前的 GET 中发布的,这限制了基本的欺诈性 POST。任何种类的屏幕录像机都可以录制/播放这些页面。
        【解决方案5】:

        在接受用户输入时,在将内容存储到数据库之前,您需要做的零级事情是确保您通过 mysql_real_escape_string($MyPostData) 函数运行数据。

        此外,您希望通过 POST 接受的每个变量/数据都可以根据其类型和您打算对其执行的操作以编程方式对其进行验证。

        这是确保没有来自用户的“有趣”业务的两个主要规则:确保您使用有效的变量以及确保进入数据库的数据得到正确验证和转义。

        【讨论】:

          【解决方案6】:

          使用CAPTCHA 图像。

          Web 建立在 REST 之上,根据定义,这就是将状态从一个点转移到另一个点。有足够时间的人可以制作模拟活动会话的 POST 请求。

          与所有安全请求一样,CAPTCHA 在服务器端进行验证。

          【讨论】:

            【解决方案7】:

            使用您的模型(尤其是如果您使用整数作为会话 ID),攻击者可以轻松地代表另一个用户提交请求(例如,减少您自己的会话 ID,并且您已经是其他人,前提是此会话 ID 存在) . 您需要有一个与每个会话 ID 相关联的唯一会话密钥/guid,并存储在数据库和客户端的 cookie 中。每次您的客户提交请求时,您不仅应该阅读会话 ID,还应该阅读会话 GUID,然后根据您的数据库值验证它们。 除此之外,您可能还需要考虑一些 XSRF 缓解策略。

            【讨论】:

              【解决方案8】:

              我在接受 POST 之前专门验证用户的会话

              如果您的意思是“会话”的通常含义:存储在 cookie 中的持久性令牌,用于识别用户和相关会话数据,那么不,这还不够。即使 POST 请求是由另一个(攻击者)站点引发的,该 cookie 也会由浏览器自动发送。

              您在此处查找的关键字是 Cross-Site Request Forgery 或 XSRF,攻击者可以在其中(通过脚本或其他方法)使经过身份验证的用户向您的站点发出 GET 或 POST 请求。此类请求通常无法与合法请求区分开来。 (有些人尝试通过检查 HTTP 引用数据来这样做,但这是不可靠的。)

              这些攻击不像服务器端(SQL、命令)或客户端(HTML、JavaScript)注入那样具有直接破坏性,但它们比两者都更常见:不幸的是,很少有 Web 程序员同时包含适当的对策.直到他们的网站受到 XSRF 漏洞的影响。

              有多种方法可以防御 XSRF,但唯一真正有效的方法是在每个可提交表单中包含一个第三方攻击者不会知道的秘密值。正如 Eimantas 所提到的,这通常被称为 post 键。

              有多种方法可以生成此类秘密信息。一种简单的方法是将随机生成的代码添加到每个用户的帐户详细信息中,然后将其放入表单的隐藏字段中并检查其是否存在于提交中。例如在 PHP 中:

              <form method="post" action="delete.php"><div>
                  <input type="hidden" name="key" value="<?php echo(htmlspecialchars($user['key'])); ?>"/>
                  <input type="submit" value="Delete" />
              </div></form>
              
              if ($_POST['key']!=$user['key'])
                  // error
              

              攻击者不知道该用户的密钥,因此无法创建包含它的链接/表单。

              您还可以使用服务器密钥对用户 ID 使用加密哈希函数,而不是保留单独的代码。使用哈希,您还可以输入其他内容,例如到期时间,以便必须在特定时间范围内提交表单。或者您可以生成一次性交易密钥,您也可以使用它来确保您不能两次提交相同的表单(用于停止重复发布)。

              【讨论】:

                猜你喜欢
                • 2015-03-11
                • 2010-12-15
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                相关资源
                最近更新 更多