http://mdsec.net/auth/53/
http://mdsec.net/auth/59/
http://mdsec.net/auth/70/
http://mdsec.net/auth/81/
http: //mdsec.net/auth/167/
如果应用程序使用非加密的HTTP连接传输登录证书,处于网络适当位置的窃听者当然就能够拦截这些证书。根据用户的位置,窃听者可能位于:
用户的本地网络中;
用户的IT部门内;
用户的ISP内;
因特网骨干网上;
管理应用程序的IT部门内。
注解
上述任何一个位置可能由授权用户占用,也可能由通过其他方法攻破相关基础架构的外部攻击者占用。即使某一特定网络的中间媒介可信,最好还是使用安全的传输机制传送敏感数据。
即使是通过HTTPS登录,如果应用程序处理证书的方式并不安全,证书仍有可能被泄露给未授权方。
如果以查询字符串参数、而不是在POST请求主体中传送证书,许多地方都可能记录这些证书,例如用户的浏览器历史记录中、Web服务器日志内以及主机基础架构采用的任何反向代理中。如果攻击者成功攻破这些资源,就能够获取保存在这些地方的用户证书,从而提升其访问权限。
虽然大多数Web应用程序确实使用POST请求主体提交HTML登录表单,但令人奇怪的是,应用程序常常通过重定向到一个不同的URL来处理登录请求,而以查询字符串参数的形式提交证书。我们并不清楚应用程序开发者为何采用这种方法,但以连接一个URL的302重定向执行请求,比使用另一个通过JavaScript提交的HTML表单提出POST请求要容易得多。
Web应用程序有时将用户证书保存在cookie中,通常是为了执行设计不佳的登录、密码修改、“记住我”等机制。攻击者通过攻击用户cookie即可获取这些证书。如果cookie相对安全可靠,可通过访问客户端的本地文件系统获得它们。即使证书被加密,攻击者仍然不需要用户证书就可以通过重新传送cookie实施登录。第12章和第13章将描述攻击者如何通过各种方法获取其他用户的cookie。
许多应用程序对应用程序中未经验证的区域使用HTTP,而在登录时转而使用HTTPS。如果是这样,应在向浏览器加载登录页面时转换到HTTPS,使得用户能够在输入证书前核实页面是否真实可信。但是,一些应用程序通常使用HTTP加载登录页面,而在提交证书时才转换到HTTPS。这样做是不安全的,因为用户不能核实登录页面的真实性,因此无法保证安全提交证书。那么,处在适当位置的攻击者就可以拦截并修改登录页面,更改登录表单的目标URL以使用HTTP。等到精明的用户意识到证书已使用HTTP提交时,攻击者已成功获取这些证书。