这样设计WEB API接口安全吗？

Question

我要提供一个 HTTP 接口给客户端，因为是一个简单的需求，就是提交用户反馈，把userid，反馈内容等通过GET方式请求接口。

为了保证请求合法，有两种方式，一个是白名单，一个是构造签名。

这里采用了验证签名的方式，即参数按字典排序 + secret key 通过 sha1 加密构造签名，然后服务端收到参数也用同样的 secret key 加密，然后对比进行验证，这样做是否可行？

了解过 Oauth 2 ，签名，session + cookie方式，Basic 等鉴权和身份认证方式，但对于我这种需求，似乎这样简单的签名就可以满足安全要求了。

Answer 1

各厂商流行的做法是签名

Answer 2

这里采用了验证签名的方式，即参数按字典排序 + secret key 通过 sha1 加密构造签名，然后服务端收到参数也用同样的 secret key 加密，然后对比进行验证，这样做是否可行？

，，，，，
JAVAScript暴露了你的secret key

Answer 3

参数排序，MD5加密，token认证 生成签名
具体见http://onwise.xyz/2017/02/13/...

Answer 4

签名认证的核心在于 secret 不能暴露给前端，所以顺序一定是：服务器生成 token 交给前端，前端带 token 请求，服务器检查 token。

注意生成 token 用的 secret 始终保存在服务端，前端自己不生成 token，否则 secret 和加密方法都暴露了。

至于使用什么样的 token，JWT 已经有规范了不用自己琢磨： https://jwt.io

Answer 5

客户端是浏览器的：采用前端rsa+token
客户端是native的：采用原生代码混淆+rsa+token

Answer 6

secret_key 不能暴露在参数中，可以这样
用户录入的字段为content，这样你需要传3个字段到服务器
user_id
content
timestamp

你可以再添加一个字段，命名为 verify_code，verify_code可以按照类似以下规则生成
md5(secret_key.substring(0, 4) + timestamp.substring(0, 4) + user_id + content + timestamp.substring(4, 10) + secret_key.substring(4, 10))

所以，按照你那种方法，最少要传4个参数到服务器比较稳妥
user_id
content
timestamp
verify_code

然后服务端只需校验verify_code

Answer 7

可以参考这篇文章
http://www.cnblogs.com/liemei...

Answer 8

不需要这么复杂，简单一点就是不要用 userid， 换成一个加密串 token （服务端下发，类似session的功能），如果要使用 userid，需要保证 userid足够随机化, 可自校验，例如 1234-x1d23-dax23-1233dx等。
只要保证 识别用户的字段 无法猜解，无法伪造就行了。

Answer 9

题主其实是在说HTTP请求的 防篡改 而已。

1. 基础设施上部署SSL。

2. ACL控制，如果有必要的话。

3. 请求参数签名，但也没有必要用在用户反馈这类业务上，因为这类业务哪怕被劫持也没有太大意思。

反而，应该考虑的是HTTP限流策略。