php中防止伪造跨站请求的小招式_php技巧

伪造跨站请求介绍
  伪造跨站请求比较难以防范,而且危害巨大,攻击者可以通过这种方式恶作剧,发spam信息,删除数据等等。这种攻击常见的表现形式有:
  伪造链接,引诱用户点击,或是让用户在不知情的情况下访问
  伪造表单,引诱用户提交。表单可以是隐藏的,用图片或链接的形式伪装。
  比较常见而且也很廉价的防范手段是在所有可能涉及用户写操作的表单中加入一个随机且变换频繁的字符串,然后在处理表单的时候对这个字符串进行检查。这个随机字符串如果和当前用户身份相关联的话,那么攻击者伪造请求会比较麻烦。
  yahoo对付伪造跨站请求的办法是在表单里加入一个叫.crumb的随机串;而facebook也有类似的解决办法,它的表单里常常会有post_form_id和fb_dtsg。
  随机串代码实现
  咱们按照这个思路,山寨一个crumb的实现,代码如下:

复制代码 代码如下:

<?php
class Crumb {
CONST SALT = "your-secret-salt";
static $ttl = 7200;
static public function challenge($data) {
return hash_hmac('md5', $data, self::SALT);
}
static public function issueCrumb($uid, $action = -1) {
$i = ceil(time() / self::$ttl);
return substr(self::challenge($i . $action . $uid), -12, 10);
}
static public function verifyCrumb($uid, $crumb, $action = -1) {
$i = ceil(time() / self::$ttl);
if(substr(self::challenge($i . $action . $uid), -12, 10) == $crumb ||
substr(self::challenge(($i - 1) . $action . $uid), -12, 10) == $crumb)
return true;
return false;
}
}

代码中的$uid表示用户唯一标识,而$ttl表示这个随机串的有效时间。
  应用示例
  构造表单
  在表单中插入一个隐藏的随机串crumb

复制代码 代码如下:

<form method="post" action="demo.php">
<input type="hidden" name="crumb" value="<?php echo Crumb::issueCrumb($uid)?>">
<input type="text" name="content">
<input type="submit">
</form>

处理表单 demo.php
  对crumb进行检查

复制代码 代码如下:

<?php
if(Crumb::verifyCrumb($uid, $_POST['crumb'])) {
//按照正常流程处理表单
} else {
//crumb校验失败,错误提示流程
}
?>

时间: 2024-09-19 09:44:59

php中防止伪造跨站请求的小招式_php技巧的相关文章

防止伪造跨站请求的小招式

伪造跨站请求介绍 伪造跨站请求比较难以防范,而且危害巨大,攻击者可以通过这种方式恶作剧,发spam信息,删除数据等等.这种攻击常见的表现形式有: 伪造链接,引诱用户点击,或是让用户在不知情的情况下访问 伪造表单,引诱用户提交.表单可以是隐藏的,用图片或链接的形式伪装. 比较常见而且也很廉价的防范手段是在所有可能涉及用户写操作的表单中加入一个随机且变换频繁的字符串,然后在处理表单的时候对这个字符串进行检查.这个随机字符串如果和当前用户身份相关联的话,那么攻击者伪造请求会比较麻烦. yahoo对付伪

php安全开发 添加随机字符串验证,防止伪造跨站请求_php技巧

yahoo对付伪造跨站请求的办法是在表单里加入一个叫.crumb的随机串:而facebook也有类似的解决办法,它的表单里常常会有post_form_id和fb_dtsg. 比较常见而且也很廉价的防范手段是在所有可能涉及用户写操作的表单中加入一个随机且变换频繁的字符串,然后在处理表单的时候对这个字符串进行检查.这个随机字符串如果和当前用户身份相关联的话,那么攻击者伪造请求会比较麻烦.现在防范方法基本上都是基于这种方法的了 随机串代码实现 咱们按照这个思路,山寨一个crumb的实现,代码如下: 复

php防止伪造跨站请求实现程序

浏览器的安全缺陷 现在的Web应用程序几乎都是使用Cookie来识别用户身份以及保存会话状态,但是所有的浏览器在最初加入Cookie功能时并没有考虑安全因素,从 WEB页面产生的文件请求都会带上COOKIE,如下图所示,Web页面中的一个正常的图片所产生的请求也会带上COOKIE: <img src="yun_qi_img/logo.jpg"> GET yun_qi_img/log.jpg Cookie: session_id 客户端 -------------------

[译] 跨站请求伪造已死!

本文讲的是[译] 跨站请求伪造已死!, 原文链接:Cross-Site Request Forgery is dead! 原文作者:Scott 译文出自:掘金翻译计划 译者:XatMassacrE 校对者:newbieYoung,DeadLion 跨站请求伪造已死! 在连续不断的被跨站请求伪造折磨了这么多年后,我们现在终于有了一个合理的解决方案.一个对网站拥有者没有技术负担.实施起来没有难度.部署又非常简单的方案,它就是 Same-Site Cookies. 和互联网历史一样悠久的跨站请求伪造

安全漏洞问题4:跨站请求伪造

安全漏洞问题4:跨站请求伪造 1.1. 漏洞描述 跨站请求伪造(CSRF)是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法.攻击者只要借助少许的社会工程诡计,例如通过电子邮件或者是聊天软件发送的链接,攻击者就能迫使一个Web应用程序的用户去执行攻击者选择的操作. 在跨站请求伪造攻击中,攻击者构造恶意URL请求,然后诱骗合法用户访问此URL链接,以达到在Web应用中以此用户权限执行特定操作的目的.和反射型XSS的主要区别是:反射型XSS的目的是在客户端执行脚本:CSRF的

让我们一起来消灭CSRF跨站请求伪造(上)

写在前面的话 现在已经是2017年了,想必大家一定知道什么是CSRF(跨站请求伪造)了,因为之前关于这个话题的讨论已经有很多了.这种漏洞已经存在了很多年,社区中也有非常详细的文档以及对应的解决方案,目前很多热门的网站开发框架基本上或多或少都实现了相应的缓解方案. 那我们在本系列文章中要讨论什么呢?请大家先思考以下几个因素: 遗留应用缺少CSRF保护; 某些框架的内置CSRF防护机制存在缺陷; 应用程序没有使用已证明安全的框架保护机制; 新的应用程序没有使用提供了CSRF保护功能的现代框架; 因此

跨站请求伪造(CSRF)攻击原理解析:比你所想的更危险

跨站请求伪造(Cross-Site Request Forgery)或许是最令人难以理解的一种攻击方式了,但也正因如此,它的危险性也被人们所低估.在"开放式Web应用程序安全项目"(OWASP)的榜单中,CSRF(又称XSRF)就位于前10的位置.简而言之,就是恶意软件强制浏览器在用户已认证的上下文环境中,执行原本并不需要的指令. 浏览器厂家深知这一危害,从而推出了某些类型的CSRF防护技术. 尽管如此,攻击者们的手段也在日益翻新,甚至结合多种类型的Web攻击以放大危害(比如XSS和S

《第三方JavaScript编程》——7.3 跨站请求伪造

7.3 跨站请求伪造 在第4章中,我们谈到了同源策略.该策略被所有浏览器支持,并防止不同来源的Web页面互相访问对方的方法和属性.你已经学到了一些技巧,使用这些技巧可以向你的服务器跨域发送消息.在本节中,我们将介绍利用该特性是如何转而对你进行攻击的. 跨站请求伪造(CSRF或者XSRF)是针对用户的另一种类型的漏洞.与XSS不同,XSS是将伪造的内容展现给用户,而XSRF利用的是Web应用程序与用户浏览器之间的信任.在本质上,易受XSRF攻击的Web应用都允许攻击者通过自己的网站诱导用户执行某些

CSRF(跨站请求伪造攻击)详解以及防护之道

CSRF(Cross Site Request Forgery, 跨站域请求伪造)是一种网络的攻击方式,该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作,有很大的危害性.然而,该攻击方式并不为大家所熟知,很多网站都有 CSRF 的安全漏洞.本文首先介绍 CSRF 的基本原理与其危害性,然后就目前常用的几种防御方法进行分析,比较其优劣.最后,本文将以实例展示如何在网站中防御 CSRF 的攻击,并分享一些开发过程中的最佳实践. C