当前位置:   article > 正文

web应用安全测试之功能漏洞_通过手工在web系统登录页面,输入两个不同的用户名,以下哪个两个回显说明存在用户

通过手工在web系统登录页面,输入两个不同的用户名,以下哪个两个回显说明存在用户

信息猜解

邮件内容中请求链接可预测

漏洞描述

邮件中的重置密码等链接可预测,导致链接可以直接被猜解访问

测试方法:
  • . 先按照正常流程重置密码,接收重置密码邮件,分析重置链接的构造
  • 通常情况下链接中会使用token参数使得链接具有唯一性,判断该参数是否可预测。
  • 如用户名的md5值,用户名+时间戳的md5值等。
风险分析

攻击者通过猜测重置密码链接可重置他人账户的密码

风险等级:

【高危】:存在需要收件人点击确认的链接中,无安全随机数,或 token 简单可预测。

修复方案
重置密码链接中的token使用安全随机数
  • 1

数据猜解

账号枚举

漏洞描述

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

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

在这里插入图片描述
在这里插入图片描述

风险分析

攻击者根据Web应用程序返回的上述提示信息即可枚举系统中存在的登录用户名,然后针对枚举出来的登录用户名,对其密码进行暴力破解。

风险等级:

【低危】:可通过返回关键字对系统可用账号进行枚举。

修复方案
建议对网站登录页面的判断回显信息修改为一致:用户名或密码错误。
  • 1

账号密码共用

漏洞描述

不同的业务系统存在相同的用户名密码,或者不同用户名使用相同的初始密码

测试方法

使用同一个用户名密码登录不同业务系统,看是否均可成功登录。

风险分析

攻击者在得到一个业务系统的用户名密码后可尝试登录其他业务系统,造成其他业务系统信息泄漏。
或者使用初始密码遍历用户名,批量获取可登录系统的用户名密码。

风险等级:

【高危】:多台服务器的后台或其他服务口令相同。
【高危】:不同用户名使用相同初始密码,且第一次登陆未强制密码修改或强制修改机制可绕过继续使用初始密码。
【低危】:同样的账户名密码可以在多个系统上登录。

修复方案:
设置每个账号的初始密码均不同,且不可预测。
不同业务系统采用不同的账号密码体系。
  • 1
  • 2

认证信息泄漏

传输过程泄漏

漏洞描述

认证过程中传输未加密(用户名密码等敏感数据明文传输)。

测试方法:
  • 找到网站或者Web系统登录页面
  • 通过对网站登录页面的请求进行抓包,工具可用burp、wireshark、filder、等等,分析其数据包中相关password(密码)参数的值是否为明文
风险分析

攻击者通过在局域网中嗅探网络流量,获取明文传输的认证凭证
如用户名密码、SESSIONID等敏感信息。

风险等级:

【中危】:传输数据包含明文密码、链接、明文身份证、明文地址等其他敏感信息。
【中危】:GET方式明文传输用户名密码。
【中危】:Token或者用户身份标识,以GET方式显示在URL中。

修复方案
建议按照网站的密级要求,需要对密码传输过程中进行加密得使用加密的方式传输,如使用HTTPS,  但加密的方式增加成本,或许会影响用户体验。
如果不用 HTTPS,可以在网站前端用 Javascript 做密码加密,加密后再进行传输。
  • 1
  • 2

会话变量泄漏

漏洞描述

登录、验证等页面的隐藏域中存在密码信息

测试方法

查看网页源代码,寻找隐藏域中是否存在密码等信息

风险分析

攻击者通过在局域网中嗅探网络流量,获取明文传输的认证凭证,如用户名密码。

风险等级:

【高危】:隐藏域中存在密码等信息

修复方案

禁止在前端页面中保存密码等敏感信息

认证信息猜解

存在弱口令
漏洞描述

认证登录环节存在弱口令

测试方法:
  • 找到网站登录页面,尝试输入常见弱口令;
  • 根据网站所使用的第三方组件,寻找特定的弱口令或默认口令进行登录
风险分析

攻击者可利用互联网公开的常见弱口令尝试登录管理后台,对网站造成一定的影响。

风险等级:

【高危】:存在弱口令

修复方案
禁止使用弱口令,口令应满足一定的复杂度。
  • 1

存在暴力破解

漏洞描述
  • 暴力破解的基本思想是根据题目的部分条件确定答案的大致范围,并在此范围内对所有可能的情况逐一验证,直到全部情况验证完毕。
  • 若某个情况验证符合题目的全部条件,则为本问题的一个解;
  • 若全部情况验证后都不符合题目的全部条件,则本题无解。
  • 常常存在于网站的登录系统中,通过对已知的管理员用户名,进行对其登录口令的大量尝试。
测试方法:
  • 找到网站登录页面。
  • 利用burp对登录页面进行抓包,将其发送到Intruder,并设置其密码参数,如pwd=为变量,添加payload(字典),进行攻击,攻击过程中查看其返回的字节长度,来判断是否成功。
  • 攻击效果如图所示:
    在这里插入图片描述
一般情况下,暴力破解有三种形式:
1)	固定账号对密码暴力破解。
2)	在得知账号具有规律性,或者通过某种方式获取到大量账号的前提下,固定密码对账号暴力破解。
3)	使用网上流传的账号密码库进行撞库攻击。

  • 1
  • 2
  • 3
  • 4
  • 5
风险分析

攻击者一般会使用自动化脚本组合出常见的用户名和密码,
即字典,再结合软件burpsuite的intruder功能进行暴力破解。

风险等级:

【中】:存在暴力破解风险,但未暴破出密码。

修复方案

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

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

认证功能失效

存在空口令

漏洞描述

认证登录环节允许空口令

测试方法:

找到网站登录页面,尝试输入用用户名,密码为空进行登录

风险分析

攻击者可利用该漏洞登录网站后台,操作敏感数据,甚至上传webshell,从而控制服务器。

风险等级:

【高危】:存在空口令

修复方案
判断输入密码是否为空,禁止空口令登录。
  • 1

认证绕过

漏洞描述

能够绕过应用认证,直接登录系统。

测试方法

绕过认证主要有几下几种途径:

1.	网络嗅探。
     通过网络嗅探工具探测局域网中传输的明文用户名和密码。
    有些应用程序采用GET方式发送登录请求,可能导致GET的URL请求内容被缓存在代理服务器活着Web服务器端,导致用户名和密码泄漏。
2.	默认或可猜测的用户账号。
    大多数开源软件或商业软件提供的基于网络配置和管理的接口,通常都会有一些默认的用户名和密码。
    例如,一般默认的用户名是:admin,administrator、root、system、guest等,而默认的秘密吗也根据硬件和软件的不同而不同,可尝试一下这些密码:password、admin、guest、12345等。
3.	直接访问内部URL。
    使用Spider工具找到含有admin、manager、administrator、login等词语的路径,尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
4.	修改参数绕过认证。
     应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了,通过修改这些参数,从而被认为是已经认证过的用户。例如:http://www.xxx.xom/userinfo.jsp?authenticated=no,通过修改authenticated参数为yes,http://www.xxx.xom/userinfo.jsp?authenticated=yes,然后就可以通过认证,直接访问内部页面。
5.	可猜测的SessionID。
    利用规律,猜测到一个有效的SessionID,然后通过修改请求中的SessionID为一个预测到的有效的SessionID,从而冒充会话的真正拥有着,绕过认证环节。
6.	注入问题。
    利用万能密码登录系统,绕过认证环节。
7.	CSRF。
    利用CSRF漏洞在用户不知情的情况下,利用用户的会话进行敏感操作,从而绕过认证。

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
风险分析

如果应用程序在认证上没有做好,可以导致恶意用户或者攻击者绕过认证,访问内部资源,这类漏洞通过防火墙和入侵检测系统很难预防

风险等级:

【高】:能够登录进入应用系统,且可以进行相关操作
【中】:能够登录访问进入应用系统,但无法进行相关操作

修复方案

可从以下几个方面预防认证绕过:

1.	对于每一个访问的URL都首先检查是否已经登录(不需要认证的URL除外,例如,帮助页面、免费下载页面等),如果没有登录,则跳转到登录页面。对于已经登录的用户,在退出的时候或者在会话很长时间处于idle状态的时候,需要保证原来的会话被正确的销毁并且不会再被重利用。
2.	规定密码强度要求,防止密码被猜测到。
3.	对于用户是否已经认证,禁止依赖客户端传过来的参数标识,而应将是否登录的标识保存在服务器端的会话中,当接收到该会话的请求时,从会话保存的状态判断是否登录。
4.	对于SessionID一定要使用安全的随机数生成算法,使得SessionID不可预测。
5.	对于暴力破解攻击,建议在尝试3次左右失败之后,使用图形验证码。
  • 1
  • 2
  • 3
  • 4
  • 5

Oauth认证缺陷

漏洞描述

OAuth是一个在不提供用户名和密码的情况下,授权第三方应用访问Web资源的安全协议。
Oauth认证不完全,可越权登录他人账户

测试方法

OAuth认证缺陷具体测试场景如下:

  1. 开始认证过程,从提供商那里得到回调,获取code,但暂不访问带有code的URL,
 如:http://www.xxx.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI
  • 1
2.	然后把它放在<img src=”URL”><iframe>标签下保存起来。
3.	让用户(某一特定的用户或者target.com上随机的用户)发送HTTP请求到你的callback  URL。例如,通过钓鱼等手段诱骗用户访问example.com/somepage.html,其中包含<iframe src=URL>,且用户在发送HTTP请求时处于登录状态。
4.	现在,按下“用facebook账号登录”即可以登录用户账户。
  • 1
  • 2
  • 3
风险分析

攻击者结合OAuth认证缺陷和钓鱼攻击可定向的登录某个用户的账户

风险等级:

【高危】:可导致用户资源任意访问或任意账户登陆或用户密码获取。

修复方案
各应用除了验证access token之外,还必须辅助其他参数进行判断(比如自行加入其它认证参数进行双重认证);另一种方法则是验证access token背后所属的应用app key的唯一性和对应性(无论是自行验证还是开放平台通过签名等形式帮助验证),确保该access token是该应用的。
  • 1

2.6.4 IP地址伪造

漏洞描述

通过伪造IP地址能够绕过应用IP地址限制,访问和执行系统相关功能

测试方法

使用代理软件拦截请求包,修改HTTP头中的Host字段,伪造IP地址绕过限制

风险分析

攻击者可利用该漏洞访问受限系统,造成应用系统数据泄漏

风险等级:

【高危】:访问重要系统/执行重要功能
【中危】:访问非重要系统/执行非重要的功能

修复方案:
1.	使用getServerName()代替getHeader(“Host”);
2.	在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法Host header,或者在Apache和Nginx里指定一个ServerName名单;同时,Apache开启UseCanonicalName选项。
  • 1
  • 2

认证功能滥用

多点认证缺陷

漏洞描述

系统允许多点认证

测试方法:
  • 浏览器A中使用测试账号登录系统
  • 同时在浏览器B中使用同一个账号登录系统
  • 若在多个浏览器中均可登录同一各账号,说明存在多点认证缺陷
风险分析

攻击者在获取到其他用户的账号密码后,可利用该缺陷在用户已登录且未知的情况下进行登录,操作用户账户。

风险等级:

【高危】:多点登录架构可被绕过
【中危】:核心系统允许多点登录

修复方案
建议在不影响业务的前提下,关键业务系统应禁止多点认证。当同一账号在其他地方登录时已登录的账号应退出会话,并提示用户账户在其他地区登录,可能存在账号被盗风险。
  • 1

会话固定

漏洞描述
  • 在用户进入登录页面,但还未登录时,就已经产生了一个session,用户输入信息,登录以后,session的id不会改变,也就是说没有建立新session,原来的session也没有被销毁)。
  • 攻击者事先访问系统并建立一个会话,诱使受害者使用此会话登录系统,然后攻击者再使用该会话访问系统即可登录受害者的账户。

会话固定攻击的原理及流程如下图所示:

在这里插入图片描述

1)	攻击者Bob匿名访问www.buybook.com。
2)	服务器与Bob建立了一个会话,比如sessionid为1234567。
3)	Bob构造了一个URL:http://www.buybook.com/login.jsp?sessionid=1234567,发给了受害者Alice。
4)	Alice直接打开此链接,输入自己的用户名和密码登录系统。
5)	此时Bob再次访问http://www.buybook.com/viewprofile.jsp?sessionid=1234567,即可进入Alice的账户。
  • 1
  • 2
  • 3
  • 4
  • 5
测试方法:
  • 打开网站登录页面。
  • 登陆前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比,如果其值一样,则可判断其会话的cookies或者sessions未进行更新。
风险分析

攻击者可能会窃取或操纵客户会话和cookie,用于模仿合法用户,从而以该用户身份查看或变更用户记录以及执行事务。

风险等级:

【中危】:会话可由攻击者建立后发给受害者使用该会话登录系统,然后攻击者利用该会话即可登录受害者账户。

修复方案
在用户提供的认证信息(例如用户名和密码)、相应的权限级别发生变化时,服务器端应重新生成SessionID,并强制失效之前的会话,JAVA示例代码如下:
request.getSession().invalidate();//清空session 
Cookie cookie = request.getCookies()[0];//获取cookie 
cookie.setMaxAge(0);//让cookie过期 ;
注意:这段代码需要在页面的最后部分加上才可以,否则将报错。
  • 1
  • 2
  • 3
  • 4
  • 5

摘抄


于日暮黄昏中等待黎明,

于熊熊烈火中涅槃重生,

于芸芸众生里闪闪发光。


声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/花生_TL007/article/detail/649878
推荐阅读
相关标签
  

闽ICP备14008679号