原文地址：www.zoucz.com/blog/2017/0…，参与评论
面向公网的web服务或者http接口服务可能会面临黑客的攻击，故一些基本的web安全案例在上线之前要过一遍，本文记录一些简单的web安全漏洞，后续发现陆续补充。我要说话
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问题，例如： github.com/leizongmin/…我要说话
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模块：github.com/expressjs/c…我要说话
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注入
参见 www.vuln.cn/6818我要说话
解决方案
首先客户端填写的参数是绝对不能未经处理直接拿来拼接sql语句的，如果是手动拼接sql，要注意替换下面这些符号：
我要说话
sqlValue
.replace(/\\/g,"\\\\")
.replace(/"/g,"\\\"")
.replace(/'/g,"\\\'")
.replace(/\r/g,"\\r")
.replace(/\n/g,"\\n")我要说话
若不是手动拼接sql而是使用的orm框架，则一般框架会自己去处理sql注入的问题。我要说话
而bigint注入，一般容易出现在分页等场景中，此处要注意的就是pageindex、pagesize、offset等参数一定要做数字类型校验及大小校验。我要说话
