简单web安全checklist及解决方案

时间:2017-03-27 12:44 来源:武松娱乐整理 字体:[ ] 评论:
简单web安全checklist及解决方案。面向公网的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问题,例如: xss" target="_blank" rel="nofollow,noindex">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 用户已经登录,照样会被攻击,像下面的代码一样 用户进入攻击页面后,攻击者可以自动提交表单,若用户已经登录了 xxxx.com 则请求依然会成功 解决方案检查referer 检查下请求的referer,根据地址来判断是否接受请求 添加csrf token 在cookie中写入一个随机生成的csrf token,用户请求的时候这样构造表单 {C} 这样攻击者在伪造表单的时候,是没办法获取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注入 参见 http://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等参数一定要做数字类型校验及大小校验。
Top_arrow
武松娱乐注册