重要声明

        进行任何程度的非授权CSRF攻击都属于违法行为！！！

CSRF概念

        Cross-Site Request Forgery 跨站请求伪造 —— 通过伪造成被授权用户对授权服务器开展非法行为，如获取资料、修改/删除资料、造成服务瘫痪等。

准备工作

        postman / 自建服务器(jsp为例)

实录

        首先登录自建服务，在默认使用Session的情况下java(php / .net / python / node / ...) web会通过在Response中设置一个HttpOnly的cookie项sessionID

sessionID

并且会自动加入RequestHeader中，用来标识后续的请求是登录人所发起

后续请求

HttpOnly表示无法通过页面脚本来获取该cookie项，所以也无法通过一个AJAX请求来进行CSRF。相反，CSRF使用更简单的方式 —— 一个隐藏form。

隐藏表单

只要在相同浏览器中，打开另一个页签

伪装按钮

不仅可以伪装成按钮，还可以是图片、链接等，只要能触发form发送的都可以

CSRF攻击成功

可以看到，CSRF请求头中自动包含了sessionID，并且成功拿到了返回数据。

请注意，不要进行CSRF攻击，同时防止被钓鱼！

怎么办？

本质上，无论哪种鉴权方式都存在安全隐患，只是发生和未发生的区别，不然OAuth为什么要出2.0？这里列举一些防止办法仅供参考：

使用payload —— 传统form方式无法提交payload格式请求体，比如刚才的demo，我们换成payload提交，那就会出现400错误，因为服务器只接受payload格式

400请求参数错误

但这只能处理网页CSRF，如果使用工具依然可以进行操作

postman发送请求

postman可以伪造cookie

伪造cookie

验证请求头中的Referer —— 在服务端进行请求源的验证，但存在伪造的可能性

停用cookie —— 使用token，服务端每次返回都在ResponseHeader中加入验证码，并在后续请求中读取header进行验证，或者使用URI重定向返回token。而这一类方式已经有成熟的方案比如OAuth、基础/数字验证、等。

最后

无论使用何种前置安全措施，都不要忘记做数据权限的验证！！！