CSRF(跨站请求伪造)

原理

简单来说就是，攻击者通过一些技术手段欺骗用户通过浏览器去访问一个，自己已经认证过（登陆过，留下过登录验证信息）的网站，进行一系列操作（例如：发邮件，发消息，甚至财产操作和转账），所以被访问的网站会认为是真正的用户操作而去运行。

原因

简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求是用户自愿发出的。

假设：

假如把1000元钱转账给shx的链接为：

https://www.bank.com/withdraw？amount=1000&for=shx

那么，一个恶意攻击者top可以在另外一个网站上设置如下链接:

https://www.bank.com/withdraw？amount=1000&for=top

如果用户登陆过账号不久，登录信息尚未过期，并且被攻击者骗取打开此链接，那么shx就有可能会损失1000元钱。

防御措施

①检查Referer字段：

HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通过此字段获取发送请求的网址，并传递给服务器端，这时候服务器就能识别出是否为恶意访问。

这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。

②添加校验token:

由于CSRF的本质是利用存储在浏览器中的验证数据欺骗用户去访问攻击者设置的地址，只要用户提供的验证数据不存储在浏览器中，并且攻击者无法伪造验证数据作为效验，那么攻击者就无法运行CSRF攻击。

所以这种验证数据一般是由服务器生成，将其放在请求的返回值中，其内容是一个伪随机码，当客户端提交数据时，将这个伪随机码一并提交上去做校验。

当用户正常访问时，客户端能接受并返回这个随机码，而通过CSRF传来的欺骗性攻击中，攻击者无法事先得知或伪造这个伪随机码，服务器就会因为token的值为空或者错误，拒绝这个可疑请求。

③在 HTTP 头中自定义属性并验证：

这种方法本质也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。

然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

XSS(跨站脚本)

原理

XSS攻击通常是指利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。

HTML是一种超文本标记语言，通过将一些字符特殊地对待来区别文本和标记，当HTML标签引入了一段JavaScript脚本时，这些脚本程序就将会在用户浏览器中执行。所以，当这些特殊字符不能被动态页面检查或检查出现失误时，就将会产生XSS漏洞。

特点

①由于XSS攻击在用户当前使用的应用程序中执行，用户将会看到与其有关的个性化信息，如账户信息或“欢迎回来”消息，克隆的Web站点不会显示个性化信息。

②通常，在钓鱼攻击中使用的克隆Web站点一经发现，就会立即被关闭。

③许多浏览器与安全防护软件产品都内置钓鱼攻击过滤器，可阻止用户访问恶意的克隆站点。

④如果客户访问一个克隆的Web网银站点，银行一般不承担责任。但是，如果攻击者通过银行应用程序中的XSS漏洞攻击了银行客户，则银行将不能简单地推卸责任。

类型

①持久型跨站：最直接的危害类型，跨站代码存储在服务器（数据库）。

②非持久型跨站：反射型跨站脚本漏洞，最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。

③DOM跨站（DOM XSS）：DOM（document object model文档对象模型），客户端脚本处理逻辑导致的安全问题。

基于DOM的XSS漏洞是指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置，而使得攻击脚本被执行。在整个攻击过程中，服务器响应的页面并没有发生变化，引起客户端脚本执行结果差异的原因是对本地DOM的恶意篡改利用。

攻击方式

①盗用cookie，获取敏感信息。

②利用植入Flash，通过crossdomain权限设置进一步获取更高权限；或者利用Java等得到类似的操作。

③利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作。

④利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。

⑤在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果。

防御方法

①不信任用户提交的任何内容，对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、REFER、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。尽量采用POST而非GET提交表单；对“<”，“>”，“；”，“””等字符做过滤；任何内容输出到页面之前都必须加以en-code，避免不小心把htmltag显示出来。

②实现Session 标记（session tokens）、CAPTCHA（验证码）系统或者HTTP引用头检查，以防功能被第三方网站所执行，对于用户提交信息的中的img等link，检查是否有重定向回本站、不是真的图片等可疑操作。

③cookie 防盗。避免直接在cookie中泄露用户隐私，例如email、密码，等等；通过使cookie和系统IP绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值，很难拿来直接进行重放攻击。

④确认接收的内容被妥善地规范化，仅包含最小的、安全的Tag（没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和JavaScript），使用HTTPonly的cookie。