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

《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的配置

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页