简析XSS 与 CSRF 两种跨站攻击

XSS：跨站脚本攻击，注入攻击的一种。攻击者利用应用程序的动态展示功能，在HTML页面中嵌入恶意代码。当用户浏览该页时，这些嵌入在html的恶意代码就会被执行，用户浏览器被攻击者控制。。。。

1.盗取用户cookie,伪造用户身份

2.控制用户浏览器

3.结合浏览器及其插件漏洞，下载病毒木马到浏览者的计算机运行

4.衍生URL跳转漏洞

5.官网挂钓鱼网站

6.蠕虫攻击

CSRF：跨站请求伪造（冒充用户之手，伪造请求）。

-->横向提权（修改个人数据）；纵向提权（添加用户）；

XSSvsCSRF:XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。

严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。

例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问： http://example.com/bbs/create_post.php?title=标题&content=内容 那么，我只需要在论坛中发一帖，包含一链接： http://example.com/bbs/create_post.php?title=我是脑残&content=哈哈只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。

总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的，只能通过提高攻击门槛尽可能的防御。

针对表单比较可行的解决方案遵循三步：

1.在用户登录时，设置一个CSRF的随机token，同时种植在用户的cookie中，当用户浏览器关闭或者再次登录、退出时，清除token;

2.在表单中，生成一个隐藏域，它的值就是cookie中随机token

3.表单提交后，在web服务器端，判断表单中是token是否和用户cookie中的token一致，如果不一致或者为空，就判断为CSRF攻击。

 

当出现GET请求修改用户数据时，一旦在url中出现了csrftoken，当前页面就不允许出现用户定义的站外链接，否则攻击者可以诱惑用户点击攻击者定义的链接，访问在自己的网站，从refer中，获取url中的csrftoken。

 

http://blog.csdn.net/liushulin183/article/details/52613658