《Web漏洞防护》读书笔记——第7章，访问控制防护

访问控制的分类

1.基于角色的访问控制
2.自助访问控制
3.强制访问控制
4.基于权限的访问控制

常见问题

1.不安全对象的直接引用：
服务端没有验证用户是否有权限访问目标对象，攻击者直接改变参数就能访问到其他对象的信息。
最常见的发生情形是，如通过http://abc.com?id=111来获取用户111用户的详情，如果服务端未进行适当的访问控制，则可以遍历ID参数来获取到所有用户的信息。

不安全对象的直接引用防护措施：
a.不直接引用id为参数，而是改为基于用户ID生成一个随机值进行访问，随机值会在服务端映射到相应的用户ID，这样就增加了攻击者的攻击难度和攻击成本。
b.执行严格的权限检查，对于任何来自不可信任的源的对象引用，必须进行权限检查，确保该用户的所有请求都具有访问权限。
如可以在Cookie中植入一个Token令牌值，该值通过用户ID及其他参数加密生成，用户无法对Token值进行篡改，当请求到达服务器时，通过解密该Token获取用户ID，与参数中的ID值进行比对，确认两个值是否一致，如果不一致则拒绝用户的请求，并进行日志记录。

2.功能级访问控制缺失：
如果配置出现错误，会造成用户对应用程序的任意访问，如匿名用户可以访问死人数据，普通用户可以访问特权页面，甚至是管理员页面。

3个方面着手去验证：
a.用户界面UI是否存在未授权的功能导航
b.服务端的身份认证和授权功能是否足够完善
c.服务端的权限检查是否仅依赖用户所提供的数据

先以特权用户的身份浏览所有的功能，然后切换到普通用户身份再次访问所有页面，如果对于受限制的页面，服务器对两者的响应是一样的，则很可能存在问题。

需要注意的：
a.确保权限管理模块容易进行升级和审计，避免硬编码。
b.对于每个功能的访问，需要明确其访问权限。
c.当权限管理的执行机制缺失时，应当拒绝所有的访问。
d.对于不应该显示的未授权的链接和按钮，应该在服务端执行检查，不应该在前端进行检查。

CORS跨域资源共享机制

该机制允许Web应用服务器进行跨域访问控制，使得跨域数据传输得以安全进行。

网站通过发送如下HTTP响应头来启用CORS：
Access-Control-Allow-Origin:https://example.com

服务端可以配置Access-Control-Allow-Credentials:true来启用凭证cookie的传输。

如果允许多个源进行跨域请求，可以使用通配符设置(启用了通配符，就不能使用携带凭证的配置，因为CORS规范规定使用携带凭证的请求时，必须指定域名，不能使用通配符，可以保护用户的凭证信息)：
Access-Control-Allow-Origin:*

需要注意的问题：
服务器根据用户提供的Origin值来生成Access-Control-Allow-Origin标头，但是不会对Origin值进行校验或者校验不严格，如example.com信任以example.com结尾的任何Origin头，可以构造一个hackerexample.com的Origin头，对于包含“Access-Control-*”的响应头，服务器很有可能就会根据用户与输入的信息生成相关的头信息。

CORS的防护

需要对Origin参数进行严格检查，病设置Access-Control-Allow-Origin头的白名单机制。
Access-Control-Allow-Origin如果被设置为null，会造成Origin为null的请求，从而获得用户凭证，因此需要禁止将Access-Control-Allow-Origin设置为null

漏洞产生的根本原因：
程序需要携带用户凭证进行跨域的资源访问，可以使用请求转发的方式来突破跨域的限制，目前最常用的方法是使用Node.js搭建中转服务器，来进行请求的转发操作。

CORS的工具防护

1.通过Apache Shiro框架实现访问控制（管理授权的3个核心元素：权限、角色、用户）
2.通过ESAPI实现对象的随机化引用
3.通过Spring Security实现CORS的配置