上面我转载了两篇关于ThinkPHP token验证的文章（ThinkPHP中的创建方法和手动token验证）。 里面提到了token，这里转载另外两篇文章来了解一下token的作用。
（网络安全的token，网络安全的CSRF攻击）
网络安全令牌
参考：
Token就是代币，它最大的特点就是随机性和不可预测性。 一般黑客或软件很难猜测。
那么，Token有哪些作用呢？ 原理是什么？
Token通常用在两个地方：
1）防止重复提交表单，2）anticsrf攻击（跨站请求伪造）。
两者原则上都是通过sessiontoken来实现的。 当客户端请求页面时，服务器会生成一个随机数Token，将Token放入Session中，然后将Token发送给客户端（通常通过构造隐藏表单的方式）。 下次客户端提交请求时，Token会连同表单一起提交给服务器。
那么，如果应用于“anticsrf攻击”，服务器会验证Token值，判断是否与会话中的Token值相等。 如果相等，则可以证明该请求是有效的并且不是伪造的。
但如果应用于“防止表单重复提交”，服务器会在第一次验证相同后更新Session中的Token值。 如果用户重复提交，则第二次验证判断会失败，因为用户提交的表单中的 Token 没有改变，但服务器端会话中的 Token 已经改变了。
上面的session应用比较安全，但是也比较复杂。 同时，当请求多个页面、多个请求时，必须同时生成多个Token，占用较多资源，降低执行效率。 因此，sessionToken也可以替换为cookie存储认证信息。 例如，处理“重复提交”时，第一次提交时，已经提交过的信息会被传输到cookie中。 当第二次提交时，第二次提交会失败，因为cookie已经有提交记录了。
然而，cookie存储有一个致命的弱点。 如果cookie被劫持（xss攻击可以轻松获取用户cookie），则再次gameover。 黑客将直接实现csrf攻击。
因此，安全和效率是相对的。 让我们来处理具体问题。
另外，为了防止“添加token但不校准”的情况，在session中降低token，但服务器并没有验证token，所以根本没有防范作用。
还需要注意的是，数据库的增删改查都需要token验证。 对于查询操作，不得添加token，防止攻击者通过查询操作获取token进行csrf攻击。 但这并不是说攻击者获取代币困难，只是降低了攻击成本。
Web安全的CSRF攻击
什么是 CSRF？
CSRF（CrossSiteRequestForgery），中文是跨站请求伪造。 当用户已经登录目标网站后，CSRF攻击者引诱用户访问攻击页面，利用目标网站对用户的信任，向目标网站发起伪造用户操作的请求。攻击页面作为用户达到攻击的目的。
举一个简单的反例：
如果博客园有加关注的GET套接字，则blogUserGuid参数显然就是关注者的Id，如下：
然后我只需要在我的一篇博客文章的内容上写一个 img 标签：
那么只要有人打开我的这篇博文，就会手动关注我。
升级版：
如果博客园里还有加关注的socket，但是已经被限制只能获取POST请求的数据了。 这时，制作一个第三方页面，但其中包含表单提交代码，然后通过QQ、电子邮件等社交工具进行传播，引诱用户打开，打开博客园的用户就会被中招。
在讲例子之前，需要纠正一个iframe的问题，有些人会直接把这个写在第三方页面上。 如下：
CSRF SHOW
document.forms.form1.submit();
这是个问题。 由于同源策略，iframe内容根本无法加载，所以上面的表单提交实际上不会被执行。
PS：我试过chrome、IE11、Firefox，都是一样的。
所以可以通过再嵌入一层页面来解决，如下：
第一显示页面（测试）：
CSRF SHOW
第二个隐藏页面（test2）：
CSRF GET
document.forms.form1.submit();
这样就可以解决问题。 有人可能会问为什么要额外加一层iframe，因为不嵌入iframe的话页面会被重定向，这样就降低了攻击的隐蔽性。 另外，我们的测试页面没有使用XMLHTTPRequest发送POST请求，因为存在跨域问题，而表单可以跨域发布数据。
进阶版：
如果博客园还有加关注的socket，POST已经被限制，但是博文的内容直接粘贴到HTML中（未经过滤），那么就会受到XSS攻击。 然后你可以直接将代码嵌入到博文中，这样只要有人打开我的博文，他们仍然会手动关注我。 这种攻击组合称为 XSRF。
CSRF攻击的本质
CSRF 攻击是一种始于 Web 的隐式身份验证机制！ Web的认证机制实际上可以保证请求来自用户的浏览器，但不能保证该请求得到用户的批准。 CSRF攻击通常由服务器解决。
针对 CSRF 工具的防御
1. 尽量使用POST，限制GET
GET 套接字太容易被用作 CSRF 攻击。 看第一个例子，只需要构造一个img标签即可，而img标签是无法过滤的数据。 最好限制该接口的使用为POST，GET无效，以降低被攻击的风险。
当然，POST 并不是万无一失的。 攻击者只需构造一个表单，但需要在第三方页面上完成，降低了暴露的可能性。
2. 浏览器 Cookie 政策
IE6、7、8、Safari默认会阻止发送第三方本地cookie（Thirdparty Cookie）。 但Firefox2、3、Opera、Chrome、Android等都不会拦截，所以通过浏览器cookie策略来防御CSRF攻击并不可靠，只能说增加了风险。
PS：cookie有两种，SessionCookie（浏览器关闭后会失效网站程序被攻击，保存在显存中），Third-partyCookie（即过了Exprie时间才会失效的cookie，这种cookie 将保存在本地）。
PS：另外，如果网站返回包含P3PHeader的HTTP标头，浏览器将被允许发送第三方cookie。
3.添加验证码
验证码，强制用户与应用程序交互以完成最终请求。 总的来说，验证码可以很好的防止CSRF攻击。 但为了用户体验网站程序被攻击，网站无法对所有操作添加验证码。 因此，验证码只能作为辅助手段，不能作为主要解决方案。
4. 推荐人检查
RefererCheck在网络上最常见的应用就是“防止图片盗链”。 同理，RefererCheck也可以用来检测请求是否来自合法的“来源”（Referer值是否是指定的页面，或者网站的域名），如果不是，那么很可能是CSRF攻击。
但由于服务器无法时刻获取Referer，因此很难将其作为CSRF防御的主要手段。 但使用RefererCheck来监控CSRF攻击的发生是一种可行的方法。
5. 反CSRF Token
现在业界对于CSRF的一致防御是使用Token（AntiCSRFToken）。
例子：
1. 用户访问表单页面。
2、服务器生成Token，放入用户的Session或者浏览器的Cookie中。
3. 将Token 参数附加到页面表单中。
4、用户提交请求后，服务器验证表单中的Token与用户Session（或Cookies）中的Token是否一致。 如果一致，则为合法请求，如果不一致，则为非法请求。
这个Token的值必须是随机的且不可预测的。 由于Token的存在，攻击者无法构造带有有效Token的请求来执行CSRF攻击。 另外，在使用Token时，应注意Token的保密性，尽量将敏感操作从GET改为POST，并以表单或AJAX方式提交，避免Token被盗。
注意：
CSRF Token仅用于对抗CSRF攻击。 当网站同时存在XSS漏洞时，那么这个解决方案也是一句空话。 因此，XSS带来的问题应该通过XSS防御方案来解决。
总结
CSRF攻击是攻击者使用用户身份来操作用户帐户的一种攻击形式。 AntiCSRFToken通常用于防御CSRF攻击。 同时要注意Token的保密性和随机性。
参考：
1.《浅谈CSRF攻击方式》
2.《白帽谈网络安全》
本文为原创文章，转载请保留原始出处，方便追查，如有错误，谢谢原谅。
目前，越来越多的服务器被入侵，攻击频繁发生，如数据泄露、数据库篡改、用户数据被脱裤子、网站被迫跳转到恶意网站、百度中的网站快照被绑架等。攻击和疾病层出不穷。 当我们的服务器被攻击、黑客入侵时，我们首先应该如何处理呢？
如何查看服务器被黑客攻击的痕迹？ 有没有紧急的解决方案，在不影响网站访问的情况下，很多客户出现上述攻击的时候，就来找我们赛恩安全来解决服务器被攻击的问题。 我们正弦安全工程师总结了一套自己的方法分享给大家，希望大家能够尽快解决服务器被黑的问题。 有的客户遇到这些情况时，首先想到的就是先关闭服务器网站程序被攻击，通知机房拔掉电源，有的干脆先关闭网站。 这种措施只能先解决当前的问题，但不能解决问题的症结，所以当服务器被封锁、攻击成功的情况下，我们应该详细检查日志，以及攻击的痕迹。入侵，回溯，找到漏洞，找出服务器在哪里被成功攻击。
首先，我们应该从以下几个方面入手：
检测服务器进程是否为恶意进程，以及管理员账号是否被恶意减少，检查服务器端口，是否有开放的冗余端口，然后检查服务器的登录日志，服务器的默认启动项是启用、服务和定时任务，检测网站是否存在木马侧门，服务器系统是否感染病毒。
如何查看进度？ 打开服务器，cmd命令下输入tasklis，或者右键任务管理器查看进程，点击显示所有用户的进程。 我们综合分析，内存占用大网站程序被攻击，CPU占用大。 查看哪些进程在不断使用，就可以大致判断是否存在异常进程。 一般来说，系统侧门是加载到进程中的。 要查看进程的详细信息，可以使用PID来查看，然后使用命令findstr来查找进程。 被调用的文件就存储在那里。 截图如下：
下一步是检查系统中是否存在其他恶意管理员帐户。 在cmd命令下输入netuser会列出当前服务器中的所有账户。 还可以通过注册表查看管理员账户是否被减少。 注册表需要在命令中输入egedit打开注册表，找到HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNames可以看到所有帐户名。 截图如下：
端口检测，比如一些客户服务器经常被攻击，比如3306数据库端口，21FTP端口，135、445端口，1433sql数据库端口，3389远程桌面端口，是否对外开放，这个端口是否开放对外界来说，很可能利用漏洞攻击、入侵、账号密码弱口令、部分数据库中root账号密码为空、FTP可以匿名连接等，这些都可能导致服务器被入侵。 有的密码还是123456、111111等。 应更改远程桌面的端口，尽可能防止攻击者通过暴力破解的方式登录服务器。 在这里可以对远程登录进行安全验证，限制IP、MAC、计算机名，大大加强了服务器的安全性。 还需要检查服务器的登录日志，看看日志中是否有被清除的痕迹，以及服务器被恶意登录的日志记录。一般来说，很多攻击者都会登录服务器，并且登录日志肯定会留下。 您可以了解丰茂682。
接下来需要检测服务器的启动项、服务、计划任务。 通常，攻击者加壳入侵服务器后，会在服务器中植入木马侧门，同时也会插入到启动项、计划任务或服务中。 去吧，混淆成一个系统服务，让管理员很难检测到，用msconfig命令查看服务器。
以下是注册表中需要检查的一些项目：
HKLMSoftwareMicrosoftWindowsCurrentVersionRunServices
HKLMSoftwareMicrosoftWindowsCurrentVersionRunHKEY_CLASSES_ROOTexefileshellopencommand
HKLMSoftwareMicrosoftWindowsCurrentVersionRunOnce
最重要的是对服务中的网站代码进行安全检查。 对比之前网站的备份文件，看看是否有可疑的代码文件。 图片格式可以忽略，主要是asp、aspx、php、jsp等脚本执行文件，检查代码看看是否存在带有eval等特殊字符的一句话木马webshell，还有可能是一些加密文件网站木马文件，网站的首页代码，标题描述，是否加密，有一些你看不到的字符，这通常是网站被入侵了，服务器被一步步攻击。
对被入侵服务器的整体攻击如上所述。 还有一些服务器和环境上安装的软件，如apache、trust2、IIS环境漏洞，都会导致服务器被入侵。 如果网站被篡改，一定要检测网站的漏洞，是否存在sql注入漏洞、文件上传漏洞、XSS跨站漏洞、远程代码执行漏洞，多方向排查服务器入侵攻击问题。 如果你对服务器不太了解，可以找专业的网络安全公司来处理。 海外的sinesafe、启明星辰、绿盟科技都比较不错。 以上是我们自己日常处理客户服务器的一套方法。 找到问题，进行追溯，彻底避免服务器被黑客攻击，将损失降到最低。 每个客户服务器的安装环境，以及代码的编译方式都不同，根据实际情况排查问题并解决。
