防止CSRF攻击的实际操作流程精简版

以下的文章主要描述的是正确防止CSRF攻击的实际操作流程，我在一个信誉度很好的网站找到一个关于正确防止CSRF攻击的实际操作流程的资料，拿出来供大家分享，以下就是文章的详细内容介绍，望大家借鉴。　

1.Hello World

欢迎来到崭新的Playhack.net的新季度开题项目报告。我非常高兴您能够再次回来让我们的c001项目重现。

希望您能喜欢这个新的短篇论文，我邀请你浏览位于http://www.playhack.net的全部新项目。

开始：几乎没有什么，只是一点香烟!:

呐喊：我向我的playhack m8s null,omni,god and emdel,ofc o str0ke大声呐喊!NEX 回来了。

2.介绍

我对跨站请求伪造(Cross Site Request Forgery，即CSRF)技术有一定研究，但是对网站开发者应当采取的措施研究不深。这些日子在编写一个对用户和管理员(这些人对他们的任务并不明晰:P)有高度安全要求的分布式网站程序时，我被这个话题深刻的纠缠了。

针对这种情况，我必须考虑程序最终可能受到的各个方面的可能的攻击威胁。

给我最多麻烦的就是Session欺骗(或者CSRF，你可以按照自己喜欢的方式称呼)，因为这种攻击是完全以用户的身份，因此并没有百分百的可能性来防止它。

如果你对我刚才说所的Session欺骗并不太了解，那么你可以阅读：http://www.playhack.net/view.php?id=30

3.可行措施

Ok，从这里开始，我必须假定你对Session欺骗攻击的实施方法已经深刻领会了:P

让我们开始新的继续。

考虑到一个已经登录到网站的受信用户可以完成一些重要的或者私密的操作，攻击者尝试记性一个可能的登录攻击(但是大多数情况下是不可行的)并且得到已经登录用户的Session来实现其巧妙的行为。

为了劫持用户的Seession，入侵者精心构造一个适当的网页，在这个网页中包含了隐藏的JavaScript函数来重新创造一个原始操作表单，但是攻击者却修改了一些表单值，然后攻击者让受攻击者访问该页面，此时页面加载过程会提交上述表单到一个远程页面，以隐秘地完成一个请求(此时受攻击者并不知道)，他们用这种方法利用了用户的受信身份。

这种方式简单解释了Session欺骗攻击是如何工作的，但是一个重要的问题是，“我如何避免我的用户成为这种攻击的受害者?”

现在，你可能想到如下的几种方法：

检查Cookies凭据

检查HTTP请求来路

使用验证码

但是经过一些尝试，你会发现这些方法不是我们应当采取的最合适的解决方式，让我们一个个的来看为什么。

3.1 Cookies Hashing

第一个方案可能是解决这个问题的最简单和快捷的方案了，因为攻击者不能够获得被攻击者的Cookies内容，也就不能够构造相应的表单。

这个问题的实现方法与下面的类似。在某些登录页面我们根据当前的会话创建Cookies：

// Cookie value

$value = “Something from Somewhere”;

// Create a cookie which expires in one hour

setcookie(”cookie”, $value, time()+3600);

?>

在这里，我们在Cookies中使用了散列来使得这个表单可被认证。

以上的相关内容就是对防止CSRF攻击的实际操作流程的介绍，望你能有所收获。