webservice的安全问题

大家都知道，Webservice中的安全策略的实施主要从以下三个方面考虑：
1.传输时安全。通常采用SSL/HTTPS 对连接加密，而不是传输数据。
2.数据安全。通常采用数据加密(XML Encryption) 数字签名(XML-DSIG)。
3.底层架构提供的安全策略，利用应用服务安全机制。


对于传输时的安全，比较容易地加入到Webservice应用。可以利用HTTPS协议，就可以获得连接过程中的安全。

a.我们目前这个项目没有计划采用https。当然我是很希望采用这种策略，因为系统的安全性越高越好啊，但是没采用我也没办法。


传输过程中数据的保护是对于消息本身的保护。你可以使用已有的XML安全扩展标准，实现数字签名的功能，从而保证你的消息是来自特定方并没有被修改过。XML文件的加密技术从大程度上加强了Webservice的安全，它能够定制数据传输到后，能否被接受者所查看，进一步完善了传输后的安全，业界也在不断的制定Webservice的安全标准，比如SAML 和WS-Security。

a.数据的加密。目前采用了对XML文件中部分数据加密的策略。原因很简单，http上不能传明文吧，而且实现起来也不是很困难。只要客户端和服务端约定好一种加解密的算法，加上适当的密钥就可以了。当然实现过程中，如果两端的语言和平台不同，例如客户端是.net，服务端是java，.net的某些算法的具体模式需要清楚才行，否则调试起来会有些小麻烦。


b.数字签名可以确保传递的数据没有被第三方恶意修改过。数字签名这块理论上了解一点，具体的实施没有做过，听前辈高人说，可以采用伪签名机制，没有深入学习。整体上的设想是，将来用户量上来了，可以购买正式的数字签名产品，来避免数据被篡改的危险。目前针对数据可能会被篡改的危险，采用了消息摘要的策略，因为它确实具备这种能力，也因为这种策略被广为采用。

c.想到的另一种危险,恶意的重复发送问题。如果恶意用户截获了正在传输的数据，反复不断的重复发送，这种情况该如何处理。这种情况对整个系统来说，危险系数太高了，会造成数据的混乱，业务处理的错误，后果非常之严重，所以必须要预防。目前的策略是，因为数据是要保存到DB中的，正好表中的时间字段和其他的几个字段可以组成数据的唯一标识，这样就很容易的预防了这种情况的发生，呵呵，还不错。


最后一层保护就是依靠底层架构的安全，这更多的来自于操作系统和某些中间件的保护。比如在J2EE中，主持Webservice的应用服务器。目前很多的J2EE应用服务器都支持Java Authentication and Authorization Service (JAAS)，是被加入到J2SE 1.4当中的。利用主持Webservice的服务器，实现一些安全机制这是很自然的做法。另一种利用底层架构的安全方法就是，做一个独立的负责安全的服务器，Webservice的使用者和创建者都需要与之取得安全信任。