1.越权访问
漏洞场景
类似于http://xxxx.com/resource/:id格式的路由，要特别注意越权访问的问题
例如http://xxxx.com/resource/123456是属于用户A的资源，但是后台没有对资源从属关系做验证，导致恶意用户B登录后也可以通过此链接访问到资源
解决方案
此漏洞比较低级，但是也是一个需要注意的点。 开发类似的资源接口时，注意一下做身份校验就可以了。
2.服务器路径泄露
漏洞场景
有时候服务端对错误信息处理不当，在生产环境中和开发环境一样，把错误的message和调用栈同时打印出来，会暴露服务器内部的路径。
这样的漏洞本身不会导致什么危害，但是若与其他漏洞结合，容易导致黑客推断出服务器内部的具体情况，所以一般也会被认为是一种安全漏洞。
解决方案
为生产环境开发一个友好的报错界面，只显示错误message，不要显示错误信息堆栈。
3.xss
漏洞场景
富文本 : 含有用户编辑富文本页面为xss重灾区，是典型的存储型xss场景。 用户A编辑了一段含有xss代码的内容存放于db，渲染到页面上展现给其他用户时，若用户内容出入时都没有做好xss过滤的措施，就会导致其他用户面临xss攻击的风险。
页面直接显示url参数中的内容
比较典型的例如查询参数、页码参数等。类似于http://xxx.com/xxx/?query=keyword&pageindex=4
若页面上对keyword或者pageindex处理不当直接渲染在页面上，则容易导致反射型xss攻击
解决方案
要注意的一点，现在很多浏览器已经可以自动拦截部分xss攻击代码了，但是这并不意味着我们就可以不处理xss，因为不能保证所有用户都用了先进的浏览器。
在调试的时候可以给接口加上res.header('X-XSS-Protection' , 0 ); 这个header来允许浏览器运行xss代码。
过滤xss的规则比较繁杂，可自行google之。nodejs有一些开源的组件可以很方便的用来处理xss问题，例如： https://github.com/leizongmin/js-xss
4.csrf
漏洞场景
csrf如果不注意防范，很容易被攻击。
get请求
若用户的敏感操作是一个get请求，如http://xxxx.com/pay?money=100&to=user ，此时攻击者在钓鱼页面中插入一个img标签，src的值是http://xxxx.com/pay?money=100&to=attacter 。攻击者将此页面发送给网站的用户，若用户已经登录，则敏感操作将成功。
post请求
get请求做敏感操作实际上是很低级的错误。那么使用post请求就很安全了吗？ 也不是的，攻击者可以在钓鱼页面中伪造表单，若xxxx.com 用户已经登录，照样会被攻击，像下面的代码一样
<form action="http://xxxx.com/pay" method="POST"> <input type="hidden" name="money" value="100" /> <input type="hidden" name="to" value="attacter" /> <input type="submit" value="Submit request" /> form>
用户进入攻击页面后，攻击者可以自动提交表单，若用户已经登录了xxxx.com 则请求依然会成功
解决方案
检查referer
检查下请求的referer，根据地址来判断是否接受请求
添加csrf token
在cookie中写入一个随机生成的csrf token，用户请求的时候这样构造表单
<form action="http://xxxx.com/pay" method="POST"> <input type="hidden" name="money" value="100" /> <input type="hidden" name="to" value="attacter" /> <input type="hidden" name="_csrftoken" value="asdfasdgqwesdf" /> <input type="submit" value="Submit request" /> form> 这样攻击者在伪造表单的时候，是没办法获取csrf token随机值的——除非网站还有xss漏洞，攻击者可以拿到用户的cookie。因此cookie中的csrf token建议是写成http only的，那样会更为安全一点。
为了更简单的处理此类问题，还可以考虑在页面中使用封装好的ajax库，然后在全局配置的请求header中加上token，后端验证的时候也从header中去取token。
nodejs+express开发web server的话，可以用一些开源的模块来快速处理此类问题，例如csurf模块：https://github.com/expressjs/csurf
5.sql注入
sql注入的场景比较多，这里记录一下我所了解到的场景和防范方式吧，后续补充。
漏洞场景
客户端字符未经处理
这种方式的sql注入在远古时代的web应用中比较常见，现在的web应用一般不会出现这样的低级注入问题。
例如select * from table where user='xxxxxxxxx' and password=123456
假如user字段是直接使用用户输入字符做拼接的，那么可以输入xxxx' or 1=1 --，来让sql语句变成:
select * from table where user='xxxx' or 1=1 --' and password=000000` 这样就可以非法获取用户数据了。
bigint注入
解决方案
首先客户端填写的参数是绝对不能未经处理直接拿来拼接sql语句的，如果是手动拼接sql，要注意替换下面这些符号：
sqlValue
.replace(/\\/g,"\\\\")
.replace(/"/g,"\\\"")
.replace(/'/g,"\\\'")
.replace(/\r/g,"\\r")
.replace(/\n/g,"\\n") 若不是手动拼接sql而是使用的orm框架，则一般框架会自己去处理sql注入的问题。
而bigint注入，一般容易出现在分页等场景中，此处要注意的就是pageindex、pagesize、offset等参数一定要做数字类型校验及大小校验。
6.上传文件类型绕过
漏洞场景
上传文件时，需要注意限制用户上传的文件类型，如只接受图片等。判断文件类型的时候，有时候只会去判断文件后缀名是否合法，此时会有文件类型绕过的风险，攻击者将文件后缀名修改之后上传，即可绕过服务端对文件类型的检测
解决方案
一般来说不仅仅要检查文件后缀名，还需要根据文件头的前几个字节来判断文件的真实类型，对应关系可以参考百度百科：
http://baike.baidu.com/item/%E6%96%87%E4%BB%B6%E5%A4%B4
若是nodejs应用，可以用此模块来判断：https://www.npmjs.com/package/file-type
7.http响应头注入
漏洞场景
用户输入的参数未经处理直接在http的response响应头中出现，由于http报文是用\r\n来分隔head和body的，攻击者可能在参数中插入\r\n来截断原本的报文，构造任意响应body
解决方案
在用户输入的响应头中过滤回车换行符%0d%0a
实际上，参数中包含%00——%1f 的控制字符时都是不合法的，可以对其进行删除
