「第十章」访问控制

「第三篇」服务器端应用安全

	批注
		[……]	表示他人、自己、网络批注
			参考资料来源于
				* 优快云
				* GitHub
				* Google
				* 维基百科
				* YouTube
				* MDN Web Docs
			由于编写过程中无法记录所有的URL
			所以如需原文，请自行查询
		{……}	重点内容
		*……*	表示先前提到的内容，不赘述
	

「第三篇」服务器端应用安全
	「0.6本书结构」
		就常见的服务器端应用安全问题进行了阐述
		这些问题往往能引起非常严重的后果，在网站的安全建设之初需要优先解决这些问题，避免留下任何隐患

	「第十章」访问控制
		「10.1我能做什么」
			权限控制，或者说访问控制，广泛应用于各个系统中
			抽象地说，都是某个主体(subject)对某个客体(object)需要实施某种操作(operation)，而系统对这种操作的限制就是权限控制
			在网络中，为了保护网络资源的安全，一般是通过路由设备或者防火墙建立基于IP的访问控制
			这种访问控制的“主体”是网络请求的发起方(比如一台PC), 客体是网络请求的接收方(比如一台服务器)，主体对客体的操作是对客体的某个端又发起网络请求
			这个操作能否执行成功，是受到防火墙ACL策略限制的
			在操作系统中，对文件的访问也有访问控制
			此时主体是系统的用户，客体是被访问的文件，能否访问成功，将由操作系统给文件设置的ACL(访问控制列表)决定
			比如在Linux系统中，一个文件可以 执行的操作分为“读”、“写”、“执行”三种，分别由r、w、x表示
			这三种操作同时对应着三种主体
				文件拥有者
				文件拥有者所在的用户组
				其他用户
			主体、客体、操作这三者之间的对应关系，构成了访问控制列表
			在一个安全系统中，确定主体的身份是认证解决的问题，而客体是一种资源，是主体发起的请求的对象
			在主体对客体进行操作的过程中，系统控制主体不能无限制地对客体进行操作，这个过程就是访问控制
			主体能够做什么，就是权限，权限可以细分成不同的能力(capability)
			在Linux的文件系统中，将权限分成了读、写、执行三种能力
			用户可能对某个文件拥有读的权限，但却没有写的权限
			在Web应用中，根据访问客体的不同，常见的访问控制可以分为基于URL的访问控制、基于方法(method)的访问控制和基于数据的访问控制
			一般来说，基于URL的访问控制是最常见的
			要实现一个简单的基于URL的访问控制，在基于Java的Web应用中，可以通过增加一个filter实现
			当访问控制存在缺陷时，会如何呢
			我们看看下面这些真实的案例，这些案例来自漏洞披露平台 WooYun
				http://www.wooyun.org
			凤凰网分站后台某页面存在未授权访问漏洞
				http://www.wooyun.org/bugs/wooyun-2010-0788
			mop后台管理系统未授权访问
				http://www.wooyun.org/bugs/wooyuii-2010-01429
			网易某分站后台存在未授权访问
				http://www.wooyun.org/bugs/wooyun-2010-01352
			酷6网某活动用户审核页面未授权访问
				http://www.wooyun.org/bugs/wooyun-2010-01085
			在正常情况下，管理后台的页面应该只有管理员才能够访问，但这些系统未对用户访问权限进行控制，导致任意用户只要构造出了正确的URL，就能够访问到这些页面
			在正常情况下，这些管理页面是不会被链接到前台页面上的，搜索引擎的爬虫也不应该搜索到这些页面
			但是把需要保护的页面藏起来，并不是解决问题的办法
			攻击者惯用的伎俩是使用一部包含了很多后台路径的字典，把这些藏起来的页面扫出来
			在这些案例的背后，其实只需要加上简单的基于页面的访问控制，就能解决问题了
		「10.2垂直权限管理」
			访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是基于角色的访问控制(Role-Based Access Control)，简称RBAC
			RBAC事先会在系统中定义出不同的角色，不同的角色拥有不同的权限，一个角色实际上就是一个权限的集合
			而系统的所有用户都会被分配到不同的角色中，一个用户可能拥有多个角色，角色之间有高低之分(权限高低)
			在系统验证权限时，只需要验证用户所属的角色，然后就可以根据该角色所拥有的权限进行授权了
			Spring Security中的权限管理，就是RBAC模型的一个实现
				http://static.springframework/org/spring-security/site/
			Spring Security基于Spring MVC框架，它的前身是Acegi，是一套较为全面的Web安全解决方案
			在Spring Security中提供了认证、授权等功能，在这里我们只关注Spring Security的授权功能
			Spring Security提供了一系列的Filter Chain，每个安全检查的功能都会插入在这个链条中
			在与Web系统集成时，开发者只需要将所有用户请求的URL都引入到Filter Chain即可
			Spring Security提供两种权限管理方式
				基于URL的访问控制
				基于method的访问控制
			这两种访问控制都是RBAC模型的实现
			换言之，在Spring Security中都是验证该用户所属的角色，以决定是否授权
			不同的URL对于能访问其的角色有着不同的要求
			虽然Spring Security的权限管理功能非常强大，但它缺乏一个管理界面可供用户灵活配置，因此每次调整权限时，都需要重新修改配置文件或代码，而其配置文件较为复杂，学习成本较高，维护成本也很高
			除了Spring Security外，在PHP的流行框架Zend Framework中，使用的Zend ACL实现了一些基础的权限管理
				http://framework.zend.com/manual/en/zend.acl.html
			不同于Spring Security使用配置文件管理权限，Zend ACL提供的是API级的权限框架
			权限管理其实是业务需求上的一个问题，需要根据业务的不同需求来实现不同的权限管理
			因此很多时候，系统都需要自己定制权限管理
			定制一个简单的权限管理系统，不妨选择RBAC模型作为依据
			这种基于角色的权限管理(RBAC模型)，我们可以称之为垂直权限管理
			不同角色的权限有高低之分
			高权限角色访问低权限角色的资源往往是被允许的，而低权限角色访问高权限角色的资源往往则被禁止
			如果一个本属于低权限角色的用户通过一些方法能够获得高权限角色的能力，则发生了越权访问
			在配置权限时，应当使用最小权限原则，并使用默认拒绝的策略，只对有需要的主体单独配置允许的策略，这在很多时候能够避免发生越权访问
		「10.3水平权限管理」
			优酷网用户越权访问问题(漏洞编号wooyun-2010-0129)
			用户登录后，可以通过以下方式查看他人的来往信件(只要更改下面地址的数字id即可)，查看和修改他人的专辑信息
			URL经过rewrite后将参数映射成URL路径，但这并不妨碍通过修改用户id来实现攻击
			在这里，id代表资源的唯一编号，因此通过篡改id，就能改变要访问的资源
			而优酷网显然没有检查这些资源是否属于当前用户
			来伊份购物网站越权访问问题(漏洞编号wooyun-2010-01576)
			来伊份购物网站没有对用户进行权限控制，通过变化URL中的id参数即可查看对应id的个人姓名、地址等隐私信息
			同样的，id是用户的唯一标识，修改id即可修改访问的目标
			网站后台应用并未判断资源是否属于当前用户
			相对于垂直权限管理来说，水平权限问题出在同一个角色上，系统只验证了能访问数据的角色，既没有对角色内的用户做细分，也没有对数据的子集做细分，因此缺乏一个用户到数据之间的对应关系
			由于水平权限管理是系统缺乏一个数据级的访问控制所造成的，因此水平权限管理又可以称之为基于数据的访问控制
			在今天的互联网中，垂直权限问题已经得到了普遍的重视，并已经有了很多成熟的解决方案，但水平权限问题却尚未得到重视
				* 对于一个大型的复杂系统来说，难以通过扫描等自动化测试方法将这些问题全部找出来
				* 对于数据的访问控制，与业务结合得十分紧密
					有的业务有数据级访问控制的需求，有的业务则没有，要理清楚不同业务的不同需求，也不是件容易的事情
				* 如果在系统己经上线后再来处理数据级访问控制问题，则可能会涉及跨表、跨库查询，对系统的改动较大，同时也可能会影响到性能
			这种种原因导致了现在数据级权限管理并没有很通用的解决方案，一般是具体问题具体解决
			一个简单的数据级访问控制，可以考虑使用用户组(Group)的概念，比如一个用户组的数据只属于该组内的成员，只有同一用户组的成员才能实现对这些数据的操作
			此外，还可以考虑实现一个规则引擎，将访问控制的规则写在配置文件中，通过规则引擎对数据的访问进行控制
			水平权限管理问题，至今仍然是一个难题——它难以发现，难以在统一框架下解决，在未来也许会有新的技术用以解决此类问题
		「10.4OAuth简介」
			OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议
			OAuth 1.0于2007年12月公布，并迅速成为了行业标准(可见不同网站之间互通的需求有多么的迫切)
			OAuth 1.0正式成为了RFC 5849
				http://tools.ietf.org/html/rfc5849
			OAuth与OpenID都致力于让互联网变得更加的开放
			OpenID解决的是认证问题，OAuth则更注重授权，认证与授权的关系其实是一脉相承的，后来人们发现，其实更多的时候真正需要的是对资源的授权
			常见的应用OAuth的场景，一般是某个网站想要获取一个用户在第三方网站中的某些资源或服务
			在OAuth 1.0中，涉及3个角色
				* Consumer:消费方(Client)
				* Service Provider:服务提供方(Server)
				* User:用户(Resource Owner)
			在新版本的OAuth中，又被称为Client、Server、Resource Owner
			OAuth的发展道路并非一帆风顺，OAuth 1.0也曾经出现过一些漏洞[9]，因此OAuth也出过几个修订版本，最终才在2010年4月定稿OAuth 1.0为RFC 5849
				http://oauth.net/adxisories/2009-1/
			在这个版本中，修复了所有已知的安全问题，并对实现OAuth协议需要考虑的安全因素给出了建议
				http://tools.ietf.org/html/rfc5849#section-4
			OAuth 1.0已经成为了RFC标准，但OAuth 2.0仍然在紧锣密鼓的制定中，到2011年年底已经有了一个较为稳定的版本
			OAuth 2.0吸收了OAuth 1.0的经验，做出了很多调整，它大大地简化了流程，改善了用户体验，两者并不兼容，但从流程上看区别不大
			常见的需要用到OAuth的地方有桌面应用、手机设备、Web应用，但OAuth 1.0只提供了统一的接又，这个接又对于Web应用来说尚可使用，但手机设备和桌面应用用起来则会有些别扭
			同时OAuth 1.0的应用架构在扩展性方面也存在一些问题，当用户请求数庞大时，可能会遇到一些性能瓶颈
			为了改变这些问题，OAuth 2.0应运而生
				http://hueniverse.com/2010/05/introducing-oauth-2-0/
		「10.5总结」
			还分别介绍了垂直权限管理，它是一种基于角色的访问控制，以及水平权限管理，它是一种基于数据的访问控制
			这两种访问控制方式，在进行安全设计时会经常用到
			访问控制与业务需求息息相关，并非一个单纯的安全问题
			因此在解决此类问题或者设计权限控制方案时，要重视业务的意见
			无论选择哪种访问控制方式，在设计方案时都应该满足最小权限原则，这是权限管理的黄金法则