问题描述
刚学webapi不久，很多问题都不怎么懂，觉得web的东西安全性是第一位，我想请教下各位有开发经验的大神，webapi暴露接口给mvc，webform，手机app调用的话，我用非对称加密的数字签名，提供公钥给提供调用的系统，并要求他们提供他们的公钥，每次传送数据时候，带上他们的用户名和对数据进行签名，这样就可以替代用户验证了吧，因为数字签名本来就有不可抵赖性，而且因为每次传送数据的时候都带上用户名，所以不用session或者cookie存放敏感信息，用数字签名验证完用户后再验证授权，这样单是使用数字签名就可以防止了大部分的攻击了吧，因为session或者cookie没有敏感信息，对于重放攻击话，因为数据库的资源都带有一个GUID，如果是add，检验GUID是否存在，如果存在就update，而update，del都是作用到同一条数据的相同修改无论对少次相同的修改都一样的结果，数字签名+不放敏感信息到session或者cookie+资源采用GUID，这样是不是可以避免了大部分的攻击，这样的设计是OK的吗？还有哪些攻击需要注意
解决方案
本帖最后由 cwm1985 于 2016-06-18 16:06:10 编辑
解决方案二：
自顶一下，想知道一下实际的方案，刚学不久啊
解决方案三：
1、这样调用系统可以伪造用户名2、每次都要验证签名过的数据，效率低下
解决方案四：
这个也差不多啦，比较安全的，可以了解下微信公众号那种方式，token需要跟服务器获取，而且是有效时间的
解决方案五：
你这种就是HMAC验证方式，但你这样太麻烦了，一般采用的都是MD5签名的方式，因为不需要解密，只需要按规则再进行一次签名对比就可以确认是否被伪造，性能消耗比你的方式小重放攻击一般来说，是加上时间戳来解决，如果你按照REST规范进行编码的话，时间戳可以解决get和del的重放问题，而put和post一般是更新数据库的，这时候时间戳只能解决一部分问题，其它部分就需要逻辑来保证了（比如put更新了数据，那后面同样的请求再来时，逻辑上就可以验证到数据已经变更过了，所以请求被拒绝）