随着新时代网络空间安全要求的提高，企业对于安全意识有了大幅提升，然而黑产人员的恶意攻击手段也日新月异，层出不穷。传统开发中的单纯依靠开发人员经验进行的安全防护已经无法应对当前迅速发展的恶意攻击手段。于是由专业安全公司进行的基于黑盒测试的渗透测试与基于白盒测试的代码审计已经成为了保障应用安全的重要法宝。本文中将谈一下几种在代码审计中常发现的问题
应用中无权限控制校验或权限控制校验错误。
权限校验主要分为水平权限校验和垂直水平校验。迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制（Role-Based Access Control)。下图为RBAC0模型，这是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。用户是发起操作的主体,可以是OA系统的内部员工,也可以是面向C端的用户,比如微信的用户。角色起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。权限是用户可以访问的资源,包括页面权限,操作权限,数据权限。
对权限的设计与实现十分考验开发人员的经验，权限的错误设置会导致非常严重的后果，然而因为复杂的逻辑导致权限设计的错误较难通过静态的审查检出，实际的代码审计中往往是使用渗透测试手段去探查问题类型然后定位具体的问题代码段。
作用于相同角色但不同数据之间。例如A与B都是应用系统的用户,对该系统上的资源拥有相同的权限,但各自有自己不同的个人资料以及评论数据等私有数据。如果不做好水平校验,抱有恶意的A用户很容易通过伪造包含B用户id的请求的方式获得B用户中的信息，这明显是不安全的。所以我们在开发的时候尤其需要注意此类问题,可以使用例如OAuth登录机制等来验证用户,结合使用类似JWT(JSON WEB Token)的token机制等来进行鉴权。
垂直权限校验一般基于ACL(Access Control List 暨访问控制列表，包含了对一个对象或一条记录可进行何种操作的权限定义)，这很多框架都会对应业务来进行集成。例如A是注册用户,B是管理员,有些不成熟的应用会使用对于不同角色展示不同页面的方法进行权限控制，然而会忽略恶意用户通过直接访问后端接口操纵数据的方式越过前端的权限控制。而正确的做法则是将权限校验放在后端，在服务器端将不同的角色对应不同的权限列表，操作数据前先校验用户的权限，这样才可以保证垂直权限控制的有效性。
对用户输入的参数不进行检验直接与sql语句拼接访问数据库
SQL注入是一个老生常谈的安全问题，具体的技术原理就不再详谈，然而总是在各种应用中发现。此类写法会导致sql注入，平时在代码审计中不发现则已，一发现就是数百处，往往导致公司后期整改成本非常之高。所以建议从开发公司在开发过程中明确禁止此类写法，对用户输入的参数要严格遵守参数绑定或者数据的元数据对应,从而对用户的输入的内容进行更好的校验,避免sql注入的问题。下面一个小漫画生动了展现了不对输入参数进行校验的系统会出现的问题。
忽略参数校验可能导致:内存溢出，恶意order by导致数据库慢查询，任意重定向，SQL注入，反序列化注入，正则输入源串拒绝服务ReDoS等等问题。
对于一些安全开发经验较为缺乏的公司,在项目中对于用户的输入往往不做校验或只做一些基本的校验。然而实际上目前恶意攻击的方法层出不穷,而恶意攻击基本都是针对输入流做文章，对用户的输入做好过滤是安全防护中第一关也是最重要的一关，明显不成体系的简单校验是远远不够的，关于安全的方面是我们不得不重视，勤做测试，多做CR,方方面面都需要考虑到。
CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。跨站点请求伪造(Cross-Site Request Forgeries,CSRF)攻击是指攻击者通过设置好的陷阱,强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新,属于被动攻击。简单介绍一下CSRF攻击。
如图，要完成一次CSRF攻击，受害者必须依次完成两个步骤：
1.不能保证用户登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2.不能保证用户关闭浏览器了后，其本地的Cookie立刻过期，使上次的会话立即结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
解决CSRF漏洞的方法并不是很难，只要在用户提交内容时对用户的身份真实性进行校验即可，但是很可惜目前市面上很大一部分的应用采用的校验方法并不有效。
对于涉及使用平台资源的接口,未实现正确的防重放机制。
例如注册时发送验证码到手机,如果没有限制次数和频率,那么恶意攻击便可以可以利用此功能骚扰到其它用户,并造成短信平台资源浪费。
此类与具体业务类型（短信、邮件、电话、下单、支付等）相关性较强，可使用的解决方案根据业务的不同也很多，产生的损失也可大可小，一般在审计中会根据具体的业务制定具体的审计标准与防范措施（如数量限制、疲劳度控制、验证码校验，或者干脆使用久经考验的第三方应用等）。
原文始发于微信公众号（SK安全实验室）：谈谈代码审计中的常见问题（1）
评论