Web应用安全测试-认证功能缺陷
存在空口令
漏洞描述：认证登录环节允许空口令
测试方法：
找到网站登录页面，尝试输入用用户名，密码为空进行登录。
风险分析：攻击者可利用该漏洞登录网站后台，操作敏感数据，甚至上传webshell，从而控制服务器。
风险等级：
【高危】：存在空口令
修复方案：判断输入密码是否为空，禁止空口令登录。
注意事项：暂无
认证绕过
漏洞描述：能够绕过应用认证，直接登录系统。
测试方法：绕过认证主要有几下几种途径：
- 网络嗅探。通过网络嗅探工具探测局域网中传输的明文用户名和密码。有些应用程序采用GET方式发送登录请求，可能导致GET的URL请求内容被缓存在代理服务器活着Web服务器端，导致用户名和密码泄漏。
- 默认或可猜测的用户账号。大多数开源软件或商业软件提供的基于网络配置和管理的接口，通常都会有一些默认的用户名和密码。例如，一般默认的用户名是：admin，administrator、root、system、guest等，而默认的秘密吗也根据硬件和软件的不同而不同，可尝试一下这些密码：password、admin、guest、12345等。
- 直接访问内部URL。使用Spider工具找到含有admin、manager、administrator、login等词语的路径，尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
- 修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了，通过修改这些参数，从而被认为是已经认证过的用户。例如：http://www.xxx.xom/userinfo.jsp?authenticated=no，通过修改authenticated参数为yes，http://www.xxx.xom/userinfo.jsp?authenticated=yes，然后就可以通过认证，直接访问内部页面。
- 可猜测的SessionID。利用规律，猜测到一个有效的SessionID，然后通过修改请求中的SessionID为一个预测到的有效的SessionID，从而冒充会话的真正拥有着，绕过认证环节。
- 注入问题。利用万能密码登录系统，绕过认证环节。
- CSRF。利用CSRF漏洞在用户不知情的情况下，利用用户的会话进行敏感操作，从而绕过认证。
风险分析：如果应用程序在认证上没有做好，可以导致恶意用户或者攻击者绕过认证，访问内部资源，这类漏洞通过防火墙和入侵检测系统很难预防。
风险等级：
【高】：能够登录进入应用系统，且可以进行相关操作
【中】：能够登录访问进入应用系统，但无法进行相关操作
修复方案：可从以下几个方面预防认证绕过：
- 对于每一个访问的URL都首先检查是否已经登录（不需要认证的URL除外，例如，帮助页面、免费下载页面等），如果没有登录，则跳转到登录页面。对于已经登录的用户，在退出的时候或者在会话很长时间处于idle状态的时候，需要保证原来的会话被正确的销毁并且不会再被重利用。
- 规定密码强度要求，防止密码被猜测到。
- 对于用户是否已经认证，禁止依赖客户端传过来的参数标识，而应将是否登录的标识保存在服务器端的会话中，当接收到该会话的请求时，从会话保存的状态判断是否登录。
- 对于SessionID一定要使用安全的随机数生成算法，使得SessionID不可预测。
- 对于暴力破解攻击，建议在尝试3次左右失败之后，使用图形验证码。
注意事项：暂无
Oauth认证缺陷
漏洞描述：OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。Oauth认证不完全，可越权登录他人账户。
测试方法：OAuth认证缺陷具体测试场景如下：
- 开始认证过程，从提供商那里得到回调，获取code，但暂不访问带有code的URL，如：http://www.xxx.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI
- 然后把它放在<img src=”URL”>或<iframe>标签下保存起来。
- 让用户(某一特定的用户或者target.com上随机的用户)发送HTTP请求到你的callback
URL。例如，通过钓鱼等手段诱骗用户访问example.com/somepage.html，其中包含<iframe src=URL>，且用户在发送HTTP请求时处于登录状态。 - 现在，按下“用facebook账号登录”即可以登录用户账户。
风险分析：攻击者结合OAuth认证缺陷和钓鱼攻击可定向的登录某个用户的账户。
风险等级：
【高危】：可导致用户资源任意访问或任意账户登录或用户密码获取。
修复方案：各应用除了验证access token之外，还必须辅助其他参数进行判断（比如自行加入其它认证参数进行双重认证）；另一种方法则是验证access token背后所属的应用app key的唯一性和对应性（无论是自行验证还是开放平台通过签名等形式帮助验证），确保该access token是该应用的。
注意事项：暂无
IP地址伪造
漏洞描述：通过伪造IP地址能够绕过应用IP地址限制，访问和执行系统相关功能。
测试方法：使用代理软件拦截请求包，修改HTTP头中的Host字段，伪造IP地址绕过限制。
风险分析：攻击者可利用该漏洞访问受限系统，造成应用系统数据泄漏。
风险等级：
【高危】：访问重要系统/执行重要功能
【中危】：访问非重要系统/执行非重要的功能
修复方案：
- 使用getServerName()代替getHeader(“Host”)；
- 在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法Host header，或者在Apache和Nginx里指定一个ServerName名单；同时，Apache开启UseCanonicalName选项。
注意事项：暂无
多点认证缺陷
漏洞描述：系统允许多点认证
测试方法：
- 在浏览器A中使用测试账号登录系统；
- 同时在浏览器B中使用同一个账号登录系统；
- 若在多个浏览器中均可登录同一各账号，说明存在多点认证缺陷。
风险分析：攻击者在获取到其他用户的账号密码后，可利用该缺陷在用户已登录且未知的情况下进行登录，操作用户账户。
风险等级：
【高危】：多点登录架构可被绕过
【中危】：核心系统允许多点登录
修复方案：建议在不影响业务的前提下，关键业务系统应禁止多点认证。当同一账号在其他地方登录时已登录的账号应退出会话，并提示用户账户在其他地区登录，可能存在账号被盗风险。
注意事项：暂无
会话固定
漏洞描述：在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说没有建立新session，原来的session也没有被销毁）。攻击者事先访问系统并建立一个会话，诱使受害者使用此会话登录系统，然后攻击者再使用该会话访问系统即可登录受害者的账户。会话固定攻击的原理及流程如下图所示：
- 攻击者Bob匿名访问www.buybook.com。
- 服务器与Bob建立了一个会话，比如sessionid为1234567。
- Bob构造了一个URL：http://www.buybook.com/login.jsp?sessionid=1234567，发给了受害者Alice。
- Alice直接打开此链接，输入自己的用户名和密码登录系统。
- 此时Bob再次访问http://www.buybook.com/viewprofile.jsp?sessionid=1234567，即可进入Alice的账户。
测试方法：
1、 打开网站登录页面。
2、 登录前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比，如果其值一样，则可判断其会话的cookies或者sessions未进行更新。
风险分析：攻击者可能会窃取或操纵客户会话和cookie，用于模仿合法用户，从而以该用户身份查看或变更用户记录以及执行事务。
风险等级：
【中危】：会话可由攻击者建立后发给受害者使用该会话登录系统，然后攻击者利用该会话即可登录受害者账户。
修复方案：在用户提供的认证信息（例如用户名和密码）、相应的权限级别发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话，JAVA示例代码如下：
| request.getSession().invalidate();//清空session Cookie cookie = request.getCookies()[0];//获取cookie cookie.setMaxAge(0);//让cookie过期 ； |
注意：这段代码需要在页面的最后部分加上才可以，否则将报错。
注意事项：暂无
