认证和授权类漏洞挖掘指南

莫慌搞安全

已于 2024-07-17 11:08:15 修改

阅读量1k

点赞数 18

分类专栏： # web安全性测试指南（全套）文章标签： web安全网络安全

于 2024-07-10 18:21:22 首次发布

本文链接：https://blog.csdn.net/u014247926/article/details/140326320

版权

web安全性测试指南（全套）专栏收录该内容

3 篇文章 0 订阅

订阅专栏

认证和授权类漏洞挖掘指南

在网络安全领域，认证和授权机制是保护系统不受未授权访问的关键。然而，如果这些机制实现不当，就可能成为攻击者利用的漏洞。本文将详细介绍常见的认证和授权类漏洞，以及如何检测和修复这些漏洞。

1. 任意文件下载漏洞

描述

目录遍历（任意文件下载）漏洞不同于网站目录浏览，此漏洞不仅仅可遍历系统下web中的文件，而且可以浏览或者下载到系统中的文件，攻击人员通过目录遍历攻击可以获取系统文件及服务器的配置文件等等。一般来说，他们利用服务器API、文件标准权限进行攻击。严格来说，目录遍历攻击并不是一种web漏洞，而是网站设计人员的设计“漏洞”。如果web设计者设计的web内容没有恰当的访问控制，允许http遍历，攻击者就可以访问受限的目录，并可以在web根目录以外执行命令。

检测方法

1.通过web漏洞扫描工具对网站实施扫描可能发现目录遍历或者任意文件下载漏洞，发送一系列”…/”字符来遍历高层目录，并且尝试找到系统的配置文件或者系统中存在的敏感文件。
2.也可通过判断网站语言，并根据其url中部分提供的参数，进行构造相关的路径信息，如收集到网站中间件版本为apache，则想办法构造…/…/…/ WEB-INF/web.xml等，然后查看其是否可被下载出来。随后可构造下载系统文件。

评价

根据我实际测试来看，使用web漏扫即可，burp、AWVS、开源的有nuclei，还有kali下面和国内都喜欢用的目录扫描器即可，高手请随意手工，git上也有常见的目录字典，自行搜索。

修复方案

对文件操作功能，做到以下几点：

1.要下载的文件地址保存至数据库中。
2.文件路径保存至数据库，让用户提交文件对应ID下载文件。
3.下载文件之前做权限判断。
4.文件放在web无法直接访问的目录下。
5.记录文件下载日志（内容见日志章节）。
6.不允许提供目录遍历服务。

2. 越权访问漏洞

描述

越权访问，这类漏洞是指应用在检查授权（Authorization）时存在纰漏，使得攻击者在获得低权限用户帐后后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的高权限功能。在实际的代码安全审查中，这类漏洞往往很难通过工具进行自动化检测，因此在实际应用中危害很大。其与未授权访问有一定差别。目前存在着两种越权操作类型：横向越权操作和纵向越权操作。前者指的是攻击者尝试访问与他拥有相同权限的用户的资源；而后者指的是一个低级别攻击者尝试访问高级别用户的资源,如图所示的情况
在这里插入图片描述

检测条件

1.Web业务存在不同级别的权限（垂直越权）
2.通过用户鉴权站内进行功能的操作。

检测方法

1.以超管 admin（高权限用户）身份登录系统
2.找到一个只有超管（高权限）才有的功能的链接,比如说:“http://localhost/mywebappname/userManage/userList.do” , 显示出所有的user,并复制此链接.
3.以普通用户登陆进系统,在地址栏输入: userManage/userList.do ,如果可以查看到其所有的user，则就造成了,普通用户的越权访问

评价

水平越权和垂直越权，垂直越权更容易发生，水平越权相对少见，但是在不同人功能项不同的系统中，水平越权是很容易出现的。另外未授权也是越权的一种，未授权是更容易发生的，测试的时候，可以根据系统的功能，来判断更容易发生水平越权还是垂直越权，至于未授权，是一定要单独测试的。

修复方案

对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对请求的数据和当前用户身份做一个校验检查。流程描述：在服务器接收到用户发送的页面访问请求时，根据预设的识别策略，从用户的页面访问请求中提取该用户对应的用户唯一标识信息，同时提取所述页面访问请求对应的应答页面中的表单及该表单中不可修改参数，将所述表单及不可修改参数与所述用户唯一标识信息绑定后记录到参数列表中；检测到用户提交请求页面的表单时，将所述请求页面的表单及不可修改参数与该用户对应的所述参数列表中记录的表单及不可修改参数进行比对，控制该用户的访问。

3. 弱口令漏洞

描述

弱口令漏洞是由于使用了容易被猜测的密码。

检测条件

存在可爆破的登录端口，如SSH、FTP、mysql、RDP、Redis等。

检测方法

1.尝试使用常见密码如：123456，password，111111等尝试登陆。
2.使用默认口令进行登陆，如设备的初始密码，身份证后六位等尝试登陆；
尝试用burpsuite进行暴力破解：

评价

弱口令是必备检查项，尤其是内网测试，构造合理的弱口令往往是取胜的关键，如果在域下面有一个机器的shell，可以尝试获取整个域的所有用户，然后在组合构建字典,弱口令工具较多，随意找适合自己的，界面的超级弱口令检查工具不错，终端的hydra,fscan等。

修复方案

使用强密码策略，并限制登录尝试次数。

4. 文件上传漏洞

描述

文件上传漏洞，直面意思可以利用WEB上传一些特定的文件。一般情况下文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。文件上传本身是web中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。一般的情况有：

1. 上传文件WEB脚本语言，服务器的WEB容器解释并执行了用户上传的脚本，导致代码执行；
1. 上传文件FLASH策略文件crossdomain.xml，以此来控制Flash在该域下的行为；
1. 上传文件是病毒、木马文件，攻击者用以诱骗用户或管理员下载执行；
. 上传文件是钓鱼图片或为包含了脚本的图片，某些浏览器会作为脚本执行，实施钓鱼或欺诈；

检测条件

1.已知Web网站在登录前或者登录后具有上传页面。
2.上传的文件具备可执行性或能够影响服务器行为，所以文件所在的目录必须在WEB容器覆盖的路径之内；
3.用户可以从WEB上访问这个文件，从而使得WEB容器解释执行该文件；
4.上传后的文件必须经过安全检查，不会被格式化、压缩等处理改变其内容

检测方法

上传方式根据不同的web语言，检测方法也各式各样，以下列举基于JS验证的上传的几种常见的文件上传绕过方法：
1、我们直接删除代码中onsubmit事件中关于文件上传时验证上传文件的相关代码即可。如图：
在这里插入图片描述

2、直接更改文件上传JS代码中允许上传的文件扩展名你想要上传的文件扩展名，如图所示：
在这里插入图片描述

3、使用本地提交表单即可，如下图，作相应的更改，如图所示：
在这里插入图片描述

4、使用burpsuite或者是fiddle等代理工具提交，本地文件先更改为jpg，上传时拦截，再把文件扩展名更改为asp即可，如图所示：
在这里插入图片描述

5、当然也有不是基于JS验证的上传，例如一些中间件IIS，Nginx,，PHP,FCK编辑器等等的解析漏洞，其上传绕过方式也是多种多样。通过对上传页面进行检查，常见的文件上传检查针对文件类型进行，可以使用手动修改POST包然后添加%00字节用于截断某些函数对文件名的判断。除了修改文件名来绕过类型检查外，还可以修改文件头来伪造文件头，欺骗文件上传检查，如图，修改文件头中的类型来进行绕过：
在这里插入图片描述

以上为几种常见的上传，更多的还需自行研究，进行上传绕过。以下为总体的测试流程：

1. 登陆网站，并打开文件上传页面
1. 点击“浏览”按钮，并选择本地的一个JSP文件（比如hacker.jsp），确认上传。
1. 如果客户端脚本限制了上传文件的类型（比如允许gif文件），则把hacker.jsp更名为hacker.gif；配置HTTP Proxy（burp）进行http请求拦截；重新点击“浏览”按钮，并选择hacker.gift，确认上传。
1. 在WebScarab拦截的HTTP请求数据中，将hacker.gif修改为hacker.jsp，再发送请求数据。
1. 登陆后台服务器，用命令find / -name hacker.jsp查看hacker.jsp文件存放的路径。如果可以直接以Web方式访问，则构造访问的URL，并通过浏览器访问hacker.jsp，如果可以正常访问，则已经取得WebShell，测试结束。如果hacker.jsp无法通过web方式访问，例如hacker.jsp存放在/home/tmp/目录下，而/home/tomcat/webapps目录对应http://www.example.com/，则进行下一步
1. 重复1～3，在burp拦截的HTTP请求数据中，将hacker.gif修改为…/tomcat/webapps/hacker.jsp，再发送请求数据。
  在浏览器地址栏输入http://www.example.com/hacker.jsp，访问该后门程序，取得WebShell，结束检测。

评价

文件上传是一个值得写一个专题的内容，建议大家通过打靶机练习上传，经典靶机upload-labs，大家自行搜索练习，这个靶机难度适中，其实建议每一个安全员都去练习一下，虽然场景不打也就忘记了o(╯□╰)o。

修复方案

针对文件上传漏洞的特点和必须具备的三个条件，我们阻断任何一个条件就可以达到组织文件上传攻击的目的：
1、最有效的，将文件上传目录直接设置为不可执行，对于Linux而言，撤销其目录的’x’权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理，一是方便使用缓存加速降低能耗，二是杜绝了脚本执行的可能性；
2、文件类型检查：强烈推荐白名单方式，结合MIME Type、后缀检查等方式（即只允许允许的文件类型进行上传）；此外对于图片的处理可以使用压缩函数或resize函数，处理图片的同时破坏其包含的HTML代码；
3、使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件；
4、单独设置文件服务器的域名（即存储文件服务器跟web网站服务器不在同一个根目录下，最佳是跟web服务器分离）；

5. 用户名可枚举

描述

存在于系统登录页面，利用登陆时输入系统存在的用户名错误密码和不存在的用户名错误密码，返回不同的出错信息可枚举出系统中存在的账号信息。

检测条件

1. 已知Web网站具有登录页面。
1. 登录错误回显不一至。

检测方法

1、找到网站或者web系统登录页面。
2、在web系统登录页面，通过手工方式，利用系统中存在的用户名和不存在的用户名，密码随意，尝试登录，查看其回显内容。例如：输入存在的用户名admin，回显如下：密码错误；输入不存在的用户名test，回显如下：用户不存在。如图所示：

在这里插入图片描述

评价

这里的测试用例是用户名枚举，类似的还有手机号枚举，邮箱枚举等等，要举一反三

修复方案

1.建议对网站登录页面的判断回显信息修改为一致：用户名或密码错误
2.对于连续失败5次的账户，进行5分钟的锁定；

6. 暴力攻击

描述

暴力破解的基本思想是根据题目的部分条件确定答案的大致范围，并在此范围内对所有可能的情况逐一验证，直到全部情况验证完毕。若某个情况验证符合题目的全部条件，则为本问题的一个解；若全部情况验证后都不符合题目的全部条件，则本题无解。常常存在于网站的登录系统中，通过对已知的管理员用户名，进行对其登录口令的大量尝试。

检测方法

1、找到网站登录页面。
2、利用burp对登录页面进行抓包，将其发送到Intruder,并设置其密码参数，如pwd=为变量，添加payload（字典），进行攻击，攻击过程中查看其返回的字节长度，来判断是否成功。攻击效果如图所示：
在这里插入图片描述

修复方案

防止暴力攻击的一些方法如下：

1. 账户锁定
  账户锁定是很有效的方法，因为暴力破解程序在5-6次的探测中猜出密码的可能性很小。但是同时也拒绝了正常用户的使用。如果攻击者的探测是建立在用户名探测成功之后的行为，那么会造成严重的拒绝服务攻击。对于对大量用户名只用一个密码的探测攻击账户锁定无效。如果对已经锁定的账户并不返回任何信息，可能迷惑攻击者。
1. 返回信息
  如果不管结果如何都返回成功的信息，破解软件就会停止攻击。但是对人来说很快就会被识破。
1. 页面跳转
  产生登录错的的时候就跳到另一个页面要求重新登录。比如126和校内网都是这样做的。局限性在于不能总是跳转页面，一般只在第一次错误的时候跳转，但是第一次之后又可以继续暴力探测了。
1. 适当的延时
  检查密码的时候适当的插入一些暂停，可以减缓攻击，但是可能对用户造成一定的影响。
1. 封锁多次登录的IP地址
  这种方法也是有缺点的，因为攻击者可以定时更换自己的IP。
1. 验证码
  验证码是阻止暴力攻击的好方法，但设计不好的验证码是可以绕过的，而且对于特定目标的手工探测来说验证码是没有作用的。

7. 会话标识未更新

描述

在用户进入登录页面，但还未登录时，就已经产生了一个Session，用户输入完信息并登录以后，Session的ID不会改变（也就是说没有建立新Session，原来的Session也没有被销毁），可能会窃取或操纵客户会话和Cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务。。

检测方法

1、打开网站登录页面。
2、登陆前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比，如果其值一样，则可判断其会话的cookies或者sessions未进行更新。
登录前：Cookie: JSESSIONID=0000QG_uEL3xnYACkk2dHbZtcJy:-1
登录后：Cookie: JSESSIONID=0000QG_uEL3xnYACkk2dHbZtcJy:-1

3、检测的时候要注意有的链接session会更新，有的链接不会更新的情况

修复方案

始终生成新的会话，供用户成功认证时登录登陆界面和登陆成功的界面一致时，修改后台逻辑，在验证登陆逻辑的时候，先强制让当前session过期，然后用新的session存储信息：登陆界面和登陆成功的界面不一致时在登陆界面后增加下面一段代码，强制让系统session过期。
request.getSession().invalidate();//清空session
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期；
注意：这段代码需要在页面的最后部分加上才可以，否则将报错

8. 未授权访问

描述

未授权访问漏洞，是在攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。

检测方法

1、通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开，
2、也可以通过web扫描工具进行扫描，爬虫得到相关地址链接，进行直接访问，如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞。

评价

这个检测手段很简单的，但是如何发现未授权的页面其实却还是有技巧的，通常情况，从js中提取的url，可能存在较多的未授权的情况，这里可以使用一个findsomething的浏览器插件来解决。

修复方案

在打开管理页面URL时，首先判断当前用户是否拥有该页面的权限，如果没有权限，就判定为“未授权访问”攻击，同时记录安全日志。建议使用成熟的权限框架处理权限问题，比如spring security/shiro。

9. 会话令牌不应写入URL

描述

会话令牌直接显示在URL中，容易被窃取。

检测方案

网站需要登录并且登录之后网站会给每个用户指定token值。
检测网站的URL中是否含有token，如URL中是否含有： article.html?id=&token=等。，如下图，之前拉勾网的漏洞，token值直接显示在URL中。
在这里插入图片描述

修复方案

修改源码，避免将令牌暴露在URL中。

10. 密码明文传输

描述

密码以明文形式传输，容易被捕获。

检测方法

使用burp能看到Http协议的明文内容，而不是经过加密，如果是Https协议可以绕过这个问题

修复方案

使用HTTPS等加密方式传输密码。如果使用http协议，可对传输内容进行加密。

11. 脆弱的加密方式

描述

网站登陆处的密码采用脆弱的加密方式，如加密方式容易被破解，或者加密方式存在于网站的页面源代码中。

检测方法

1.通过直观的观察进行判断，如tomcat的控制台，登录的账号密码是使用base64方式进行编码的
2.通过浏览网站的前端页面代码进行判断，有很多网站是使用前端加密的方式进行加密的

修复方案

使用强加密算法，并避免在前端代码中暴露加密方式。

12. 会话重放攻击

描述

会话令牌可以被重复使用，导致攻击者可能利用旧会话进行操作。

检测方法

1.首先使用账号密码进行正常的登录，登录后获取到cookie值，保存。
2.然后退出网站，使用刚才记录的cookie值登录网站，如果cookie值可以正常使用，用户成功登陆到网站，说明漏洞存在。
第一步：
在这里插入图片描述

第二步：
在这里插入图片描述

修复方案

1.设置cookie的有效时间，如果超过了限定的时间或者用户退出，应该将cookie设置为失效。
2.在关键环节，如订单生成时，应对token对应的信息内容、用户身份、等进行强校验。

13. 验证码漏洞

描述

验证码就是每次访问页面时随机生成的图片，内容一般是数字和字母（更BT点的有中文，现在已经升级到图片，动画等验证码），需要访问者把图中的数字字母填到表单中提交，这样就有效地防止了暴力破解。验证码也用于防止恶意灌水、广告帖等。在登陆的地方访问一个脚本文件，该文件生成含验证码的图片并将值写入到session里，提交的时候验证登陆的脚本就会判断提交的验证码是否与session里的一致。目前常常会出现验证码失效或者被绕过的可能，也成为了当前产生web漏洞的一个问题

检测方法

1、登陆页面是否存在验证码，不存在说明存在漏洞，完成检测。
2、验证码和用户名、密码是否一次性、同时提交给服务器验证，如果是分开提交、分开验证，则存在漏洞。
3、在服务器端，是否只有在验证码检验通过后才进行用户名和密码的检验，如果不是说明存在漏洞。（检测方法：输入错误的用户名或密码、错误的验证码。观察返回信息，是否只提示验证码错误，也就是说当验证码错误时，禁止再判断用户名和密码。）
4、验证码是否为图片形式且在一张图片中，不为图片形式或不在一张图片中，说明存在漏洞，完成检测。
5、生成的验证码是否可以通过html源代码或者在http头部查看到，如果可以说明存在漏洞，完成检测。
6、生成验证码的模块是否根据提供的参数生成验证码，如果是说明存在漏洞，完成检测。
7、请求10次观察验证码是否随机生成，如果存在一定的规律（例如5次后出现同一验证码）说明存在漏洞，完成检测。
8、观察验证码图片中背景是否存在无规律的点或线条，如果背景为纯色（例如只有白色）说明存在漏洞，完成检测。
9、验证码在认证一次后是否立即失效。
10、尝试下万能验证码 0000，8888等。

13.1 短信验证码总结

短信轰炸
1.在一个限制时间的情况下对一个手机号，发送的短信验证码条数超过发送预期，这种漏洞我们都称为短信轰炸
2.在一个限制时间的情况下对N个手机号，发送短信，虽然每个手机只能收到一条短信，但是消耗了短信资源，这也叫短信轰炸
短信验证码可爆破
我们讲了 2 个发送短信验证码，都知道验证码通常 4 位数或者 6 位数的数字验证码。如果服务器没有限制提交的验证码的次数，那么我们可以爆破这个验证码。
短信验证码可编辑
短信验证码需要前端点击发送短信，从触发的请求包中可能看到短信的内容，这个时候如果拦截更改，则会导致短信内容改变，有成为短信钓鱼漏洞的可能性
短信验证码绕过

1.通常，开发在发送短信验证码的时候，没有对特殊字符进行过滤。比如在手机号是 15312341234。我们加上+86，变成+8615312341234，这样的话服务器就有可能判定为两个手机号了。
2.在 mobile=15312341234 的前面，加空格，86，086，0086，+86，0，00，/r,/n,?,#,!,…只要想法多就有可能绕过。或者添加多个值Mobile=18312341234,13612341234
3.在请求包中添加XFF头，有的时候服务器是按照IP地址进行判定你是否短时间可以重复发短信。
4.添加多个值比如在发送手机短信验证码的时候可以把一个参数赋上多个值。比如 Mobile=18312341234,13612341234&code=1234
5.添加多个参数比如 Mobile=18312341234&Mobile=13612341234
6.修改返回包比如在发送短信验证码的数据包，修改返回包的 Flase 为 Success
7.并发比如对短信验证码的数据包进行并发，有机会绕过限制
8.在抓取短信验证码的数据包后，在响应包可以看到短信验证码
9.提交别人的验证码，两个人他同时发送验证码，使用另外一个人的验证码登录自己的账户
10.一个手机号，点击 2 次发送短信验证码，验证码都是同一个。这样的情况下，可以试试爆破验证码，如果爆破次数无限制，还是存在验证码固定这样漏洞的
11.验证码不失效比如验证码是在修改密码处使用。在使用短信验证码进入修改密码后，验证码没有失效。当前用户还可以再次用这个短信验证码修改密码，或者收到两条短信验证码，时间顺序为，1 在前，2 在后。收到的 2 后，1 还是没有失效
12.使用固定验证码，比如6666,8888等测试验证码
13.在找回密码方面，填写完账号名，要给A发短信验证码，通过burp拦截包，给B发送短信验证码。这样的话，就能用B的验证码提交给A用，造成任意账号密码重置

13.2图形验证码总结

图形验证码长宽可控
简单测试方法，就是看到一个登录框，然后新建打开图片链接，在图片链接中就有机会看到两个参数值，一个是 width，一个是 length。这两个参数是计算图片验证码的长宽，如果长宽过高就会过度消耗的是服务器的 CPU 资源。会造成拒绝服务攻击

图形验证码可绕过
有时候开发，会写两套图形验证码流程，一套是在生产运行阶段必须使用正确验证码才能通过服务器校验。另外一套是在测试 SIT 环境下，把验证码设置为只要是 null 或者是空都可以登录验证码置为空，可以将验证码设置为常见的一些字符比如null ，zone,true等
图形验证码不失效
简单易懂，图形验证码没有对应的失效机制。导致图形验证码能被多次利用。图形验证码在使用后未失效，发送短信时抓包，发送到Repeter中进行重放，可以发送成功

图形验证码返回到前端
顾名思义，响应包返回图片验证码的值，实际测试过程遇到过几次了。

修复方案

修复方式如下：
1、系统在开发时注意验证识别后销毁session中的验证码。
2、限制用户提交的验证码不能为空
3、判断提交的验证码与服务器上存储的是否一致
4、无论是否一致，都将服务器上存储的验证码清空

14. 页面渲染逻辑错误

描述

由于系统优先渲染页面后再进行用户状态判断，导致攻击者可通过截留数据包直接访问导航页面，暴露生产服务器。

检测方法

1.从加载顺序可见是在进入导航页面后检测用户状态，如无用户token则跳转回登录页面
2.如暂停页面加载即可查看导航页面内容

评价

这个漏洞类型在实际测试的时候，几乎不重要，就有一次，我不知道这个网站干什么的，通过页面渲染逻辑漏洞知道了这个页面都有那些功能，当然了，没有权限点进去，也是无法测试的，不过还是要说一句，VUE的前端架构，就算没有页面渲染逻辑错误，也是可以看到所有功能页面的，所以这个漏洞说到底真的重要么，如果真的重要，那么VUE这种技术架构得直接扔进垃圾桶。