API 接口签名验证

2016-12-08 21:33:30 +08:00
 hellojammy

点击访问原文 您还可以加入全栈技术交流群( QQ 群号: 254842154 )


系统从外部获取数据时,通常采用 API 接口调用的方式来实现。请求方和 接口提供方之间的通信过程,有这几个问题需要考虑:

1 、请求参数是否被篡改;

2 、请求来源是否合法; *3 、请求是否具有唯一性。

今天跟大家探讨一下主流的通信安全解决方案。

参数签名方式

这种方式是主流。它要求调用方按照约定好的算法生成签名字符串,作为请求的一部分,接口提供方验算签名即可知是否合法。步骤通常如下:

①接口提供方给出 appid 和 appsecret

②调用方根据 appid 和 appsecret 以及请求参数,按照一定算法生成签名 sign

③接口提供方验证签名

生成签名的步骤如下:

①将所有业务请求参数按字母先后顺序排序

②参数名称和参数值链接成一个字符串 A

③在字符串 A 的首尾加上 appsecret 组成一个新字符串 B

④对字符串进行 md5 得到签名 sign

假设请求的参数为: f=1,b=23,k=33 ,排序后为 b=23,f=1,k=33 ,参数名和参数值链接后为 b23f1k33 ,首尾加上 appsecret 后 md5 : md5(secretkey1value1key2value2...secret)。

签名的 php 版本实现:

	public static function sign($appSecret, $params) {
	if (!is_array($params)) 
		$params = array();

	ksort($params);
	$text = '';
	foreach ($params as $k => $v) {
		$text .= $k . $v;
	}

	return md5($appSecret . $text . $appSecret);
}

接口调用方的请求地址类似于:

/api/?f=1&b=23&k=33&sign=signValue

以上签名方法安全有效 地解决了参数被篡改和身份验证的问题,如果参数被篡改,没事,因为别人无法知道 appsecret ,也就无法重新生成新的 sign 。

这里使用了 md5 的算法进行签名,也可以自行选择其他签名方式,例如 RSA , SHA 等。

另外,多说一句,微信公众号开发时,验证服务器地址的有效性也采用了类似的方法,只是生成签名的方法不一样。

请求唯一性保证

md5 签名方法可以保证来源及请求参数的合法性,但是请求链接一旦泄露,可以反复请求,对于某些拉取数据的接口来说并不是一件好事,相当于是泄露了数据。

在请求中带上时间戳,并且把时间戳也作为签名的一部分,在接口提供方对时间戳进行验证,只允许一定时间范围内的请求,例如 1 分钟。因为请求方和接口提供方的服务器可能存在一定的时间误差,建议时间戳误差在 5 分钟内比较合适。允许的时间误差越大,链接的有效期就越长,请求唯一性的保证就越弱。所以需要在两者之间衡量。

秘钥的保存

在签名的过程中,起到决定性作用之一的是 appsecret ,因此如何保存成为关键。我们分类讨论。

接口调用方的代码跑在服务器的情况比较好办,除非服务器被攻陷,否则外接无法知道 appsecret ,当然,要注意不能往日志里写入 appsecret 的值,其他敏感值也禁止写入日志,如账号密码等信息。

假如是客户端请求接口,就需要多想一步了。假如把 appsecret 硬编码到客户端,会有反编译的风险,特别是 android 。可以在客户端登陆验证成功后,返回给客户端的信息中带上 appsecret(当然,返回的数据也可能被拦截,真是防不胜防啊。。。)。特别说明一下,在 android 开发中,假如硬要把 appsecret 硬编码,建议把 appsecret 放到 NDK 中编译成 so 文件, app 启动后去读取。

TOTP : Time-based One-time Password Algorithm (基于时间的一次性密码算法)

在一些小型项目中,可能不需要复杂的签名校验,只需要 做调用方的身份验证。TOTP(rfc6238)即可满足。

TOTP 是基于时间的一次性算法,客户端和服务器端约定秘钥,加入时间作为运算因子得到一个 6 位数字。客户端请求服务端时生成一个 6 位数字,服务端使用相同算法验证这个 6 位数字是否合法。

下面再展开一下讨论,跟本文讨论的主题关系不大。

TOTP 允许 客户端和服务器端存在时间误差,如口令在 N 分钟内有效。给出一下源码供大家参考:

与 TOTP 类似的还有 HTOP,它是基于次数的验证算法。这里不展开讨论。

基于 TOTP 还有很多应用,例如动态的登录口令。用户登录时,除了需要输入设置的密码外,还需要输入动态密码,每个用户的秘钥都不一样,用户的手机端安装一个 app 即可实现,动态口令每 N 分钟变化一次。 android 客户端在各大应用市场搜索 google-authenticator,如 百度应用市场, ios 客户端在 appstore 也可搜索得到。下面给出部分下载链接:

支付宝、 QQ 令牌、银行客户端等这些手机客户端中也有类似的应用,在验证密码之后会多出一道动态口令的验证,他们使用的方案都类似于 google-authenticator 。

大公司的运维人员,甚至是所有员工登录内部 OA 系统(单点登录),都需要 PIN+令牌码的双重验证( PIN 是自行设置的固定密码,令牌码则是动态口令码),他们通常使用 RSA SecurID 双因素动态口令身份认证解决方案。


点击访问原文 您还可以加入全栈技术交流群( QQ 群号: 254842154 )


8758 次点击
所在节点    程序员
24 条回复
bdbai
2016-12-09 18:36:09 +08:00
@raysonx 密钥不保存在客户端,是每次领一个么?这样也能被逆出来的吧。
raysonx
2016-12-09 19:24:52 +08:00
@bdbai 但是你怎么领呢?我也可以拿到你领密钥的 API 自己去领啊,关键你没法对客户程序鉴权。
laxenade
2016-12-10 00:42:29 +08:00
如果是前端调用 api 有什么好的签名方法吗
ihuotui
2016-12-10 09:17:30 +08:00
@raysonx 那就是用户就是破解者,然后可以根据特征封用户了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/326285

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX