一，xss
xss:（Cross Site Scripting），跨站脚本攻击；a. 其原本缩写是 CSS，但为了和层叠样式表(Cascading Style Sheet)有所区分，因而在安全领域叫做 XSS;b. 是攻击者利用漏洞。在客户端（浏览器）注入恶意脚本代码。做些非法的事情。c. XSS攻击可以分为3类：反射型（非持久型）、存储型（持久型）、基于DOM。复制代码
- 反射性
a. 顾名思义，用户被诱导点击一个恶意链接。如：http://xxx?keyword=；b. 网站给受害者的返回中包含了来自URL的的恶意文本；c. 网站给受害者的不正常的网页，恶意文本会马上在浏览器执行，做些攻击者想做的事情，如：获取cookie等；即：浏览器发送给服务器，服务器又反射回到浏览器并执行脚本；故个人理解叫反射型攻击；复制代码
- 存储型
a. 同样根据名字来理解。攻击者通将数据http://xxx?keyword=提交到后台服务端；b. 后台服务端在不校验的情况下。将keyword=这个数据存入DB;C. 其他正常用户在正常访问这个网站时，得到DB的非法脚本，并执行。做些非法的事情；这个和反射型有点类似。。但存储型存从接口拿到数据。会影响所有访问这个网站的用户。影响比较大。复制代码
- 基于DOM型
a. 基于DOM型和反射型也差不多。。但不知为啥要分我三种类型。b. 与反射型有一些区别就是，用户误点开了带攻击的url :http://xxx?name=c. 网站给受害者的返回中正常的网页，等到用户触发某个脚本时，才会执行。这种方式比反射型隐蔽。发生在我们合法的js执行中，服务器无法检测我们的请求是否有攻击的危险。复制代码
二，xss的危害
a. 攻击者把代码注入进了访问的页面，所以恶意脚本都在网站的上下文环境中执行， 这就意味着恶意代码被当做网站提供的正常脚本一样对待；b. 他有权访问页面与网站的关键数据（比如cookie）,浏览器会认为他是网站的合法部分，允许他做任何非法事情；c. 或者攻击者可以通过修改DOM在页面上插入一个假的登陆框，也可以把表单的`action`属性指向他自己的服务器地址， 然后欺骗用户提交自己的敏感信息；复制代码
三，xss的防范
a. 编码，就是转义用户的输入，把用户的输入解读为数据而不是代码；b. 校验，对用户的输入及请求都进行过滤检查，如对特殊字符进行过滤，设置输入域的匹配规则等；c. 服务端输出检查；d. HttpOnly 防止劫取 Cookie，这个只能阻止非法获取cookie。并不能防范xss的攻击；复制代码
四，csrf
a. 即 Cross Site Request Forgery，中译是跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式；b. 通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任， 可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器， 从而在并未授权的情况下执行在权限保护之下的操作；c. 此种攻击比xss更隐蔽。不容易被发现；举例说明：CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。比如说：受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。1. 通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，2. 并且该 session 的用户 Bob 已经成功登陆。黑客 Mallory 自己在该银行也有账户， 他知道上文中的 URL可以把钱进行转帐操作。3. Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。4. 但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。5. 这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，6. 并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，7. 而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，8. 因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，9. 他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。10. 这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，11. 而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，12. 他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。13. 而 Mallory 则可以拿到钱后逍遥法外。总之是通过截取cookie。冒充合法用户，骗取服务器信任。然后做非法的事情；复制代码
五，csrf的防范
1. 验证码，被认为是对抗 CSRF 攻击最简洁而有效的防御方法。 但验证码并不是万能的，因为出于用户体验考虑，不能给网站所有的操作都加上验证码； 2. Referer Check 根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。 通过 Referer Check，可以检查请求是否来自合法的"源"。 这种方法的弊端： a. 每个浏览器对于 Referer 的具体实现可能有差别。比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值； b. 有些用户认为这样会侵犯到他们自己的隐私权,因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer； 3. 添加 token 验证 a. CSRF 攻击之所以能够成功，是因为攻击者可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 Cookie 中， 因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的 Cookie 来通过安全验证; b. 关键在于在请求中放入攻击者所不能伪造的信息，并且该信息不存在于 Cookie 之中。 c. 可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个token， 如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。 （这种弊端就是每个请求都要带上这个生成的token随机数，所以采用封装一个公共方法的来调用接口）复制代码