xss 攻击和 csrf 攻击浅显的理解

xss 攻击用通俗的语言表达就是：通过在数据中插入 js 代码，利用浏览器自动执行的特性，执行这些代码，达到破坏的目的。

举例，网页上有个文本框，后台接收网页的数据保存请求，将文本框内容保存下来，刷新页面予以展示。

若在文本框中输入了以下内容 

“<script>alert(2)  </script>”，保存到了后台，之后展示时，此数据被传到网页，在展示时，会把数据  <script>alert(2)  </script> 当成代码执行，弹出 2。

举一个更具破坏性的例子：

一个社交网站，攻击者可以录入文字让用户在登录网站之后看到，此时，攻击者就可以展开 xss 攻击，执行一段简单的代码就可以让客户无法正常使用网站。比如，强制登出，强制广告展示，弹窗。严重的甚至可以进行转账等更严重的伪造交易(csrf 攻击)。

关于 xss 攻击，还有一个特性是，如果服务器端返回的数据格式是 html/text 的方式，则只要返回了 “<script>alert(2)  </script>” 不管后面有没有把这个串放在文本框中去展示，都会被执行。如果数据格式是 json 方式，则不会，因为在解析时会被当成数据。然而，仍然会在展示时(如果有)被执行。

那么什么是 csrf 攻击呢？简单来说，就是前端网页多次使用同样的参数请求后端，每次都能成功地完成交易。这里有个转账的例子比较生动，

http://blog.csdn.net/stpeace/article/details/53512283

一个直观的感受就是，转账攻击之所以会成功，是因为仅仅通过一个链接，而没有使用其它的验证手段就可以访问。如果验证信息全部在 session 里面，且浏览器发起请求时，自动从 cookie 里面带上，一并发到服务器端，这个防护实际上不起任何作用，这种情况下只需要事先攻击，在网站上挂广告，引诱客户去点击，就可以在网站的“上下文”中发起请求，也就能够使用网站的 cokkie 了。

所以一种解决方法是，在转账链接后面手动添加一些参数达到分辨的目的。比如，可以在登记登录成功后，给他一个 token ,他可以放置于 cookie 中，然后在执行转账时，从 cookie 中取出这个 tooken ，添加到链接后面就可以做出一个只有他自己能做的转账操作。

但这是基于攻击者不能在网站上自由执行代码的假设。如果攻击者可以执行他自己的代码，他也就可以取出 cookie 里面的值，然后构造私有链接进行转账了。

也就是说，最可怖的是，把以上两种攻击方法一起使用，此时可能达到非常大的破坏。