第3 章 认证与授权的攻击与防护 【本章重点】 掌握认证与授权的攻击定义以及特点。 【本章难点】 熟悉认证与授权的攻击原理,掌握对攻击的防护方法。 3.1 认证与授权攻击背景与相关技术分析 3.1.1 认证与授权的攻击定义 认证(Authentication):是指验证你是谁,一般需要用到用户名和密码进行身份 验证。授 权(Authorization):是指你可以做什么,而且这发生在验证通过后,能够做什么操 作。例如,对一些文档的访问权限、更改权限、删除权限,需要授权。 通过认证系统确认用户的身份。通过授权系统确认用户具体可以查看哪些数据,执 行哪些操作。 3.1.2 认证与授权的特点 1.认证 (1)密码维度:单因素认证、双因素认证、多因素认证(密码、手机动态口令、数字证 书、指纹等各种凭证)。 (2)密码强度: . 长度:普通应用6位以上;重要应用8位以上,考虑双因素。 . 复杂度:密码区分大小写;密码为大写字母、小写字母、数字、特殊符号中两种以 上的组合;不要有(语义上)连续性的字符,如123、abc;避免出现重复字符,如 111;不要使用用户的公开数据,或与个人隐私相关的数据作为密码,如QQ 号、身 份证号、手机号、生日、昵称、英文名、公司名等。 (3)密码保存:密码必须以不可逆的加密算法,或单项散列函数算法加密后存储在 数据库中。目前业界比较普遍的做法:在用户注册时就已经将密码哈希(MD5、SHA-1、 SHA-2)后保存在数据库中,登录时验证密码仅是验证用户提交的密码哈希值是否与保 存在数据库中的密码哈希值一致,即服务器不会保存密码原文。 破解MD5加密后密码的方法是彩虹表:收集尽可能多的明文密码和对应MD5值, 然后通过MD5 值反查到该MD5 值对应的密码原文。防御方法:加盐,即MD5 30 Web 安全开发与攻防测试 (Username+Pasword+Salt),其中Salt为一个固定的随机字符串,应该保存在服务器 端的配置文件中,妥善保管。目前,MD5与SHA-1都不安全,SHA-2相对安全,不易被 彩虹表碰撞出原始密码。 (4)SesionID(会话编号):当登录认证成功后,服务器分配一个唯一凭证SesionID 作为后续访问的认证媒介。会话(Sesion)中会保存用户的状态和其他相关信息,当用户 的浏览器发起一次访问请求时,将该用户持有的SesionID上传给服务器。常见的做法 是将SesionID加密后保存在Cookie中,因为Cookie会随着HTTP请求头发送,且受到 浏览器同源策略的保护。生成的SesionID要足够随机,比较成熟的开发框架都会提供 Cookie管理、Sesion管理的函数,要善用这些函数和功能。 SesionID可能带来的风险:一旦有效的SesionID泄露,则在其有效期内攻击者能 够以对应用户的身份访问站点。泄露方式:Cookie泄露(SesionID保存在Cookie中的 情况),Referer的URL中泄露(URL携带SesionID的情况)。 SesionFixation攻击:SesionID没有及时更替、销毁,导致旧的SesionID仍然有 效,一旦激活,便可以正常使用。 防御方法:在用户登录完成后要重新设置SesionID;用户更换访问设备的时候要求 重新登录;使用Cookie代替SesionID的作用。 Sesion保持攻击:Sesion是有生命周期的,当用户长时间未活动,或用户单击退出 后,服务器将销毁Sesion。 ①如果只依赖Sesion的生命周期控制认证的有效期,Sesion保持攻击可以通过脚 本持续刷新页面(发送访问请求)保持Sesion的活性。 ②如果SesionID保存在Cookie中,依赖Cookie的定时失效机制控制认证的有效 期,那么Sesion保存攻击可以手动修改Cookie的失效时间,甚至将Cookie设置为永久 有效的Third-partyCookie,以此延长Sesion的活性。 防御方法:用户登录一定时间后强制销毁Seo当用户的客户端(eAget、 sin; IP 、UsrnDevice)发生变化的时候要求重新登录;每个用户只允许拥有一个Sesion。 (5)单点登录(SingleSignOn,SSO):统一认证,缺点是风险集中,单点一旦被攻破, 影响范围涉及所有用单点登录的系统,降低这种风险的办法是在一些敏感的系统里再单 独实现一些额外的认证机制(如网上支付平台,在付款前要求用户输入支付密码,或通过 手机短信验证用户身份)。 目前业内最开放和流行的单点登录系统是OpenID(一个开放的单点登录框架),其 使用URI作为用户在互联网上的身份标识。每个用户将拥有一个唯一的URI 。用户登 录网站时只提交他的OpenID(URI)以及OpenID的提供者,网站就会将用户重定向到 OpenID的提供者进行认证,认证完成后重定向回网站。 例如,用户Ricky在OpenID服务的提供者openidprovidercom拥有一个URI,即 riky.peirvdrc页(.) www.xc condpoie.om;此时他准备访问某网站的一个面(xx.om/ yyy.html),在xxx网站的登录界面会提示请用OpenID登录;于是,Ricky输入他的 OpeID(URI), iky.pndpoie.om, 页面将跳转到oeirvdr n即rcoeirvdrc然后登录; pndpoie. com站点, 认证成功后, xx.h如果认 进入认证阶段; 页面自动跳转到www.xcom/yyy.tml, 第 3 章 认证与授权的攻击与防护 31 证失败,则不会跳转。 2.授权 Web应用中,根据访问客体的不同,常见的访问控制可分为基于URL的访问控制 (常用)、基于方法的访问控制和基于数据的访问控制。 (1)垂直权限管理:定义角色,建立角色与权限的对应关系———基于角色的访问控 制(Role-BasedAcesControl,RBAC )。用户→角色→权限。例如,SpringSecurity中 的权限管理(功能强大,但缺乏一个管理界面可供用户灵活配置,每次调整权限都要重新 修改配置文件或代码);PHP框架ZendFramework中使用ZendACL做权限管理。使用 RBAC模型管理权限时应当使用“最小权限原则”“默认拒绝”。 (2)水平权限管理:水平权限问题出现在RBAC模型中的同一种角色的权限控制 上,系统只验证了能访问数据的角色,但没有反过来再对用户与数据的权限关系进行细 分,此时需要基于数据的访问控制。 (3)OAuth:OAuth是一个在不提供用户名和密码的情况下,授权第三方应用访问 Web资源的安全协议。三个角色:用户(User)、服务提供方(Server)、资源持有者 (r)。现在的版本是OAu0。 ResourceOwneth2. 没必要自己完全实现一个OAuth协议,使用第三方实现的OAuth库是一个不错的 选择。 3.1.3 认证与授权攻击产生的原理 1.权限 很多系统(如CRM 、ERP 、OA)中都有权限管理,其中的目的一个是为了管理公司内 部人员的权限,另外一个是避免人人都有权限,一旦账号泄露,对公司带来负面影响。 权限一般分为两种:访问权限和操作权限。访问权限即某个页面的权限,对于特定 的一些页面,只有特定的人员才能访问。而操作权限指的是页面中具体到某个行为,肉眼 能看到的可能就是一个审核按钮或提交按钮。 权限的处理方式可以分为两种:用户权限和组权限。设置多个组,不同的组设置不 同的权限,而用户设置到不同的组中,那就继承了组的权限,这种方式就是组权限管理,一 般使用这种方式管理。用户权限管理则比较简单,对每个用户设置权限,而不是拉入某个 组里面,这种方式灵活性不强,用户多的时候比较费劲,每次都要设置很久的权限,而一部 分用户权限是有共性的,所以组权限是目前常用的处理方式。 在权限方面,还包括数据库的权限、网站管理的权限以及API/Service的权限。 DBA需要控制好IDC的数据库权限,而不是将用户权限设置为*.*,需要建立专门 供应用程序使用的账号,并且需要对不同的数据库和不同的表赋予权限,专门供应用程序 使用的账号就不能进行更改表、更改数据库及删除操作,否则如果有SQL注入漏洞或程 序中有Bug,黑客就能轻易连接到数据库获取更多的信息。因为DBA账号除了可以更改 数据库结构、数据及配置外,还可以通过LOADDATAINFILE读取某个文件,相当于整 台服务器都被控制了。 API可以分为PrivateAPI和OpenAPI 。PrivateAPI一般是不希望外网访问的,如 32 Web 安全开发与攻防测试 果架设在内网,最好使用内网IP访问,如果是公网,最好设置一定的权限管理。Open API的权限就相对复杂很多,除了校验参数正确性,还须校验用户是否在白名单中,若在 白名单里,还须校验用户对应的权限,有些时候还需要考虑是否要加密传输等。 2.密码猜测 以下哪种错误提示更合适呢? .输入的用户名不正确。 .输入的密码不正确。 .输入的用户名或密码不正确。 前面两种提示信息其实是在暗示用户正确输入了什么,哪个不正确。第三种提示信 息比较模糊,可能是用户名错误,也可能是密码错误。如果非要说前两种提示信息更准 确,更适于普通用户,就会给黑客们带来可乘之机,实在不知道到底是哪个错误,难度增加 不少。若使用工具或批处理脚本强制枚举破解,则需要的时间更多。 2011年11月22日,360安全中心发布了中国网民最常用的25个“弱密码”: 000000 、111111 、11111111 、112233 、123123 、123321 、123456 、12345678 、654321 、666666 、 888888 、abcdef、abcabc、abc123 、a1b2c3、 a111 、123qwe 、qwerty、qweasd、admin、 pasword、p@ sword、paswd 、iloveyou、5201314 。 如何应对密码猜测攻击呢? 一般有以下3种方案: .超过错误次数账户锁定。 .使用RSA/验证码。 .使用安全性高的密码策略。 很多网站将三种方案结合起来使用。另外,在保存密码到数据库时,也一定要检查是 否经过严格的加密处理,不要再出现某天网站被暴库了结果却保存的是明文密码。 3.找回密码的安全性 最不安全的做法是在邮件内容中发送明文新密码,一旦邮箱被盗,对应网站的账号也 会被盗;一般做法是在邮件中发送修改密码链接,测试时就需要特别注意用户信息标识是 否加密、加密方法以及是否易破解;还有一种做法是修改密码时回答问题,问题回答正确 才能进行修改。 4.注册攻击 常见的是恶意注册,以避免注册后被恶意搜索引擎爬取,在线机器人投票,注册垃圾 邮箱等。缓解注册攻击的方法:使用RSA/验证码。 5.Cookie安全 Cookie中记录着用户的个人信息、登录状态等。使用Cookie欺骗可以伪装成其他 用户获取隐私信息等。 常见的Cookie欺骗有以下4种方法: .设置Cookie的有效期。 .通过分析多账户的Cookie值的编码规律,使用破解编码技术任意修改Cookie的 值达到欺骗目的,这种方法较难实施。 .结合XSS攻击上传代码获取访问页面用户Cookie的代码,获得其他用户的 第 3 章 认证与授权的攻击与防护 33 Cookie。 .通过浏览器漏洞获取用户的Cookie,这种方法需要非常熟悉浏览器 。 如何防范 ? .不要在Cookie中保存敏感信息。 .不要在Cookie中保存没有经过加密的或者容易被解密的敏感信息。 .对从客户端取得的Cookie信息进行严格校验,如登录时提交的用户名、密码的正 确性。 .记录非法的Cookie信息进行分析,并根据这些信息对系统进行改进。 .使用SSL传递Cookie信息。 .结合Sesion验证对用户访问授权。 .及时更新浏览器漏洞。 .设置HtpOnly增强安全性。 .实施系统安全性解决方案,避免XSS攻击。 6.Sesion安全 服务端和客户端之间通过Sesion连接沟通。当客户端的浏览器连接到服务器后, 服务器就会建立一个该用户的Sesion。每个用户的Sesion都是独立的,并且由服务器 维护。每个用户的Sesion由一个独特的字符串识别,成为SesionID 。用户发出请求 时,所发送的htp表头内包含SesionID的值。服务器使用htp表头内的SesionID识 别是哪个用户提交的请求。一般SesionID传递方式:URL中指定Sesion或存储在 Cookie中,后者广泛使用。 会话劫持是指攻击者利用各种手段获取目标用户的SesionID 。一旦获取到 SesionID,攻击者可以利用目标用户的身份登录网站,获取目标用户的操作权限。 攻击者获取目标用户SesionID的方法: .暴力破解:尝试各种SesionID,直到破解为止。 .计算:如果SesionID使用非随机的方式产生,那么就有可能计算出来。 .窃取:使用网络截获、XSS 、CSRF攻击等方法获得 。 如何防范 ? .定期更改SesionID,这样,每次重新加载都会产生一个新的SesionID 。 .只从Cookie中传送SesionID结合Cookie验证。 .只接受Server产生的SesionID 。 .只在用户登录授权后生成Sesion或只在用户登录授权后变更Sesion。 .为SesionID设置Time-Out时间。 .验证来源,如果Refer的来源是可疑的,就刪除SesionID 。 .如果用户代理user-agent变更,就重新生成SesionID 。 .使用SSL连接。 .防止XSS 、CSRF漏洞。 34 Web 安全开发与攻防测试 3.认证与授权攻击经典案例重现 2 3.2.1 试验1: Zero 网站能获得管理员身份数据 缺陷标题:网站htp://zeo.bppeuiy.om/在地址栏追加admin可进入管理 rweascrtc 员页面 测试平台与浏览器:Wis10+IE11或Ch0浏览器 ndowrome45. 测试步骤 : (1)打开网站htp://zeo.eascrtcom /。 rwbppeuiy. (2)在地址栏后追加admin,按Enter键。 期望结果:浏览器提示无法找到网页,或者出现管理员登录页面。 实际结果:跳转到管理员页面,单击Users链接能看到系统中所有的用户名与密码, 结果如图3-1和图3-2所示。 图3- 1 进入管理员页面 【攻击分析】 这是典型的身份认证与会话管理方面的安全问题,2017年,失效的身份认证排在全 球Web安全第二位。身份认证,最常见的是登录功能,往往是提交用户名和密码,在安全 性要求更高的情况下,有防止密码暴力破解的验证码、基于客户端的证书、物理口令卡等。 会话管理,HTTP本身是无状态的,利用会话管理机制实现连接识别。身份认证的 结果往往是获得一个令牌,通常放在Cookie中,之后对用户身份根据这个授权的令牌进 行识别,而不需要每次都登录。 用户身份认证和会话管理是一个应用程序中最关键的过程,有缺陷的设计会严重破 坏这个过程。在开发Web应用程序时,开发人员往往只关注Web应用程序所需的功能。 由于这个原因,开发人员通常会建立自定义的认证和会话管理方案。但要正确实现这些 方案却很难,结果这些自定义的方案往往在如下方面存在漏洞:退出、密码管理、超时、记 第 3 章 认证与授权的攻击与防护 35 图3- 2 查看到系统中所有的用户名与密码 住我、账户更新等。因为每个系统实现都不同,业务定义也不同,要找出这些漏洞,有时会 很困难。 如何验证程序是否存在失效的认证和会话管理? 最需要保护的数据是认证凭证(Credentials)和会话ID 。 (1)当存储认证凭证时,是否总是使用哈希或加密保护? (2)认证凭证是否可猜测,或者能够通过薄弱的账户管理功能(例如账户创建、密码 修改、密码恢复、弱会话ID)重写? (3)会话ID是否暴露在URL里(例如,URL重写)? (4)会话ID是否容易受到会话固定(SesionFixation)的攻击? (5)会话ID会超时吗?用户能退出吗? (6)成功注册后,会话ID会轮转吗? (7)密码、会话ID和其他认证凭据是否只通过TLS(传输层安全)连接传输? 3.2.2 试验2: CTFPostbook 用户 A 能修改用户 B 的数据 缺陷标题:CTFPostbook网站>用户A登录后,可以修改其他用户的数 据 测试平台与浏览器:Windows10+IE11或Chrome浏览 器 测试步骤 : (1)打开国外安全夺旗比赛网站主页htps://cfhce101.om/ctf,如果已有账 户,则直接登录;如果没有账户,请注册一个账户并登录 t 。 .akrc (2)登录成功后, otok网站htp//t.akrccfluc如 图3-3所示。 请进入Psbos:cfhce101.om/t/anh/7, (3)单击Signup链接注册两个账户,如admin/admin,abcd/bacd。 36 Web 安全开发与攻防测试 图3- 3 进入Postbok网站 (4)用admin/admin登录,然后创建两个帖子,再用abcd/abcd登录创建两个帖子。 (5)观察abcd用户修改帖子的链接:XXX/nephp?pg=dtphp&i=5。 idx.aeei.d (6)篡改步骤(5)URL中的id为1,2等,以abcd身份修改admin或其他用户的帖 子,如图3-4所示。 图3- 4 用户abcd篡改URL,修改其他用户的帖子 37 第 3 章 认证与授权的攻击与防护 期望结果:因身份权限不对,拒绝访问。 实际结果:用户abcd能不经其他用户许可,任意修改其他用户的数据,成功捕获 Flag,如图3-5所示。 图3- 5 用户abcd成功修改用户admin的帖子,成功捕获Flag 【攻击分析 】 在Web安全测试中,权限控制出错的例子非常多,例如 : (1)用户A,在电子书籍网站购买了三本电子书,然后用户A单击书名就能阅读这些 电子书,每本电子书都有bookid,用户A通过篡改URL,把bookid换成其他id,就有可能 可以免费看别人购买的电子书籍。 (2)普通用户A,拿到了管理员的URL,试图去运行,结果发现自己也能操作管理员 的界面。 (3)普通用户A,找到修改/删除自己帖子的URL,通过篡改URL把帖子id改成其 他人的id,就可以修改/删除别人的帖子。 软件工程师在实现基本功能后,需要考虑不具有权限的人是否能直接进行这些非法 操作。 3.2.3 试验3: CTF Postbook 用户 A 能用他人身份创建数据 缺陷标题:CTFPostbook网站>用户A登录后,可以用他人身份创建数 据 测试平台与浏览器:Windows10+IE11或Chrome浏览 器 测试步骤 : (1)打开国外安全夺旗比赛网站主页htps://t.akrccf,如果已有账 cfhce101.om/t 户,则直接登录;如果没有账户,请注册一个账户并登录。 (2)登录成功后,请进入Posbok网站hs://cfhce101.om/t/luch/7。 totpt.akrccfan (3)单击Signup链接注册两个账户,如admin/admin,abcd/bacd,如果已有账户, 请忽略此步。 (4)用abcd/abcd登录,单击Writeanewpost链接,在这个页面右击,选择“检查 (net)出现图36。 发现Tiltte) eiePsbdy) Isc,(”) p(5)观察右端源代码, te(il字段是必填项rqurd,ot(o字段也是 38 Web 安全开发与攻防测试 图3- 6 创建一个新帖Writeanewpost 必填项required,当前的帖子是登录用户user_id为3。 (6)篡改步骤(5)中的源代码,将Title后面的required删除,将Post后的required 删除,将user_id改为1。 期望结果:因必填字段未填,并且因身份权限不对,故拒绝访问。 实际结果:用户abcd能绕过客户端必填字段检查,同时以系统第一个用户admin身 份任意创建数据,成功捕获Flag,如图3-7所示。 图3- 7 用户abcd成功以admin身份创建一个空白帖子,成功捕获Flag 【攻击分析 】 本例实际至少用到3种攻击方法,所以有时候系统的漏洞可以用多种手段进行攻击 。 (1)客户端绕行:本书第15 章有详细讲解,就是常见的限制只有客户端的防护,没有 39 第 3 章 认证与授权的攻击与防护 服务器端的防护,这样就导致攻击者能通过各种工具或手段轻松绕过客户端的防护,直接 把非法数据提交到后台数据库。本例中,如果没有删掉title后面的required字段,那么 空白标题是提交不成功的。 (2)HTTP参数篡改:本书第8章有详细讲解,就是用户通过各自的工具或手段将 原先要提交到服务器端的参数值进行篡改,后台没有做相应的防护,导致数据直接提交到 后台数据库。本例中,登录的那个人user_id是3,默认情况下创建/修改都是自己的帖 子,但是攻击者通过各种工具或方法将user_id篡改成1,一般系统的第一个用户都是 admin,所以如果后台没有做身份权限校验,就以admin身份创建数据了。 (3)认证与授权错:本例是普通用户,通过篡改自己的user_id为其他人的user_id, 可以给系统中任何存在的一个人创建帖子,即使是管理员账户数据,也能被普通用户 创建。 3.认证与授权攻击的正确防护方法 3 3.3.1 认证与授权总体防护思想 每个资源在访问前,首先要确认谁可以访问,能做什么操作。 基本授权条款见表3-1。 表3- 1 基本授权条款 User(用户) Group(组) Role(角色) Rule(规则) Permisions(权限) 常见的授权类型: 对象尝试执行任务或访问数据 需要访问资源的对象集合 执行功能所需的任务集合 检查对象是否应该能够访问资源的逻辑 用于确定对象是否应该有权访问资源的属性 1.自主访问控制(DiscretionaryAces Control,DAC) 资源所有者设置的权限,可分配授权(Asignableauthorization),由客体的属主对自 己的客体进行管理,由属主自己决定是否将自己的客体访问权或部分访问权授予其他主 体,这种控制方式是自主的。也就是说,在自主访问控制下,用户可以按自己的意愿,有选 择地与其他用户共享他的文件。 2.基于角色的访问控制(Role-BasedAces Control,RBAC) 用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每个角色拥有若 干权限,这样就构成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角 色与权限之间一般都是多对多的关系。 其基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与 权限集合之间建立一个角色集合。每种角色对应一组相应的权限。一旦用户被分配了适 40 Web 安全开发与攻防测试 当的角色,该用户就拥有此角色的所有操作权限。这样做的好处是,不必在每次创建用户 时都进行分配权限的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的 权限变更要少得多,这样将简化用户的权限管理,减少系统的开销。 3.基于规则的访问控制(Rule-BasedAces Control) 基于规则的安全策略系统中,所有数据和资源都标注了安全标记,用户的活动进程与 其原发者具有相同的安全标记。系统通过比较用户的安全级别和客体资源的安全级别, 判断是否允许用户进行访问。这种安全策略一般具有依赖性与敏感性。 4.数字版权管理(DigitalRightsManagement,DRM) 版权保护机制,用于保护内容创建者和未授权的分发 。 5.基于时间的授权(TimeBasedAuthorization,TBA) 根据时间对象请求,确定访问资源 。 3.3.2 能引起认证与授权的错误代码段 系统没有做任何访问与授权控制,任何人通过拼凑的URL,不用登录就可访问只有 管理员可以运行的URL 。 系统仅做了部分的访问控制,许多需要登录才能访问的URL没有配置到登录验证 中,导致任何人都可以删除、修改他人的敏感信息。 系统只做了登录认证,没有做严格的授权控制,导致用户A登录后,可以通过篡改 URL修改与删除他人的资料。 错误的情况错综复杂,这里不列具体的错误代码段,请参考3.3节的正确代码段。 3. 3.3.3 能防护认证与授权的正确代码段 如果某操作只有登录用户可以执行,则可以将logncnixml文件修改为如图38 所示的代码段。 o-ofg. 图3- 8 只有登录用户才能操作 从这个XML定义,可以看到uploadfile操作需要登录保护。运行user/fileupload/ 41 第 3 章 认证与授权的攻击与防护 uploadAction这个URL 将直接检查用户是否已登录网站,如果没有登录,则显示登录 页面。 在实际应用中,有些URL 只有admin用户才能访问,普通用户无法做到。如果这个 操作只有admin用户可以做,那么可以修改admin-loon-confixml文件为如图3-9所示 的代码段。 gg. 图3- 9 只有admin用户才能操作 对于这种情况,只有admin用户可以执行删除用户操作,如果攻击尝试自己拼装 user/operation/deleteUserAction之类的URL,则直接检查用户是否已经登录并以 admin用户身份登录,如果没有登录,则进入登录页面。如果用低权限用户登录,则阻止 他的操作。 以上两个基于角色的访问控制实际上可以做很多Web安全保护,但远远不够。例 如,用户A在BBS 或博客中发布主题,他不希望用户B编辑或删除它。然而,在这种情 况下,如果只考虑登录情况(身份认证情况), 那么用户B可以删除用户A的内容。 如果此操作只有所有者自己可以做,或高级用户可以做,或管理用户可以做,然后在 auh.l文件中定义为如图3-10 所示的代码段(授权操作)。 txm 图3-10 复杂权限定义 42 Web 安全开发与攻防测试 定义一些功能级别访问控制,例如 : 用户A在一个网站上发布博客,用户A希望每个登录用户都可以查看他的博客 内 容,但不希望其他用户编辑或删除自己的博客。此博客的URL可能如下: (1) . /blog/blogAction?AT=ViewBlog&blogID=*** (2) . /blog/blogAction?AT=EditBlog&blogID=*** (3) . /blog/blogAction?AT=DeleteBlog&blogID=*** 然后,对于ViewBlg操作,只在loo-ofg.l中添加它就会满足要求,但是对于 ogncnixmEdiBlg和DltBlg操作, ogncnixm将导致用 toeeeo如果只在lo-ofg.l中添加登录就能访问, 户B登录站点可以编辑或删除用户A的博客,这是一个巨大的安全漏洞,因此需要在 txm auh.l中使用规则定义,只有满足所有已定义的主体,才可以执行相应的操作。 在autxml中定义了博客所有者(创建这个博客的人OWNER )、版主(该主题博客 h. 的版主MODERATOR )、管理员(博客或网站的管理员ADMIN)可以编辑和删除博客, 其他人想访问这个链接,将出现权限不够的错误提示。 如果系统严格遵循安全设计,那么这些功能级别访问控制需要清晰的定义和实现。 3.3.4 认证与授权最佳实践 (1)确保请求发出者具有相应权限,以执行该请求要进行的操作;如果没有,则拒绝。 (2)拥有产品的授权政策。 (3)每个资源在访问前,首先要确认谁可以访问,能做什么操作。 (4)始终实现最小权限管理。 .不要将所有进程作为root或Administrator运行。 .使用root绑定到端口,然后立即切换到非特权账户。 .sudo<任务名称>,而不是sudosu-。 .如果只需要定期修改,就不要一直留下文件“可写”(writeable)。 (5)总是失败关闭,永远不会对失败打开;验证失败,就要禁止访问。 3.认证与授权攻击动手实践与扩展训练 4 3.4.1 Web 安全知识运用训练 请找出以下网站的认证与授权攻击安全缺陷: (1)tesfre网站:h//demo.etient titp:tsfr. e (2)tsphp网站:h//etvlb.om ettp:tsphp.unwec (3)tesap网站:htp://tsap.unwec tsetsvlb.om (4)tetsnt网站:h//tsape.unwb.om sapetp:etsntvlec (5)zeo网站:htp://zrweascrtc reo.bppeuiy.om (6)cakme网站:htp://rccni.om rccakmeezcc (7)wesatstp:.(.) bcnetc bcnet网站:h//wwwwesats.om 43 第 3 章 认证与授权的攻击与防护 (8)nmap网站:h//sa.p.r tp:cnmenmaog 3.4.2 安全夺旗CTF 训练 请从安全夺旗CTF提供的各个应用中找出认证与授权攻击安全缺陷: (1)Alitlesomethingtogetyoustarted应用:htps://ctf.hacker101.com/ctf/ launch/1 (2)MicoCMSv1应用:htp//cfhce101.om/t/luc r-s:t.akrccfanh/ 2 (r-CMSv2应用:h//takrccf/anh/ 3 3)Micotps:cf.hce101.om/tluc (4)Patbn应用:htp//cfhce101.om/t/luc seis:t.akrccfanh/ 4 (5)PhooGley应用:htp//cfakrccf/anh/ 5 tars:thce101.om/tluc (6)Co..isog应用:hs://(.) t.akrccf/anh/ 6 dysFrtBltpcfhce101.om/tluc (7)Potok应用:htp//cfhce101.om/t/luc sbos:t.akrccfanh/7 (8)Ticeatc:DemoIsace应用:hs://t.akrccf/anh/8 ktsintntpcfhce101.om/tluc(ste应用:h//f101.t/ 9)Ticketatic:LiveInsanctps:ct.hackercom/cflaunch/9 (10)Pesoro应用:hs://t.akrccf/anh/10 thpPtpcfhce101.om/tluc(11)ModelE1337-RolingCodeLock 应用:htps://ctf.hacker101.com/ctf/ launch/11 (e应用:htps://takccf/anh/12 12)TempImagcf.hcer101.om/tluc (13)H1Thesat应用:hs://cfhce101.om/t/luc rmottpt.akrccfanh/13 (14)Mode-reeonook应用:htps://t.akr lE1337v2HadndRligCdeLccfhce101. com/ctf/launch/14 (15)Inetoaecse应用:hs://cfhce101.om/t/luc tninlExritpt.akrccfanh/15 (16)HeloWold!应用:hs://cfhce101.om/t/luc rtpt.akrccfanh/16 提醒1:可以在htp://coeotsrqsfcarsow.tml中查阅历年全 legcnetoiotom/wadhh国高校大学生在这些网站中发现的更多安全相(.) 关的缺(.) 陷 。 提醒2:本章中讲解的安全技术,因为对系统的破坏性很大,为避免产生法律纠纷,请 不要乱用。请在自己设计的网站上测试;或者你已得到授权允许做安全测试,才可以用各 种安全测试技术或安全测试工具进行安全测试(本章动手实践与扩展训练中所举的样例 网站,都是公开可以做各种安全测试的)。