跨站请求伪造
CSRF（Cross-site request forgery）攻击者盗用了你的身份，以你的名义发送恶意请求
攻击模式:要完成一次CSRF攻击，受害者必须依次完成两个步骤
- 登录受信任网站A，并在本地生成Cookie.
- 在不登出站点A的情况下，访问危险网站B.站点B中包含了伪造的可以请求站点A的恶意请求,此时可以利用A在浏览器中缓存的
cookie.
攻击实例
攻击情景
原文中Alice是受害者，她使用的一个银行网站http://unsafe/存在session fixation漏洞，Mallory是攻击者，他想盗窃Alice的银行中的存款，而Alice会点击Mallory发给她的网页连接（原因可能是Alice认识Mallory，或者她自己的安全意识不强）.
攻击步骤:
Hacker:Mallory访问http://unsafe/并获得了一个会话ID（session_id），例如服务器返回的形式是：Set-Cookie: session_id=0D6441FEA4496C2Hacker:Mallory给user:Alice发了一个邮件：“我行推出了一项新服务，率先体验请点击：http://unsafe/?SID=0D6441FEA4496C2”user:Alice点击并登录了.- 因为服务器的会话ID不改变，现在
Hacker:Mallory点击http://unsafe/?session_id= I_WILL_KNOW_THE_SID后，他就拥有了user:Alice的身份.可以为所欲为了.
防御:
应用自动为每个活跃的用户的会话生成一个 CSRF「令牌」.该令牌用于验证 经过身份验证的用户 是否是 向应用程序发出请求的用户.
无论何时，当您在应用程序中定义HTML表单时，都应该在表单中包含一个隐藏的CSRF标记字段，以便服务端CSRF过滤器可以验证表单中的CSRF令牌是否与会话session_id中存储的令牌相同,即使邮件中提前伪造了表单以及盗用了你的身份凭证session_id.但是他并不能伪造一个随即的的CSRF令牌.所以可以有效的预防上边的情况.除非你的终端被完全劫持.
根据上述实例,开发过程中两个关键的注意事项:
- 登陆成功以后要更新session_id,验证session_id格式是否合法.
- 接受到敏感操作时,不单单要验证身份凭证,同时也要验证
经过身份验证的用户是否是向应用程序发出请求的用户.否则session_id暴露就等于登陆权限完全暴露.
其它场景
攻击情景1：最简单：服务器接收任何会话ID.过程如下:
Hacker:Mallory发现http://unsafe/接收任何会话ID，而且会话ID通过URL地址的查询参数携带到服务器，服务器不做检查Hacker:Mallory给User:Alice发送一个电子邮件，他可能假装是银行在宣传自己的新业务，例如，“我行推出了一项新服务，率先体验请点击：http://unsafe/?SID= I_WILL_KNOW_THE_SID, I_WILL_KNOW_THE_SID是Hacker:Mallory选定的一个会话ID。User:Alice被吸引了，点击了http://unsafe/?SID= I_WILL_KNOW_THE_SID，像往常一样，输入了自己的帐号和口令从而登录到银行网站。- 因为服务器的会话ID不改变，现在
Hacker:Mallory点击http://unsafe/?SID= I_WILL_KNOW_THE_SID后，他就拥有了User:Alice的身份。可以为所欲为了。
攻击场景2：跨站cookie(cross-site cooking).利用浏览器的漏洞，即使 http://good 很安全，但是，由于浏览器管理cookie的漏洞，
使恶意网站 http://evil/ 能够向浏览器发送http://good的cookie`。过程如下：
Hacker:Mallory给User:Alice发送一个邮件"有个有趣的网站：http://evil很好玩，不妨试试"User:Alice访问了这个链接，这个网站将一个会话ID取值为I_WILL_KNOW_THE_SID的http://good/域的cookie设置到浏览器中。Hacker:Mallory又给User:Alice发了个邮件：“我行推出了一项新服务，率先体验请点击：http://good/”- 如果
User:Alice登录了，Hacker:Mallory就可以利用这个ID了