单点登陆cookie安全详解

 COOKIE在登陆服务中用来保存用户凭证，在登陆代理中用来保存SESSION。
      假设用户A是正常用户，通过登陆服务进行了登陆，用户凭证被COOKIE记录下来，假设这时黑客B截获了A的用户凭证，那么当B连接到登陆服务验证时，B可以把截获的用户凭证附加到COOKIE中，因为登陆服务通过COOKIE来判断登陆状态，所以登陆服务会认为B以前登陆过，并且告诉登陆代理B的用户凭证，这样B就欺骗了登陆服务而拥有了用户A的操作权限。
      首先应该避免用户凭证的COOKIE泄露，在用户端，因为内存COOKIE比文件COOKIE更难被截取，特别是经过特殊处理的浏览器，要截取内存COOKIE几乎不可能，而且当浏览器关闭时，内存COOKIE失效，所以应该使用内存COOKIE而非文件COOKIE，这也是很多使用文件COOKIE的论坛帐号经常被盗的原因。
      其次，为进一步减少风险，不应该在COOKIE中直接保存用户凭证，而是使用一个无意义的标识符如UUID来表示，而登陆服务可以通过这个UUID查找到真正的用户凭证，这个标志符随机生成，即使同一用户登陆，得到的UUID也不一样，所以不能重复使用，这样即使偶尔泄露一次，也不会造成长期影响。为了提高COOKIE的截取难度，可以设置一个有效时间，只有在有效期内的COOKIE是合法的，超过有效期的COOKIE将被忽略，使用超过有效期的用户依然需要重新输入验证信息。这样也带来一个不便的地方，就是用户如果两次业务逻辑之间的切换时间超过了COOKIE的有效期，那么用户还得重新输入验证信息，达不到单点登陆的效果，所以如何取舍，要根据业务逻辑而定。
其次因为http使用明文传输，通过网络侦听的方式很容易获取COOKIE，所以用户到登陆服务间的连接应该采用https。
      然后考察登陆代理中使用COOKIE来保存SESSION的情况，这是大多数Web应用服务器采用的方法。这种情况类似登陆服务使用COOKIE来保存用户凭证，典型的欺骗是黑客B截获了正常用户A的SESSION COOKIE，然后B访问业务逻辑时附带这个COOKIE，Web应用服务器会认为B就是A，于是A能得到的用户凭证，B也能得到，B就成了A的影子，与A具有相同的操作权限。所以关键问题还是如何避免SESSION COOKIE的泄露，因为这个COOKIE由Web应用服务器控制，所以除了在网络传输时使用https，基本上没有其他办法可以降低风险。除了使用COOKIE作为SESSION标记，很多Web应用服务器也支持隐式域的方式，就是Web应用服务器在页面自动创建一个隐藏的表单项作为SESSION标记，页面提交时该表单自动被提交，Web应用服务器通过这个表单项来确定用户SESSION。这个是更不安全的做法，因为很多很简单的方法就可以获取页面表单项的数据，比获取内存COOKIE容易很多。
 
消息传递安全性
      业务逻辑、登陆代理、登陆服务间存在消息传递，业务逻辑和登陆代理部署在一个Web应用服务器中，消息传递比较安全。登陆代理和登陆服务通常处在不同的Web应用服务器中，并且通常在地域上也不一致，登陆代理和登陆服务间的安全隐患除了消息泄露，还有相互信任的问题。
      首先是消息泄露，使用https可以避免消息泄露。
      其次是登陆代理和登陆服务间如何相互信任，这就需要安全证书。关于证书的更多信息参考http://en.wikipedia.org/wiki/Certificate_authority，也可以去google搜索。证书的原理是基于非对称加密和数字摘要，非对称加密由一对密钥(p, s)组成，使用p加密的数据只能使用s解密，使用s加密的数据只能使用p解密，著名的非对称加密算法是RSA，数字摘要通过一个不可逆运算可以把数据a变成数据b，b通常数据长度固定并且很小，而且不能用过b反运算得到a，常用的数字摘要算法有MD5和SHA1。
      制作证书时，首先将证书信息i使用数字摘要算法如SHA1进行运算得到s，s = SHA1(i)，然后把i和s使用非对称加密算法如RSA的s加密得到证书c，c = RSA(s, i+s)。获取证书信息刚好是一个逆过程，i+s = RSA(p, c)，然后把i和s分离，并且比较s和SHA1(i)是否一致，如果一致，则这个证书信息是可信赖的。
      证书通常由权威机构制作，这个机构妥善保管s，公布p，那么互不相识的A和B通信，A要核对B的身份，A要求B的证书，然后核对解密后的证书信息就可以了。
      同样登陆代理和登陆服务在传递信息时也要核对身份，否则黑客可以将登陆代理引导到假冒的登陆服务，或者传递给登陆代理预先设定的用户凭证，进行认证欺骗。使用证书后，登陆代理请求登陆服务进行登陆时，首先核对登陆服务的证书，登陆代理处理登陆服务返回的用户凭证时，也核对登陆服务的证书，双方信息传递在https中进行，所以存在消息篡改和泄漏，保证登陆服务是可信赖的。登陆服务的证书必须妥善保管，并且定期更换。
      也可以根据证书原理自定义处理过程，登陆代理和登陆服务各自掌握p和s，证书代理发送消息使用p加密，接收消息使用p解密，登陆服务接收消息使用s解密，发送消息使用s加密，消息附带SHA1数字摘要，这样登陆代理和登陆服务也可相互信任。这种方案下，可以不使用https，因为消息已经被加密。但是这样有一个漏洞，就是会被重播，比如黑客可以截获登陆服务发送给登陆代理的整个加密的消息，然后完整地发送给登陆代理，这样登陆代理不能识别究竟真伪而被欺骗。可以在消息里面附加随机数据来解决这个漏洞，登陆代理发送消息前，先随机产生一段数据，并附加到消息中，然后加密发送给登陆服务，登陆服务发送消息给登陆代理时也附带这个数据，登陆代理核对这个数据来确定有效性，每次登陆代理和登陆服务传输的数据都不一样，重播不再有效。