本篇内容介绍了“php表单安全中Token的实际应用”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
架起代理burpsuit开启准备大干一场，首先找到了一个表单的提交页面，表单主要采用Post方法进行提交，随便填了点数据就提交了。
通过burpsuit拦截下来之后看一下各个参数
通过Post提交到一个Task的action，看这么多参数万一有过滤不严格的情况方法说不定能出现一些XSS或者sql注入的漏洞于是就稍微看了一下就发送到了scanner。
Proxy放过之后页面却出现了异常提示Token验证不通过。
然后认真一看发现除了一些表单提交的参数外还有一个token=20e168c64ce1f1f98f89e4c8ff9e3aba的字段。表单提交之后response数据包当中也有一个新的token":"e40fe4b3afedc40f95903fef92eb79ed，这样导致这一个请求包只能请求一次，Burpsuit Scanner基于原有请求包的参数测试的扫描模式就基本上没有什么用了。
Token普遍有二个作用：
1.防止表单重复提交
2.anti csrf攻击（跨站点请求伪造）
由于token具有较好的随机性，不容易被猜测出来具有良好的安全性，于是看一下源码当中的实现。
通过请求的路径找到对应的php文件，当请求这个表单的时候会自动执行$label->token()这么一个方法
查看label.php的源码，token这个方法构造hidden表单定义了一个token的变量后赋值Core\Func\CoreFunc::$token
继续再查看CoreFunc的源码，包含了对token生成的过程
调用microtime生成毫秒数之后打散成数组增加随机性，通过substr提取数字与随机数相乘之后计算md5保证了token的不可预测性。
Token的随机性取决于当前时间、rand随机、md5散列算法
将生成的token存如session服务器会话当中
提交的表单主要由task.php处理task类当中只是读取了session中userid的字段，使用父类Content的 parent::action($jump, $commit)方法进行验证通过之后再处理表单数据。
一层又一层，感觉真复杂。Content类继承了Controller中的checkToken()检查
Token无论验证是否通过都会删除当前token的值保证了不会被重用
session应用相对安全但也繁琐，同时当多页面多请求时必须采用多Token同时生成的方法，这样占用更多资源，执行效率会降低。但是对安全性的提升是明显的，对于表单的重复提交、基于单个数据包的变形扫描、解决CSRF漏洞也不是一种不错的方式。
“php表单安全中Token的实际应用”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
