Question

希望加强安全性并防止跨站点请求伪造攻击。理解表单的标记化，但对对象实例不太清楚。

根据OWASP漏洞利用标准包括：1。需要对Web用户进行身份验证; 2. CSRF攻击专门针对状态变更请求。

问题： 我有面向公众的照片库，内容包含数据库驱动的内容。应用程序使用数据库进行身份验证，但不是Web用户。

在初始页面加载（初始状态）时，查看器（HTML）从应用程序请求缩略图图像的灯箱。 Web用户单击缩略图以加载与库关联的图像。 click事件重新加载将GET变量（gallery id）传递给控制器脚本的页面。控制器创建params数组的新实例。

应用程序启动会话，但不启动查看器html。

以下是应用程序的公共接口，其他所有内容都受保护或私有。

viewer.php

 /* 
  * class params 
 */
if( isset($gid) && $gid!=null ) {
  /* show project gallery images */
  $params['ticket'] = "gallery";
  $params['active'] = "Y";
  $params['gid'] = $gid;
} else {
  /* show lightbox thumbnails */
  $params['ticket'] = "lightbox";
  $params['active'] = "Y";
}
/* later in html body, instance object */
  $cObj = accesswrapper::factory($params);
  $cObj->jobrequest();
  unset($params);
  unset($cObj);

factory.php

 /**
 * @api
 * @return void
 * instantiates the sub class passed from viewer
 * 
 * @param array $params, [ticket] subclass name
 * pforeman, object interface
 */
 class accesswrapper {
    public static function factory($params) {

        $ticket = $params['ticket'];

        switch($ticket) {  //route to appropriate sub class
          case $ticket=="lightbox":
            $inst = new lightbox($params);
          break;
          case $ticket=="gallery";
            $inst = new gallery($params);
          break;        
        }

      if ($inst instanceof pforeman) {
        return $inst;
      } else {
        return void;
      }
     }
    }

问题： 这个过程需要一个令牌吗？这会足以阻止CSRF吗？

Answer 1

如果请求只进行了一些简单的更新，您就不必担心CSRF（更多关于“琐碎更新”的定义）。在典型的CSRF攻击中，您有：

用户使用网站cookie登录网站A.
在同一浏览器会话中，用户访问网站B.
网站B会导致浏览器访问网站A上的某些网址。
网站A回应认为来自用户的请求。

由于原始政策相同，网站B无法看到访问的响应;它只能导致访问发生。因此，如果请求仅进行简单的更新，则用户的浏览器将在访问站点B时显示来自站点A的内容，但我们知道用户仍有权查看该数据，因为站点A否则将拒绝该请求。

用户可能会有点吓坏，请致电网站A支持，无论如何，但没有数据泄露。

如果请求不仅仅是微不足道的更新，那么网站B已经导致用户在网站A上采取行动而不是他们的意图。对于用户和站点A来说非常糟糕。

如果没有CSRF保护，那么琐碎的更新是安全的。其他一切都需要保护。

“琐碎的更新”对不同的网站意味着不同的东西。例如，更新某人的银行余额显然不是微不足道的。但是在数据库中记录获取平衡请求是一项微不足道的更新吗？如何执行耗时的查询？您的网站的技术和业务模型将确定您认为琐碎更新的内容，并且可以接受不受CSRF保护，以及您认为必须保护的内容。

在您的应用身份验证模型中，但不是用户身份验证，您无需担心CSRF，因为所有访问都是公开的。

最后需要注意的是，在注销功能上不添加CSRF保护通常是个好主意。这有助于确保用户始终可以注销，即使CSRF验证中发生错误也是如此。也就是说，这样做的风险在于，站点B可以强制从站点A注销用户。您必须选择对您最有意义的内容。

跨站点伪造（CSRF）和公共应用程序接口

1 个答案: