4.2 Web验证机制存在的漏洞
4.2.1 用户名和密码可以进行预测
用户名和密码都能够预测了，理所当然的，这里的漏洞就很大了。
（1）可预测的用户名。一些应用程序根据某种顺序自动生成账户名，当然，现在邮箱、手机、QQ号码成为用户名的可能性越来越高，攻击者们也越来越省事了；一些应用程序在大批量创建用户之后，并自动指定初始密码，然后通过某种方式（邮件、短信）将密码分配给用户。
（2）可预测的初始化密码。让攻击者能够预测其他应用程序用户的密码，基于内网的企业应用程序经常存在这种漏洞。如果所有用户都收到相同的密码，或者根据用户名和职务、ID、手机号码等创建的密码，这种密码非常容易被攻破。比这个更加糟糕的是，很多人有了初始密码之后，几乎不做修改，就一直使用；如果初始密码过于复杂，很多人会从一个极端走向另外一个极端，使用尽可能简易的密码。
4.2.2 重置密码和忘记密码漏洞
1．重置密码功能漏洞
一般的密码重置的设计都是分为以下四步。
第一步：输入账户名。
第二步：验证身份。
第三步：重置密码。
第四步：完成。
通常漏洞是会存在于步骤二或者步骤三中。下面来看看常见的一些重置密码漏洞的方式及漏洞产生的原因。
（1）手机验证码爆破从而重置密码。
这种设计一般是在找回密码时会给指定的手机号发送一个用于验证身份的验证码，然后只要用户输入正确的验证码，就可以进行密码重置了。
这种设计产生重置密码漏洞的情况，一般是由于验证设计过于简单，而且对校验码的校验使用次数没有进行限制，导致正确的验证码可以被枚举爆破，从而重置密码。此方法也是最常见的重置密码的方式，因为大多数厂商最开始的设置都是采取的4～6位纯数字验证码的验证方式，而且是没有防止爆破的设计。
漏洞展示
1 找回密码，选择手机找回，如图4-10所示，点击获取验证码后，验证码位置随便写4个数字，密码写成自己想要改的密码。
图4-10 找回密码设置
2 用burpsuite抓包，然后选择4位纯数字对验证码位置的爆破。4位纯数字，1万种情况，普通配置的计算机和网速2分钟就可以跑出来。如图4-11所示，跑出来正确的验证码，就已经成功重置用户密码了。
图4-11 跑出来正确的验证码
（2）邮箱验证码爆破从而重置密码。
这种设计一般是在找回密码时会给指定邮箱发送一个用于校验的URL链接，链接中一般会有一个参数就是用于验证身份的验证码，然后用户点击指定url就可以进入重置密码的页面从而去重置密码了。
这种设计产生重置密码漏洞的情况，也是由于重置密码链接中的验证码参数设计过于简单，可以被爆破，从而可以重置密码。
（3）偷梁换柱——给指定邮箱发送URL重置密码链接。
这种设计一般是在找回密码时会给指定邮箱发送一个用于校验的URL链接，链接中一般肯定会存在两个比较重要的参数，一个是用户名（或者手机号、QQ邮箱之类的能代表用户身份的参数），另一个就是一个加密的字符串（通过服务器端的某种算法生成的用来验证用户身份的参数）。然后用户在重置密码时，单击邮箱中的重置密码链接，就可以重置账号密码了。
这种设计产生重置密码漏洞的情况，一般是由于重置密码链接中的表示用户名的参数和用于校验的加密字符串参数没有进行一一对应，导致可以被黑客偷梁换柱，从而重置密码。
也就是说，那个验证身份的加密字符串是万能的。例如，生成的重置密码URL为：http://www. xx.com/xx.php? username=admin1&code=qwertyyu，由于这里的参数code在服务器端验证时，只要其自身的算法满足服务器端的验证就直接通过了，不会去验证这个code是不是和aasdsdff账户对应的。从而，黑客可以直接利用URL:http://www.xx.com/xx.php? username=admin2&code=qwertyyu重置账号admin2的密码。
（4）偷梁换柱——疏忽验证用户身份。
这种设计一般是在最后一步设置新密码时，程序员往往会疏忽验证用户身份，从而被偷梁换柱，重置密码。这种一般是由于前面步骤二中已经验证了身份，然后步骤三重置密码时没有对用户身份进行持续性的验证导致的。
漏洞展示
1 注册账号test，点击忘记密码，收到一封重置密码的邮件。
http://ovs.ifl ytek.com/public/change_password? &md1= wffITuct8rJhZ63vwwCRcusSIrrNRho
2 访问重置密码，如图4-12所示。
图4-12 重置密码
3 抓包修改账号为admin，如图4-13所示。
图4-13 修改账号
4 最后账号admin成功登录，如图4-14所示。
图4-14 用admin成功登录
（5）程序员泄露。
有时虽然加密字符串的算法很复杂，但是在重置密码的过程中，如果程序员自己不小心将其泄露了，那也可以被重置密码。这种属于程序员自己没有将开发调试时的一些数据在正式上线前去掉导致的。
（6）加密算法过于简单而被破解。
有时利用邮箱的URL重置密码，虽然不存在爆破的情况，但是由于加密算法过于简单而被破解，导致密码重置。这种一般都是一些简单的加密算法，将一些关键参数如用户名、邮箱、手机号、验证字符、时间戳等，进行一定的规则的组合，然后进行md5、base64加密。
（7）没有对关键的身份验证的参数进行追踪。
在重置密码的4个步骤中，有时当你输入账户名之后，直接去修改URL或者前端代码去进行重置密码，从而也能成功地绕过身份验证去重置密码。这种一般是由于没有对关键的身份验证的参数进行追踪导致的。
（8）没有验证手机号或者邮箱身份。
有时修改密码会给邮箱或者手机发送一个新密码，那么抓包将手机号或者邮箱改成我们自己的会怎么样呢？这种一般是由于没有验证手机号或者邮箱的对应身份导致的。
（9）利用CSRF破解。
有时CSRF利用好的话，也可以重置用户甚至是管理员的密码。这种一般是由于登录账号后重置密码或者绑定邮箱、手机号时没有token也没有验证refer导致的。
（10）利用XSS漏洞破解。
有时XSS漏洞也可以重置密码，当然这种也是因为本身重置密码中就有其他的设计缺陷。这种一般是用XSS劫持了账户后，由于某些奇怪的设计造成的。
2．忘记密码功能漏洞
忘记密码之后怎么办？大多数人会依赖网站的“密码找回”功能找回密码。但据官方公布的资料显示，密码找回功能或存在漏洞，导致用户账号泄密，甚至出现被盗的威胁。
“某些大型支付网站，通过密码找回功能的漏洞，一旦获取方法，只需5分钟就可以侵入客户账号”。来自tools网站的著名“白帽子”（维护网络安全的专业人士）Tang3曾经说到，他曾与团队一同发现并修补过类似的安全漏洞。通过这类漏洞，黑客能够盗取任意账号的密码，出现用户隐私泄露、好友关系诈骗，甚至财产直接受损的严重后果。
其主要原因是网站开发人员的安全意识不足，“密码找回”功能存在设计缺陷。例如，密码找回的凭证太弱，就会容易被黑客暴力破解；又或者有的网站直接将密保问题的答案写在网页源代码中，黑客只需通过填写他人注册邮箱，进行密码找回的操作，查看网页源代码就能得到密保问题答案，从而达到篡改他人账号密码的目的。
4.2.3 对验证登录的暴力破解攻击
暴力破解攻击是指攻击者通过系统地组合所有可能性（如登录时用到的账户名、密码），尝试所有的可能性破解用户的账户名、密码等敏感信息。攻击者会经常使用自动化脚本组合出正确的用户名和密码。
对防御者而言，给攻击者留的时间越长，其组合出正确的用户名和密码的可能性就越大。这就是为什么时间在检测暴力破解攻击时是如此重要的原因了。
暴力破解攻击是通过巨大的尝试次数获得一定成功率的。因此在Web应用程序日志上，你会经常发现有很多的登录失败条目，而且这些条目的IP地址通常还是同个IP地址。有时你又会发现不同的IP地址会使用同一个账户、不同的密码进行登录。
大量的暴力破解请求会导致服务器日志中出现大量异常记录，从中你会发现一些奇怪的进站前链接，如http://user:password@website.com/login.html。
有时，攻击者会用不同的用户名和密码频繁地进行登录尝试，这就给主机入侵检测系统或者记录关联系统一个检测到他们入侵的好机会。当然这里会有一些误报，需要我们排除掉。例如，同一个IP地址用同一个密码重复登录同一个账户，这种情况可能只是一个还未更新密码或者未获得正确认证的Web/移动应用程序而已，应排除掉这种干扰因素。
4.2.4 对用户密码强度不进行控制
网络安全事件日益频发，人们对密码的保护意识自然开始增强，媒体网站也纷纷发文告诫用户该如何设置安全的密码。密码中不要包含常用的词汇，不要以生日、邮箱、用户名、手机号等作为密码。
设置密码的方式已经被许多普通用户熟知，那么在设置自己密码时，中国用户的安全意识是否已经足够了呢？本节仅以2014年底的某购票网站因撞库事件泄露的数据作为我们的数据源，来分析一下目前中国用户的密码设置习惯。
先来看一下该次泄露数据的总体情况。在本次事件中，共有131389名用户的信息遭到泄露，其中主要以80后和90后为主，80后占比最高，为65%，是90后的一倍多，如图4-15所示。从目前来看，80后仍然是泄露事件的主力军。
图4-15 数据泄露分布图
设置密码之大忌
（1）密码中包含常用词汇。
从网络曝光的13万条泄露数据来看，仍有不少人在设置自己的密码时使用了123456、1314、520、521等常用词汇，其中密码中包含520的用户有4500人之多，如图4-16所示。
图4-16 弱密码分布图
（2）用生日做密码。
在本次泄露数据中，依然有2326人仅仅使用自己的生日6位数字作为密码！而那些在密码中包含生日数字的用户更是多不胜举。在这些犯了密码设置大忌的人中，尤以80后为主，占比达到83.8%，远超过其他年龄段的群体，如图4-17所示。看来用生日做密码是80后一个普遍存在的坏习惯。
图4-17 用生日做密码的年龄分布
（3）使用用户名、邮箱做密码。
泄露数据又给了我们一次“惊喜”，竟然有1700多人使用自己的注册用户名作为自己的密码，而使用注册邮箱作为密码的用户更为严重，有2396人之多。有趣的是，在泄露的人群中，90后的绝对占比（绝对占比即不同年龄段使用邮箱、用户名的占比与不同年龄段用户总数占比的比值）远大于其他年龄群体，如图4-18所示。看来80后和90后在密码设置上的习惯都是不一样的。
图4-18 非主流密码分布图
（4）用手机号做密码。
本次泄露事件中有81名用户使用了手机号做密码。其中，60后的绝对占比最高，并且随着年龄的降低，这一使用习惯绝对占比逐渐降低，如图4-19所示。
图4-19 手机密码分布图
年龄大的用户要记的东西多，要使用一个好记的作为密码才便于记忆，也是情有可原，毕竟自己的手机号还是记得最准确的，不容易搞混，但是这样做很容易给黑客暴力破解密码可乘之机。
另外，我们发现，该网站有一半以上的用户还在使用纯数字或纯英文这种单一的密码设置形式，使用组合密码的用户只占了46%。在如此高敏感高风险的网站中，居然有这么多用户的密码设置这么简单。在这之中，尤其以80后使用组合密码的为最少，只占了42%，而90后使用组合密码的超过了一半，为53.38%。看来90后在密码安全意识上是要略强过80后的。
4.2.5 对网络安全证书进行攻击
所谓的网站安全证书是通过在客户端浏览器和Web服务器之间建立一条SSL安全通道，保证了双方传递信息的安全性，而且用户可以通过服务器证书验证他所访问的网站是否真实可靠。
信息发送者先对原始数据进行杂凑运算得到消息摘要，再使用自己的签名私钥对消息摘要进行加密运算。服务器/网站安全证书的基本过程则是信息接收者对收到的原始数据采用相同的杂凑运算得到消息摘要，将两者进行对比，以校验原始数据是否被篡改。通过服务器/网站安全证书技术可以实现对数据完整性以及传送数据行为不可否认性的保护。
网络安全证书传输步骤如下。
（1）签名发送方（甲）对需要发送的明文使用杂凑算法，计算摘要。
（2）甲使用其签名私钥对摘要进行加密，得到密文。
（3）甲将密文、明文和签名证书发送给签名验证方（乙）。
（4）乙方验证签名证书的有效性，并一方面将甲发送的密文通过甲的签名证书解密得到摘要，另一方面将明文相同的采用杂凑算法计算出摘要。
（5）乙对比两个摘要，如果相同，服务器证书则可以确认明文在传输过程中没有被更改，并且信息是由证书所申明身份的实体发送的。
那么网络安全证书又存在哪些漏洞，使得Web验证机制安全受到威胁呢？
（1）证书有效期篡改。
以微信的COM_TENC.RSA证书为例，直接修改证书有效期（仅仅改动COM_TENC.RSA文件）：
Certifi cate:
……
Validity
Not Before: Jan 19 14:39:322015 GMT
Not After : Jan 11 14:39:322015 GMT
……
很明显，证书有效期错误，结束时间比开始时间还早，但是修改后的APK依然可以正常安装、运行，因为COM_TENC.RSA文件里的公钥（证书的一部分）和．SF文件都没有修改，可以通过Android证书验证机制。
联想开来，某个已过期的证书依然可以使用，假如某个拥有高权限的证书已经过期，危害会很大。例如，Adobe颁发过某个证书C（使用Adobe公钥签名该证书），然后证书C过期了，但是由于用Adobe的公钥验证该证书仍然可以通过（修复过的证书链认证可以通过，除非Adobe吊销它自己的证书），而Android并没有验证证书有效性，所以用证书C签过名的APK依然拥有Adobe的高权限。
（2）证书拥有者主体篡改。
以微信的COM_TENC.RSA证书为例，直接修改证书拥有者名字（仅仅改动COM_TENC. RSA文件）：
Certificate:
……
Issuer: C=86, ST=Guangdong, L=Shenzhen, O=abcdefg Technology
（Shenzhen）Company Limited, OU=abcdefg Guangzhou Research and
Development Center, CN=abcdefg
Validity
Not Before: Jan 19 14:39:322015 GMT
Not After : Jan 11 14:39:322015 GMT
Subject: C=86, ST=Guangdong, L=Shenzhen, O=abcdefg Technology
（Shenzhen）Company Limited, OU=abcdefg Guangzhou Research and
Development Center, CN=abcdefg
……
将开发者信息修改为了abcdefg，但是修改后的APK依然可以正常安装、运行，因为COM_TENC.RSA文件里的公钥（证书的一部分）和．SF文件都没有修改，可以通过Android证书验证机制。
联想开来，开发者主体信息很容易修改，造成知识版权问题。例如，可以把Google开发的APK的开发者证书信息修改成我自己的名字，扩大影响力；或者，把自己开发的恶意APK冠上Google的名字。
（3）证书吊销CRL。
Android证书机制并没有引入CRL吊销机制，已经吊销但拥有合法签名的证书依然可以使用，和第一项证书过期类似（证书过期也是吊销的一种方法）。
但是，证书吊销还有另外一个应用，当发现某个证书的私钥有泄露或是被破解时，业界常用的手法是吊销该证书，加入CRL列表。例如，2012年发生的Yahoo Axis私钥泄露事件。在Android系统里，并没有采用证书吊销机制，设想场景：Adobe颁发过某个证书D（使用Adobe公钥签名该证书），然后证书D在使用过程中发生了私钥泄露，那么此时只有吊销Adobe自己的根证书才能真正使证书D失效，成本大而且会影响其他Adobe签过名的证书。