看到一篇关于web服务的文章
2008-10-04 15:02
465 查看
今天看到一篇关于web服务安全的文章,先把他copy过来,有空再看。原文如下,原文地址:http://blog.csdn.net/hulihui/archive/2008/10/01/3006882.aspx
众所周知,WebService访问API是公开的,知道其URL者均可以研究与调用。那么,在只允许注册用户的WebService应用中,如何确保API访问和通信的安全性呢?本文所指的访问与通信安全性包括:
访问安全性:当前访问者是注册合法用户
通信安全性:客户端与服务器之间的消息即使被第三方窃取也不能解密
本文安全的基本思路是:
注册用户登录时使用RSA加密
Web API调用参数使用DES加密(速度快)
Web API调用中包含一个身份票据Ticket
Web服务器保存当前Ticket的Session,包括:Ticket、DES加密矢量、注册用户基本信息
1.1 产生客户端机器票据Ticket
一般而言,可以由客户端机器根据自己的MAC、CPU序列号等唯一标识产生一个本机器的Ticket字符串票据,其目的是:唯一标识当前客户端,防止其它机器模仿本客户端行为。
1.2 请求服务器公钥RSAPublicKey
客户端携带票据Ticket向服务器请求RSA公钥RSAPublicKey。在服务器端,一般采取如下策略产生RSA加密钥匙:
Application_Start时产生一个1024或更长的RSA加密钥匙对。如果服务器需要长久运行,那么Application_Start产生的RSA可能被破解,替代方案是在当前Session_Start时产生RSA加密钥匙对
保存当前票据对应的客户帐号对象,即:Session[Ticket] = AccountObject,在确认身份后在填写AccountObject具体内容:帐号、RSA加密钥匙对、DES加密矢量
完成上述步骤后,服务器将RSAPublicKey传回给客户端。
1.3 加密登录口令及DES加密矢量
客户端获得RSAPulbicKey后,产生自己的DES加密矢量DESCipherVector(至少要8位及以上,该加密矢量用于以后的常规通信消息加密,因为其速度比RSA快)。接着,客户端使用RSAPublicKey加密登录帐号、口令及DESCipherVector,连同Ticket,发送到服务器并请求身份验证。登录API格式如下:
public void Login(string Ticket, string cipherLongID, string cipherPassword);
如果验证成功,服务器将当前帐号信息、RSA钥匙、DESCipherVector等保存到会话Session[Ticket]中。
身份确认后,在客户端调用的WebService API中,必须包括参数Ticket,其它参数则均使用DESCipherVector加密。服务器端返回的消息也同样处理。例如,提交一个修改email的函数定义为:
public void ModifyEmail(string Ticket, string cipherEmai);
2.2 客户端解密消息
客户端接收到服务器返回消息后,先做解密操作,如果成功则进入下步处理。否则抛出加密信息异常。
2.3 服务器端解密消息
服务器接收到客户提交的API请求后,首先验证Ticket的合法性,即查找Session中是否有该票据以验证客户身份。然后,解密调用参数。如果成功则进入下不操作,否则返回操作异常消息给客户端。
需要指出,如果第三方截获全部会话消息,并保留其Ticket,此时服务器端仍然认可这个第三方消息。但是,第三方不能浏览,也不能修改调用API的参数内容,此时解密参数时将抛出异常。
上面探讨了一个基于加密的WebService访问与通信安全方法,即使第三方获取消息,不能查看原始内容,也不能修改内容,保证了WebService API的安全性。
本方案还是存在一个明显的缺陷,即:如果直接修改调用参数内容,在客户端或服务器端解密时不抛出异常,如何处理?如何保证解密时一定抛出异常?这个待以后研究后回答。
众所周知,WebService访问API是公开的,知道其URL者均可以研究与调用。那么,在只允许注册用户的WebService应用中,如何确保API访问和通信的安全性呢?本文所指的访问与通信安全性包括:
访问安全性:当前访问者是注册合法用户
通信安全性:客户端与服务器之间的消息即使被第三方窃取也不能解密
本文安全的基本思路是:
注册用户登录时使用RSA加密
Web API调用参数使用DES加密(速度快)
Web API调用中包含一个身份票据Ticket
Web服务器保存当前Ticket的Session,包括:Ticket、DES加密矢量、注册用户基本信息
1 WebService身份验证
确保注册用户的访问安全,需要如下步骤:1)产生一个当前客户端机器票据(Ticket);2)请求服务器RSA公钥(RSAPublicKey);3)使用RSA加密登录口令及发布DES加密矢量(DESCipherVector)。1.1 产生客户端机器票据Ticket
一般而言,可以由客户端机器根据自己的MAC、CPU序列号等唯一标识产生一个本机器的Ticket字符串票据,其目的是:唯一标识当前客户端,防止其它机器模仿本客户端行为。
1.2 请求服务器公钥RSAPublicKey
客户端携带票据Ticket向服务器请求RSA公钥RSAPublicKey。在服务器端,一般采取如下策略产生RSA加密钥匙:
Application_Start时产生一个1024或更长的RSA加密钥匙对。如果服务器需要长久运行,那么Application_Start产生的RSA可能被破解,替代方案是在当前Session_Start时产生RSA加密钥匙对
保存当前票据对应的客户帐号对象,即:Session[Ticket] = AccountObject,在确认身份后在填写AccountObject具体内容:帐号、RSA加密钥匙对、DES加密矢量
完成上述步骤后,服务器将RSAPublicKey传回给客户端。
1.3 加密登录口令及DES加密矢量
客户端获得RSAPulbicKey后,产生自己的DES加密矢量DESCipherVector(至少要8位及以上,该加密矢量用于以后的常规通信消息加密,因为其速度比RSA快)。接着,客户端使用RSAPublicKey加密登录帐号、口令及DESCipherVector,连同Ticket,发送到服务器并请求身份验证。登录API格式如下:
public void Login(string Ticket, string cipherLongID, string cipherPassword);
如果验证成功,服务器将当前帐号信息、RSA钥匙、DESCipherVector等保存到会话Session[Ticket]中。
2 WebService通信安全性
2.1 加密WebService API参数身份确认后,在客户端调用的WebService API中,必须包括参数Ticket,其它参数则均使用DESCipherVector加密。服务器端返回的消息也同样处理。例如,提交一个修改email的函数定义为:
public void ModifyEmail(string Ticket, string cipherEmai);
2.2 客户端解密消息
客户端接收到服务器返回消息后,先做解密操作,如果成功则进入下步处理。否则抛出加密信息异常。
2.3 服务器端解密消息
服务器接收到客户提交的API请求后,首先验证Ticket的合法性,即查找Session中是否有该票据以验证客户身份。然后,解密调用参数。如果成功则进入下不操作,否则返回操作异常消息给客户端。
需要指出,如果第三方截获全部会话消息,并保留其Ticket,此时服务器端仍然认可这个第三方消息。但是,第三方不能浏览,也不能修改调用API的参数内容,此时解密参数时将抛出异常。
上面探讨了一个基于加密的WebService访问与通信安全方法,即使第三方获取消息,不能查看原始内容,也不能修改内容,保证了WebService API的安全性。
本方案还是存在一个明显的缺陷,即:如果直接修改调用参数内容,在客户端或服务器端解密时不抛出异常,如何处理?如何保证解密时一定抛出异常?这个待以后研究后回答。
相关文章推荐
- 看到了一篇关于堆和栈介绍很好的文章
- 关于编程恶习--看到的一篇文章,有点意思
- 今天看到了一篇关于为什么要进行Bug管理的文章。
- 学校BBS上看到一篇关于追女孩子的文章,相信谁看了都会有种恍然大悟的感觉。
- 一篇关于积木式WEB应用的文章
- 今天看到的关于深度学习的一篇文章,可以好好学习下
- 【Android】数据存储数据库SQLite(之前有看到的一篇关于SQLite文章,简单明了、覆盖较全面适合学习)
- 今天又看到了一篇关于程序运行时内存方面的文章,特地来分享一下。
- 【转载】以前ioi上看到的一篇关于如何成为一名程序员的文章
- 至今看到过的最高水平,最详细内容,最具含金量的一篇关于安全与加密方面的技术文章
- 今天看到一篇很精典的关于Makefile的文章
- 看到一篇关于网络的文章,颇有同感,拿来分享
- 从别人那里看到的一篇关于select模型开发的文章,不一定好用,但先留下。
- 偶尔看到的一篇关于黑客文章,拿出来分享下!
- 看到一篇关于设计的好文章
- 关于WEB服务的一遍转载的文章
- 看到的一篇讲js比较好的文章,关于function
- 关于图像快速缩放算法,目前看到的最好的最清晰的一篇文章
- 看到一篇关于搜索引擎查询机制的文章,比较感兴趣,收藏……
- 在百度看到的一篇关于程序员的文章,觉得挺好,转载一下