什么是CSRF攻击
由于所处的项目是新项目为了防止CSRF攻击，在后端上加入CSRF的防范攻击措施，那么很多同学就好奇什么是CSRF攻击，下面是关于CSRF的解释：
Cross-Site Request Forgery (CSRF) is an attack outlined in the OWASP Top 10 whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.（英文好的同学可自行理解，稍差的同学可以Google翻译理解）
简而言之，跨站点请求伪造(CSRF)指的是一种通过一种恶意的数据挟持去访问第三方的网站攻击技术。举一个例子，小A登录网银进行了相关账号操作（如下图），而此时他登录第三方的恶意网站，执行的恶意脚本会伪造出一个假冒的对网银网站的请求（转账、汇款等），而网银网站无法识别此次请求的来源是一个非用户的行为，所以会给网络信息带来极大的安全隐患。归根结底，CSRF攻击的本质是攻击者伪造了合法的身份，对网站系统进行访问和操作。如果能够识别出访问者的伪造身份，也就能识别CSRF攻击。因此网站设计开发时如何防止CSRF攻击成为了一个重要的安全保障。
如何应对CSRF攻击
通常有以下两种种常见防范CSRF攻击的方式：
1，运用token作为用户与网站的“请求令牌”，实现策略十分简单，服务器在每次新用户方位此网站的时候生成一个伪随机序列token值，存入浏览器cookie当中，然后在之后的所有请求中把该token以隐藏域的形势存入到http或https请求当中，而每一次请求服务器端都会验证两边（request中token和后端保存的token）的token是否一致，只有一致的时候才会接后续关处理请求，否则返回HTTP 403页面拒绝登录或者要求用户重新登录并分配新的token值
缺点：
尽管采用token的方式的安全保障已经基本防止了csrf攻击的可能性，但是没有网站有绝对安全的防御，一旦恶意用户通过XSS等方式获取了存储在浏览器中的cookie中，再利用cookie中隐藏的token信息实现攻击。所以在不可能根本解决恶意攻击的前提下，如何提高攻击者的成本则成了重中之重
2，验证HTTP referer信息。http请求中报头有一个字段为referer，该字段信息记录的这个请求的来源地，在通常情况下访问一个安全受限页面的请求必须来自同一个网站，如果一个攻击者发起恶意攻击时，被攻击网站可以根据referer上的字段信息过滤掉非本站的请求，如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
缺点：
如果攻击者设定正确HTTP referer信息，则所有的恶意请求都会被通过，所以这种防范策略基本属于鸵鸟政策，不建议采纳。
web项目中如何加入防范CSRF攻击策略
一个新用户登录本网站时都会被分配一个伪随机字符串作为csrf token，而后所有的操作请求都会将这个token值作为传入参数加入到request当中。
而这个token值只有在以下情况才会更新：
1，用户第一次登录网站时，会被赋予一个token值
2，token值得时效为30分钟，超出时效后端重新分配
3，本地cookie中存储的token被清空时并再访问网站，后端重新分配
在开发原来定义的登录接口中，登录时我们向/api/vi/member/login的post登录数据，但是在实际登录中如上图加入了query string parameter =
“netease_ct=37353219bd824989a500d8b96d094576"用来标记每次用户的token，一旦调用接口时传入的token值失效或者为空时，后端都就判定是一次无效的url访问，并返回给前端，这样也就杜绝了CSRF攻击（前提是第三方网站无法获取本地cookie存储的token值）
如何在接口测试中模拟登录
以上我们知道了web项目中如何应对CSRF攻击，但是接口测试工程模拟的http或https请求与浏览器中发起request请求最大的不同就是浏览器中保存的本地cookie，而此cookie可作为request header可继续作为参数代入后面对的request当中，其中包含了防范csrf最重要的token值。但是java写的接口测试本无保存cookie，所以在依赖httpclient时发起的每一次模拟请求中当中是不包含token信息的，那么作为后端接收到的每一次request都是来自不同用户，并分配了不同的token值，所以我们需要使每一次页面访问都包含正确统一的token信息，使得后端可以判断多次的请求都来自同一"用户"。
以上我们知道了web项目中如何应对CSRF攻击，但是接口测试工程模拟的http或https请求与浏览器中发起request请求最大的不同就是浏览器中保存的本地cookie，而此cookie可作为request header可继续作为参数代入后面对的request当中，其中包含了防范csrf最重要的token值。但是java写的接口测试本无保存cookie，所以在依赖httpclient时发起的每一次模拟请求中当中是不包含token信息的，那么作为后端接收到的每一次request都是来自不同用户，并分配了不同的token值，所以我们需要使每一次页面访问都包含正确统一的token信息，使得后端可以判断多次的请求都来自同一"用户"。
应对措施：
所以在接口测试中，作者提前模拟了一次http网站请求，将第一次访问时分配的token值（cookie中netease_ct的value）保存下来
而保存下来的token值作为request header中的cookie项，用来标记每一次的用户请求都是来自同一个”用户“，完整的示意图如下
同时所获取的token值也要放入每次相关请求的url中，例如https://k12.study.163.com/api/v1/member/login?netease_ct=37353219bd824989a500d8b96d094576中
通过testng的模拟登录接口测试，可以发现这种SET COOKIE的方式可以实现”动态"登录（动态指的是因为每次的url中query string parameter不同）
结论
CSRF攻击作为一种常见的互联网攻击措施给用户的数据（特别是信息账号）带来极大的安全隐患，因此引入了基于token值得防范措施，其策略基本可以概括为
利用分配的随机token值作为用户访问标识，并过滤掉一切token值过期或无效的页面访问。
因此在基于testng的接口测试项目中，先通过发送一个网站访问获取到分配的token值，再将token值作为cookie中的参数保存，并代入登陆后的所有页request
结果证明通过基于testng的接口测试模拟登录结果可以实现防范CSRF攻击，明显提高了网站的安全性和可靠性。
