本文通过 Web 登录的例子探讨安全问题，研究人员在不同的STARTTLS实现中发现了40个未修复的安全漏洞，登录不仅仅是简单地表达提交和记录写入，约32万邮件服务器受到命令注入攻击的影响。攻击者利用这些安全漏洞可以执行中间人攻击，其安全问题才是重中之重。
1. 一个简单的HTML例子看看用户信息安全
例如我的账号是user1，伪造邮件客户端内容和窃取相关凭证信息。漏洞影响多个主流的邮箱客户端，密码是123456，包括Apple Mail、Gmail、Mozilla Thunderbird、Claws Mail、Mutt、Evolution、Exim、Mail.ru、Samsung Email、Yandex和KMail邮箱客户端。攻击过程需要恶意方具有修改邮箱客户端和邮箱服务器之间的连接，那么我在提交登录的时候会给后台发送的HTTP请求如下（Chrome或者FireFox者工具捕获，并具有邮件服务器上的账号的登录凭证。邮箱客户端在提交新邮件或访问现有邮件之前，需开启Preserve log）：
可以发现即便password字段是黑点，必须用用户名和密码进行认证。对于这些连接，但是本机仍以明文的形式截获请求。
对称加密:采用对称密码编码技术，通过STARTTLS到TLS的过渡必须严格执行，它的特点是文件加密和使用相同的密钥加密。
非对称加密:需要两个密钥，因为安全降级会泄露用户名和密码，公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，攻击者就可以具有邮箱账号的完全访问权限。在另一个场景中，如果用公开密钥对数据进行加密，攻击者还可以伪造邮件内容。在TLS握手之前，只有用对应的私有密钥才能；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能。
123456-->456123
再进行反转：
456123-->321654
1.HTTPS可以保证传输过程中的信息不被别人截获，但是细细思考下，HTTPS是应用层协议，下层采用SSL保证信息安全，但是在客户端和服务端，密文同样是可以被截获的；
2.HTTPS报文在传输过程中，如果客户端被恶意引导安装“中间人”的WEB信任证书，那么HTTPS中的“中间人攻击”一样会将明文密码泄露给别人。
1.保证了用户数据库内的密码信息安全；
2.传输过程中无论如何都不会使得用户的密文被破解出原密码；
3.简单高效，执行以及编码难度都不，各种语言都提供MD5支持，快。
5. 那太好了！这样可以下HTTPS的钱了，真是这样吗？
6. 太不容易了！可是还别高兴的太早，当心数据被篡改
密码也加密了，黑客看不到明文了。加上Token了，登陆过程也没法再被截获重放了。可是想想这种情况，你在进行某宝上的网络支付，需要账号，密码，金额，token这四个字段进行操作，然后支付的时候你付了1块钱买了一袋包邮的小浣熊干脆面，某宝结算结束后，你发现你的账户余额被扣了1万元。这又是怎么回事呢？
因为即便黑客不登录，不操作，一样要搞破坏：当请求路由到黑客这边的时候，截获数据包，然后也不需要登录，反正账号密码都是对的，token也是对的，那么把数据包的字段改改，搞破坏就可以了，于是把money改成了1万，再传给服务器，作为受害者就莫名其妙踩了这个坑。可这该怎么解决呢？其实原理类似于HTTPS里的数字签名机制，首先科普下什么是数字摘要以及数字签名：
6.1 什么是“数字摘要”
我们在下载文件的时候经常会看到有的下载站点也提供下载文件的“数字摘要“，供下载者验证下载后的文件是否完整，或者说是否和服务器上的文件”一模一样“。其实，数字摘要就是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的内容信息其摘要必定一致。
因此，“数字摘要“叫”数字指纹“可能会更贴切一些。“数字摘要“是HTTPS能确保数据完整性和防篡改的根本原因。
6.2 数字签名--水到渠成的技术
假如发送方想把一份报文发送给接收方，在发送报文前，发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己的私人密钥对这个摘要进行加密，这个加密后的摘要将作为报文的”签名“和报文一起发送给接收方，接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要，接着再用发送方的公用密钥来对报文附加的数字签名进行，如果这两个摘要相同、那么接收方就能确认报文是从发送方发送且没有被遗漏和修改过！这就是结合“非对称密钥加”和“数字摘要“技术所能做的事情，这也就是人们所说的“数字签名”技术。在这个过程中，对传送数据生成摘要并使用私钥进行加密地过程就是生成”数字签名“的过程，经过加密的数字摘要，就是”数字签名“。
因此，我们可以在WEB端对之前案例中提到的username+MD5(password)+token通过签名，得到一个字段checkCode，并将checkCode发送给服务器，服务器根据用户发送的checkCode以及自身对原始数据签名进行运算比对，从而确认数据是否中途被篡改，以保持数据的完整性。
7. 总结
看似非常简单的WEB登录，其实里面也存在着非常多的安全隐患。这些安全完善的过程是在一个实际WEB项目中遇到的，上面的分析演化是在应对项目安全的检查中所提出的解决方案，多少会有很多不足的地方，希望一起交流探讨，共同进步！
补充1：JS加密函数存在被破解
感谢园友mysgk指出完整性检验中关于JS加密函数存在被破解的问题：
问题描述：
如果黑客通过阅读前端js源码,发现加密算法,是否意味他可以构造可以
被服务端的checkCode 来欺骗服务端呢 ?
我想了下，应该也是很多网站也在采取的策略：
摘要或加密JS算法不直接以静态文件的形式存在浏览器中，而是让WEB端去请求Server，服务器可以根据随机令牌token值决定返回一个相应随机的加密策略，以JS代码响应的方式返回，在异步请求响应中，加载JS摘要算法，这样客户端就可以动态加载数字摘要策略，保证无法仿造。
补充2：MD5存在隐患的问题
感谢园友EtherDream提出MD5已经过时，并且存在不安全的问题：
问题描述：
用MD5、SHA256 处理密码的过时了。。。现在 PBKDF、bcrypt 都在过时中。
1.本文重点侧重于方法思路的介绍，并不一定是要使用MD5函数，可以使用其他的方式。
2.MD5存在隐患，之前确实没有考虑太多，不过非常感谢园友指出，确实是这样的，主要思想是：
对于MD5的破解，实际上都属于【碰撞】。比如原文A通过MD5可以生成摘要M，我们并不需要把M还原成A，只需要找到原文B，生成同样的摘要M即可。
设MD5的哈希函数是MD5()，那么：
MD5(A) = M
MD5(B) = M
任意一个B即为破解结果。
B有可能等于A，也可能不等于A。
概意思也就是，截获了MD5加密后的密文，一样可以，找到一个不是原密码，但是加密后可以登陆成功的“伪原文”。
CSDN有一篇关于MD5风险的博客写的非常好，推荐一下：MD5算法如何被破解
从中可以看到一点，MD5函数确实能被反向“破解”，但是这个“破解”只是找到一个经过MD5运算后得到相同结果的原文，并非是用户的明文密码。但是这样会被破解登录的可能，确实是需要采用更完善的算法进行加密，再次感谢。
作者 | letcafe；来源 | 博客园
