目录
XSS的原理与防范
XSS的介绍
XSS（Cross Site Scripting）翻译过来意思是跨站脚本攻击。
通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。（百度百科）
总的来说XSS攻击就是攻击者通过各种办法在用户访问某个页面的时候插入自己的脚本，让用户访问这个页面的时候会执行该脚本，攻击者就可以通过自己所插入的脚本获得一些用户的信息，如cookie等等。
XSS的种类
· 反射型：
反射型指攻击者将XSS的代码的脚本代码捆绑到我们的链接中，并且作为一部分的输入提交到服务器，然后服务器解析之后会将XSS的代码反射回给浏览器，然后浏览器就会去执行这一段脚本。（但现在一般的浏览器都有基本的防御措施，自带拦截过滤）
一般攻击者会通过一些聊天软件或者邮件来传播这样的URL，用户点击了这样的URL后攻击者就能达到攻击目的了。但这样的攻击是不具有持久性的。
· 存储型：
存储型的攻击会将XSS的代码脚本通过网站所提供的接口存储到后台的数据库，当有其他人的浏览器去读取这一段内容时，后台数据库就会将这段脚本解析出来返回给该用户，这样浏览器又会执行这一段脚本了。
像一般的论坛等有发帖/留言场景的网站，攻击者只需要将自己的XSS代码作为帖子发布，这样浏览到该内容的用户都将受到攻击。
·DOM-Based型：
这种类型的攻击服务器不会参与，触发完全依靠客户端的DOM解析。
如客户端代码不够严谨，没有好好过滤攻击的情况，比如：
http://www.vulnerable.site/welcome.html#name=<script>alert(document.cookie)<script> 注意文件名后面的数字符号 #，他告诉浏览器其后面的东西不是片段，不作为查询的一部分，这样就不会被发送到服务器。
XSS的防范
XSS防范的总体思路就是“对输入(和URL参数)进行过滤，对输出进行编码。同时把用户 Cookie 设置为 http-only”。
1. 输入处理
（输入包括用户输入、URL参数、POST请求参数、Ajax等）
- 黑名单过滤。对诸如<script>、<img>、<a>等标签进行过滤。
- 白名单过滤。如输入用户名密码时限制输入长度与格式。但这个策略账号密码上应用还可以，到了富文本编辑器就不行了。
2. 输出处理
- 输出转义。对输出的的特殊符号根据 HTML实体进行转义，如 < 转为 < 、> 转为 >
3. cookie设置
- 将 cookie 设置为 http-only，这样在浏览器的document对象中就看不到cookie了，而浏览器浏览网页不受任何影响。
CSRF的原理与防范
CSRF的介绍
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。
尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。（百度百科）
简单的说，CSRF是攻击者盗用你的名义来发送恶意消息，如：以你的名义发邮件，购买物品，转账等。
CSRF的原理
上面说到攻击者会以你的名义发消息，那是怎么做到的呢？
首先我们要知道 HTTP 协议的无状态的，所以服务端需要一个 session_id 来标识每一个访问用户，然后我们再次访问服务端时会带上 session_id，这样就可以做到如保持登录状态等操作，直到服务端 session 过期。（过程可参考下图）
如在一个转账的网站，当我们保持着登录状态没有退出，然后这时候被诱导访问了另一个网站，该网站内有张不可显示的图片，代码是：
<img src="xxx/（转账接口）?to_user=（攻击者的用户）&money=（被转账金额）" />这是攻击者利用图片资源嵌入了恶意的转账操作，所以可以在我们不知情的情况下转走我们的钱钱。
但上述例子是一个 GET 请求下的操作，那如果是 POST 请求呢？
这时候只需要在诱导用户访问的页面内嵌一个表单，通过表单自动提交也可以做到恶意转账。
CSRF的防范
CSRF 的本质原因是由于服务端的身份验证不够，仅仅通过校验 session 来判断，但这并不能保证所有的操作都是用户发起的，所以要防范 CSRF 得加强在服务端的校验处理。
1. 尽量使用 POST
因为 GET 请求实在是太容易被利用了，如上述的例子，只需要一个 img 的标签，而 img 又是不能过滤的数据，所以接口最好限制为 POST 请求。
2. 加入验证码
因为 CSRF 都是偷偷盗用用户名义发送的，我们只需要加入验证码校验，就可以确定该操作是用户自己的行为而不是盗用用户名义的行为。
3. 验证Referer
HTTP 头上有一个 Referer 字段，记录了该请求的源地址，黑客要发起 CSRF 的攻击只能从他们自己的网站构建请求，源地址不会是用户的地址。但道高一尺魔高一丈，虽然 Referer 的值是由浏览器提供的，但在某些浏览器上我们可以篡改 Referer 的值，所以有时候也并不安全。
4. Token
我们知道黑客只能冒用了我们的身份发送请求，所以我们只每次发送的请求带上一个黑客所不能伪造的验证信息，并且信息不能存在与 cookie 中。所以我们可以在 HTTP 的请求头中加入一个随机产生的 token（分布式环境下的 token 生成有点不同），客户端返回消息时验证该 token 是否一致，若不一致则认为这是一次 CSRF 攻击。
参考
https://www.oschina.net/translate/dom-based-xss-of-third-kind?lang=chs&p=1
1209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
