【IT168 资讯】以“互联网安全新思维”为主题的OWASP2011亚洲峰会在11月8日-9日成功举办。本届大会以“网络安全产品测评”、“OWASP应用安全技术”“业务安全发展新思路”“云安全”等多个角度展开深入的讨论。来自美国俄亥俄州辛辛那提市的OWASP领导者Marco做了《金融业Web应用的SSO构建设计与用例》演讲。

▲Marco：金融业Web应用的SSO构建设计与用例

　　Marco先为大家介绍了网络单点登录在金融领域的必要性和挑战性。接下来为大家介绍了几个单点登录的安全设计模式和应注意的安全和风险因素，罗列一些安全架构经常用的准则，并举例说一下框图、数据流通图、功能流通图，SSO架构威胁模型，攻击树及正当使用和滥用用例，SSO架构安全设计的安全风险框架。

　　Marco谈到：“为什么做单点登录，金融界悠久的历史往往有各种各样不同的系统，有ATM取款机或者分行终端界面、帐单系统、付账系统、银行电传转帐有各种各样的系统。每一次谈到网银后端系统，我到现在还头疼，我在花旗目前还不知道幕后都是什么东西。不同的系统收集了不同的用户信息，不像社交网站QQ之类的，关于个人信息的对话之类的。金融系统有信用历史，个人地址电话，账号等等。不同的系统还提供了不同的功能，我们说起来金融范围，除了活期存款账号、信用卡账号、房贷，如果有些银行给出了一些奖励积分，奖励积分系统和人民币、美元等等可能都是在一起的。中国银行系统经常和证券交易系统联在一起的，这之间怎么保证信息统一，这也是挑战。”

　　从商业角度要求是什么?我们做IT底线是什么?一切为了企业的利润，达到企业商业界成功的需要。首先用户体验要友好，不能为了安全让用户必须拿一个临时的U盘，我知道中国工商银行给某些人的U盾，大家最好记住用户密码或者别的这方面的，能够简单的登录，所以用户体验友好是第一要求。第二要求是简单，比如说退休的工人，第一次用计算机，只是子女教的，打开计算机该这样点，我们是假定他们没有经过IT训练，界面要相对简单。不同的系统不能要记太过密码名，需要太多的确认来达到这个目的。有些社交网站，你个人的账号如果不安全，别人会盗用你的网站，你的网站就会失去很多用户，目的是要减少重复登录，功能安全是基础。

　　SSO应用举例：

　　用户可以从A网站登录使用关于产品C的功能B。

　　用户可以从X网站登录使用关于产品Z的功能Y。

　　对于同一金融机构，同时拥有产品C和产品Z的用户来说，用户应当能够从A网站登录使用功能B和功能Y。

　　X网站或许要临时存在以支持拥有产品Z的单一用户。

　　SSO的设计选择

　　在A网站重复开发功能Y，利用功能Y获取X网站的信息。

　　有利因素：为将来关闭X网站做好准备。

　　不利因素：需要在不同网站上重复实现相同功能，需要同时维护重复功能的规则和逻辑。

　　建立单点登录使用用户能从站点A使用站点X上的功能Y

　　有利因素：无需同时维护重复功能的规则和逻辑，可充分利用站点X上的所有功能。

　　不利因素：使站点A依赖于站点X。

　　增加了安全的复杂性：身份认证、授权、站间会话管理、界面。

　　这时候不是网站A的安全性加上网站B的安全性，不是1+1在这儿等于2这么简单了，很复杂的。比如身份认证、授权间会话管理、界面等等。这是单个网站安全管理上面所不存在的。

　　SSO—实现举例：

　　直接交换安全代码

　　用对称和公共密钥密码术加密SSO的应用数据传输

　　安全代码服务(STS)

　　建立中央安全代码服务为加盟网站提供希望SSO所需要的SAML代码。SAML代码基于SLM上面的协议，它越来越普及，成为工业界的标准的安全实现方式。单点登录还有其他的方式，实现中央身份认证系统和中央身份授权系统，中央交易系统，最常见的就是我强调这两种。

　　SSO—直接交换安全代码

　　有利因素：属于仅仅讨论两个站点的网络协议，用直接交换代码相对来说比较容易安装和调配，安全上面支持PKI和SAML足够，只要在实施过程中注意细节方面，授权方面就足够，无需依赖第三系统。

　　不利因素：非统一系统架构，每一个加盟网站点必须维护自己的密码密钥。

　　SSO—直接交换安全代码(数据流程图)，从这里可以看出来，网站A和网站B的服务器列在不同的域里面，如果客户做单点登录比如从网站A获取代码，网站A进行加密，利用密钥和数据存储，生成安全代码，送给客户端，客户端把请求送给网站X，网站X收到请求之后进行解密然后进行身份确认。小规模的单点登录集成是很便捷的方法。

　　安全代码服务方式

　　有利因素：

　　建立适用于内部网站及外部网站统一的安全方式。实施中央密码密钥管理方案，支持SAML和SOAP。

　　不利因素：引入SSO加盟网站STS服务的依赖性，数据交流需要走更多的网络站点。

　　从图上可以看出同样网站A和网站X多了一个STS，客户需要安全登录的时候，网站A首先要靠STS，这是代码传输到客户端，客户端通过SAML传到网站。(如图)，从这个框架可以看到交流就多了一个到STS上的，性能上面就多了一些损失。

　　设计和安全考虑

　　安全身份认证和授权

　　直接交换安全代码

　　安全代码服务(STS)

　　安全对话管理：一个结束，所有登录站点都结束：对话的发起、对话的结束、重启对话、保持对话。

　　安全界面包装：为统一界面视觉效果，iFrame：利用HTML的视框。前面提到了“用户友好界面”的问题，作为用户登录的系统，它的界面不应该让用户觉得我怎么突然到了非常奇怪，非常陌生的界面。即使是一个安全SSO，但是客户觉得是不是不安全，所以常用的是IFrame，利用了HTML的视框。

　　单点登录的潜在安全风险：

　　不安全的对话管理：

　　对话不同步：一个网站对话结束，另一个仍然保留。对话回访、捎带对话、劫持对话、对话缺乏保护，使用明码或被暂时存储/记录。

　　恶意数据植入：XSS、SQL注入，我们讲XSS，实际上你用iFarme的时候，本身相当于XSS，它是我们允许的，安全的，如果第三方攻击者想利用iFarme想盗用用户的密码或者用户名就有危险。

　　特权升级或绕过授权，绕过授权怎么不至于使用户到另一个网站，这也是要注意的问题。

　　SSO安全架构设计参照的设计原则：

　　1、建立足够强的授权机制

　　2、实行特权最小化

　　3、保护数据存储、传输和显示

　　4、实现信任最低化

　　5、跟踪和记录用户活动和安全事件

　　6、安全得体的处理错误

　　7、深入使用防卫措施

　　8、缺省使用安全措施

　　9、追求简单设计、坚持KISS原则

　　10、将安全落实到设计、开发和实施环节

　　11、将安全最为最弱环节

　　12、避免安全模糊

　　这是单点登录设计的准则，什么是身份认证，用户登录一个网站用密码和用户名是一种身份认证，是否就安全了?网银系统登录之后转钱，我们相信用户名密码，如果被别人拿到了怎么办?比如说有人偷窥了你的密码进去之后就很容易把你的钱转走，怎么进一步进行身份认证，是不是在转钱的时候再需要。

　　用户名密码名完了以后怎么样进行进一步身份认证，这里头牵扯到再问你进一步的密码问题，比如说用户事先设立一些安全问题或者一次使用的密址发送你的手机或者你的账号的特殊信息。不是越复杂越好，是多层的安全身份认证和授权。

　　常见的缺陷就跳过。

　　对话管理我们提了一下，就不进行深入讲解了。

　　这里是从这里把程序分成几层，客户层、DMZ、后台层等等。这是数据流程图，给大家看这两个图的意思，每一次信息从一个系统到另一个系统，你必须做验证和进行身份确认，保证信息的完整和整体性。

　　这是SAML单点登录顺序图，可以看到传输过程中的问题。

　　金融网络应用的风险模拟。另外有用工具就是攻击树，要假想攻击者的攻击目标是什么?会用哪些手段?根就是它的目的，每一个分支就是它利用的方式，逐步下去看看你的程序有哪些漏洞。

　　授权的正当应用和举例，对于单点登录进行一番分析以后，可以帮助测试者进行不同的案例测试保证应用中间不但进行正面的用户使用保证，另外滥用也进行防止。

　　SSO架构安全设计的风险框架，这个表列了假想风险来源，可以是恶意用户、公司职员等等他会用什么手段攻击你的单点登录系统。用户从一个站点退出登录的但是忘记从另一个SSO的站点退出登录。使用户成为网络钓鱼的受害者或欺骗用户下载恶意的软件，或是攻击者想应用程序发出恶意数据，攻击者目标是SSO设计、身份认证或对话管理功能的缺陷等等。

　　相关链接：

　　OWASP2011演讲PPT下载专辑http://topic.it168.com/factory/owasp_2011/index.html
　　OWASP2011专题报道http://safe.it168.com/topic/2011/11-7/OWASP2011/index.html