很多人喜欢使用UsbKey产生数字签名的方式提交到服务器，最近我做的几个省厅的项目均如此，利用USBKey提供的ActiveX插件（更常见的是CAPICOM接口）通过USBKey厂商提供的WindowsCSP去调用UsbKey产生数字签名。
1， 用户在页面浏览文书
2， 用户对页面中的 Form 数据进行签名
3， 在本地产生数字签名
4， 数字签名提交到服务器
大家都认为以上的方案非常可靠，但这种方案存在一个极为严重的安全问题——诱导签名。
UsbKey的用户在大多数情况下无法确认自己看到的数据就是自己说签名的数据！因为，签名数据源是通过 JavaScript 去控制的，而不是用户。
我举一个简单的例子，如下面的页面 , 用户看到并以为自己产生签名的源数据是“逮捕张子强及其同伙” , 但其实不是！
|
codeBase="capicom.cab#version=2,0,0,3" classid="clsid:A996E
看上去进行签名的数据： name="data" value=" 逮捕张子强及其同伙 " > name="data_danger" value=" 释放张子强及其同伙 " > 数字签名结果：
value=" 签名数据 " onclick="theSignedData.value=pkiSignData(data_danger.value)">
|
上面的恶意例子能够运行于所有的 USBKey 的页面，用户签名的数据其实是“释放张子强及其同伙”。但由于数据被隐藏于页面之后，用户根本看不到，以至于产生恶意诱导签名的严重后果。
防止这种恶意诱导签名的办法通常是在服务器要确保所有的涉及数字签名的页面在传递到客户端 IE 浏览器前，都不会被篡改，但这种方法不能保证 100% 安全，因为在用户那一端，仍然存在一种非常高风险的诱导签名的可能，甚至是未经用户许可，直接调用用户 USBKey 去产生恶意数字签名，看下面的例子：
用户在浏览页面的时候，已经在页面背后无声无色地产生了数字签名，而且用户根本无法知道自己已经对“ 我今天去好又多偷了几包烟 ”这样的内容进行了签名！
下面的例子是真实的例子，能够运行于任何的 IE 浏览器，最后的结果是，页面通过用户的 UsbKey 产生了恶意签名并送到 www.danger.com 。
|
codeBase="capicom.cab#version=2,0,0,3" classid="clsid:A996E 你在浏览文书： value=" 逮捕张子强及其同伙 "> 你以为这是仅仅是一个用于浏览的页面！！
|
这就是我为什么不希望使用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代码到某个不显眼的页面，后果是非常严重的。