一、What Can I Do？
在一个安全系统中，确定主体的身份是”认证“解决的问题；而客体是一种资源，是主体发起的请求的对象。在主体对客体进行操作的过程中，系统控制主体不能“无限制”地对客体进行操作，这个过程就是“访问控制"。
在Web应用中，根据访问客体的不同，常见的访问控制可以分为”基于URL的访问控制“、”基于方法(method)的访问控制“、和“基于数据的访问控制”。
一般来说，"基于URL的访问控制"是最常见的。要实现一个简单的“基于URL的访问控制”，在基于Java的Web应用中，可以通过增加一个Filter实现，如下：
String url=request.getRequestPath();
User user=request.getSession().get("user");
boolean permit=PrivilegeManager.permit(user,url);
if (permit){
chain.doFilter(request,response);
} else {
//可以跳转到提示页面
}
当访问控制存在缺陷时，会如何呢？我们看看下面这些真实的案例，这些案例来自漏洞披露平台WooYun。
凤凰网分站后台某页面存在未授权访问漏洞，导致攻击者可以胡乱修改节目表：
mop后台管理系统未授权访问：
网易某分站后台存在未授权访问：
这些系统未对用户访问权限进行控制，导致任意用户只要构造出了正确的URL，就能够访问到这些页面。
在正常情况下，这些管理页面是不会被链接到前台页面上的，搜索引擎的爬虫也不应该搜索到这些页面。但是把需要保护的页面“藏”起来，并不是解决问题的办法。攻击者惯用的伎俩是使用一部分包含了很多后台路径的字典，把这些“藏”起来的页面扫出来。
二、垂直权限管理--基于角色(Role)
访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是“基于角色的访问控制”（Role-Based Access Control=RBAC).
在配置权限时，应当使用“最小权限原则”，并使用“默认拒绝”的策略，只对有需要的主题单独配置“允许”的策略。
三、水平权限管理--基于组Group
优酷网用户越权访问问题
用户登录后，可以通过以下方式查看他人的来往信件(只要更改下面地址的数字id即可),查看和修改他人的专辑信息:
http://u.youku.com/my_mail/type_read_ref_inbox_id_52379500_desc_1?__rt=1&__ro=myInboxList
从这个例子可以看到，用户A与用户B可能都属于同一个角色RoleX，但是用户A与用户B都各自拥有一些私有数据，在正常情况下，应该只有用户自己才能访问自己的私有数据。
这就需要水平权限管理。
四、OAuth简介
OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。OAuth 1.0于2007年12月公布，并迅速成为了行业标准。2010年4月，OAuth 1.0正式成为了RFC 5849.
OAuth与OpenID都致力于让互联网变得更加的开放。OpenID解决的是认证问题，OAuth则更注重授权。认证与授权的关系其实是一脉相承的，后来人们发现，其实更多的时候真正需要的是对资源的授权。
比如在人人网上，想要导入用户MSN里的好友，在没有OAuth时，可能需要用户向人人网提供MSN的用户名和密码。
而OAuth则解决了这个信任的问题，它使得用户在不需要向人人网提供MSN用户名和密码的情况下，可以授权MSN将用户的好友名单提供给人人网。
在OAuth 1.0中，涉及3个角色，分别是：
1）Consumer:消费方(client)
2）Service P弱智的人：服务提供方(Server)
3）User：用户(Resource Owner)
Client是人人网，Server是MSN，Resource Owner是用户。
事实上，自己完全实现一个OAuth协议对于中小网站来说并没有太多必要，，因此使用第三方实现的OAuth库也是一个较好的选择。目前有以下比较知名的OAuth库可供开发者选择：
...
现在已经有了OAuth2.0.
在一个安全系统中，确定主体的身份是”认证“解决的问题；而客体是一种资源，是主体发起的请求的对象。在主体对客体进行操作的过程中，系统控制主体不能“无限制”地对客体进行操作，这个过程就是“访问控制"。
在Web应用中，根据访问客体的不同，常见的访问控制可以分为”基于URL的访问控制“、”基于方法(method)的访问控制“、和“基于数据的访问控制”。
一般来说，"基于URL的访问控制"是最常见的。要实现一个简单的“基于URL的访问控制”，在基于Java的Web应用中，可以通过增加一个Filter实现，如下：
String url=request.getRequestPath();
User user=request.getSession().get("user");
boolean permit=PrivilegeManager.permit(user,url);
if (permit){
chain.doFilter(request,response);
} else {
//可以跳转到提示页面
}
当访问控制存在缺陷时，会如何呢？我们看看下面这些真实的案例，这些案例来自漏洞披露平台WooYun。
凤凰网分站后台某页面存在未授权访问漏洞，导致攻击者可以胡乱修改节目表：
mop后台管理系统未授权访问：
网易某分站后台存在未授权访问：
这些系统未对用户访问权限进行控制，导致任意用户只要构造出了正确的URL，就能够访问到这些页面。
在正常情况下，这些管理页面是不会被链接到前台页面上的，搜索引擎的爬虫也不应该搜索到这些页面。但是把需要保护的页面“藏”起来，并不是解决问题的办法。攻击者惯用的伎俩是使用一部分包含了很多后台路径的字典，把这些“藏”起来的页面扫出来。
二、垂直权限管理--基于角色(Role)
访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是“基于角色的访问控制”（Role-Based Access Control=RBAC).
在配置权限时，应当使用“最小权限原则”，并使用“默认拒绝”的策略，只对有需要的主题单独配置“允许”的策略。
三、水平权限管理--基于组Group
优酷网用户越权访问问题
用户登录后，可以通过以下方式查看他人的来往信件(只要更改下面地址的数字id即可),查看和修改他人的专辑信息:
http://u.youku.com/my_mail/type_read_ref_inbox_id_52379500_desc_1?__rt=1&__ro=myInboxList
从这个例子可以看到，用户A与用户B可能都属于同一个角色RoleX，但是用户A与用户B都各自拥有一些私有数据，在正常情况下，应该只有用户自己才能访问自己的私有数据。
这就需要水平权限管理。
四、OAuth简介
OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。OAuth 1.0于2007年12月公布，并迅速成为了行业标准。2010年4月，OAuth 1.0正式成为了RFC 5849.
OAuth与OpenID都致力于让互联网变得更加的开放。OpenID解决的是认证问题，OAuth则更注重授权。认证与授权的关系其实是一脉相承的，后来人们发现，其实更多的时候真正需要的是对资源的授权。
比如在人人网上，想要导入用户MSN里的好友，在没有OAuth时，可能需要用户向人人网提供MSN的用户名和密码。
而OAuth则解决了这个信任的问题，它使得用户在不需要向人人网提供MSN用户名和密码的情况下，可以授权MSN将用户的好友名单提供给人人网。
在OAuth 1.0中，涉及3个角色，分别是：
1）Consumer:消费方(client)
2）Service P弱智的人：服务提供方(Server)
3）User：用户(Resource Owner)
Client是人人网，Server是MSN，Resource Owner是用户。
事实上，自己完全实现一个OAuth协议对于中小网站来说并没有太多必要，，因此使用第三方实现的OAuth库也是一个较好的选择。目前有以下比较知名的OAuth库可供开发者选择：
...
现在已经有了OAuth2.0.
没有评论:
发表评论