WEB安全第五课 HTTP协议 之七 HTTP认证

        按RFC2617原本的设想，HTTP认证方式是专为Web程序量身打造的身份验证机制，但现在却几近绝迹。其中的原因可能是HTTP认证的界面与浏览器程序自身的UI相关，导致界面布局很不灵活；也很难兼容其他更复杂的非基于密码的授权机制；也无法控制授权认证会缓存多长时间才失效，并且很难和其他域名共享授权。


        
        不管怎么说，这套基本的授权协议相当简单。最开始的时候，浏览器会先发送一个未被认证（Unauthenticated)的普通HTTP请求，这时服务器会返回一个“401 Unauthorized”(未授权）响应代码。而服务器返回的响应里，还会包含一个WWW-Authenticate的HTTP头域，其中包括本次请求的验证方式和标识此范围域的一个名为Realm的字符串(这串由任意字符组成的标识符代表着本次授权的范围），此外可能还会跟着其他一些与该方法有关的可选参数。
💅🚠🥩➡🦖‎        
        无论以哪种方式，客户端在获得用户输人的授权信息后，会在之前那次普通HTTP提交的基础上，再增加一个Authorization请求头，这个请求头里存放着经过编码的授权信息，然后重发一次请求。

        根据规范，出于对性能的考虑，如果后续访问的是同一服务器的相同目录时，在后续的请求里会一律自动加入Authorization请求头，而无需由服务器端再发一次WWW-Authenticate提问。另外在访问服务器的不同目录时，如果收到的RealmString值和授权方法与之前的都一样，也允许重用之前的WWW-Authenticate授权信息而无需重新输入。
        

👂⛪🍍☯🦠‏

        在实际应用中，这些建议并未完全被采纳：除了Safari和Chrome，其他大多数浏览器都忽略RealmString值，或对路径的匹配采用非常宽松的模式。但另一方面来说，所有的浏览器在确定缓存的授权信息的适用范围时，除比较目的端服务器信息外，还会比较使用的协议和端口，这种做法实际上对安全更有利些。
        
        在原始RFC文档里，规定了两种授权认证方法，分别为基本认证和摘要认证。基本认证差不多就是把密码用Base64编码后以纯文本方式发送。摘要认证的方式则需要计算一个单次有效的加密摘要值，以避免密码被明文查看和防止Authorization头域被重用。但不幸的是，现在常用的浏览器都同时支持这两种认证方式，而且在使用时不会特别严密地区分两者。

        因此，攻击者完全可以在初始请求之后，把服务器返回内容里的Digest(摘要）一词简单地偷换成Basic(基本），这样在用户输入认证信息并提交之后，就能获得一个明文的纯文本密码了。让人惊讶的是，RFC预见到了这种风险，并给出了一些有用但最终未被采纳的建议：
✌🦼🔪➡🦕‌        
        客户端应该考虑在界面明显的地方提示当前使用的是哪种验证策略；或者记着与该服务器之间最严格的验证策略是哪种，在采用较弱的策略之前，应该给与必要的警示。或者客户端干脆默认地，或针对某些特定站点，配置为摘要认证方式。
        
        除了这两种RFC规定的验证策略，某些浏览器还支持一些不太常见的方法，如微软的NTLM和Negotiate,以用于和Windows域身份认证无缝结合的授权。
        👨‍🎨‍👞🗡🙄🖕
        尽管HTTP认证在互联网上很少碰到，但它对某些网站应用还是会有很大影响。例如，在论坛的帖子里，黑客可以放一个使用外部链接的图片，放图片的服务器对某些HTTP请求发来一个“401 Unauthorized(未授权）”响应，此时正在浏览帖子的用户会非常意外地看到这个来路不明的密码提示框。在仔细看过浏览器里的地址没错之后，大部分人恐怕都会上当而输入自己在论坛上的帐号密码，这些信息立刻就会发到攻击者放图片的服务器上。好家伙！#385: