【转】谈APP后端开发

APP开发


浏览:890 次

收割台收割台

标题标题建议加字段:

批准

用于存储access_ Token,通过它可以对用户进行身份验证。可以理解,它相当于cookie_ID中的会话,使用此令牌,默认用户已通过身份验证登录。

客户签名

用于确定请求是否由客户端APP发起。最常用的方法之一是使用ASE加密和解密。一种方法是比较信息摘要。最简单的生成方法是给出一个随机值和时间戳,并按照一定的顺序加密与服务器商定的salt值。

signture=md5(nonce+timastamp+salt)

当服务器接收到签名时,它按照约定的顺序执行MD5加密比较和签名。如果服务器生成的签名与客户端的签名不一致,则可以认为这不是来自客户端的请求,并且此时不响应请求。当然,您应该使用此方法同时提交时间戳和随机字符串nonce。

版本客户端版本

它用于存储客户端的版本号。它主要是一个小版本。对于大型版本,服务器将打开一个新界面。但是,最好为客户端的每个版本提供一个版本号。即使在这个版本中,服务器也没有做任何更改。只要客户端是新发布的,也应该给它一个新的版本号。然后将版本号写入页眉。这样做的好处是,如果请求中出现错误,我们可以找到哪个版本的APP出现了错误,从而更容易定位和再现错误。更详细地说,设备的操作系统和型号也可以在报头中提交。

时间戳请求时间戳

客户端发送请求时的时间戳,可用于判断请求是否过期。

客户端签名详细信息

重组攻击

虽然签名存在,但我们可以判断请求是否由客户端生成,因此我们只能响应客户端的请求。但安全是不够的。

典型的攻击方法是通过数据包捕获客户端生成的签名不断请求接口。最常见的方法是使用此签名连续请求SMS验证码接口,直到服务器的验证码余额耗尽。

防止重放攻击的最有效方法是保持签名的唯一性。客户端必须生成唯一签名。同时,服务器必须确保它只能响应一次签名请求。

确保客户端签名的唯一性

客户端确保每次生成唯一签名的最简单方法是向签名生成方法添加时间戳。

服务器保证每个签名只签名一次。实现方法是:判断每个请求。如果请求所携带的签名未被使用,请响应请求,并在服务器上记录签名并将其标记为已使用。如果发现请求所携带的签名已标记为已使用,则不会对请求作出响应。

服务器以三种方式记录签名:

写入文件

写入MySql数据库

写入Redis

写入文件的缺点是它们不能被分布式系统使用。MySql的缺点是,当有很多请求时,它会增加数据库的压力。所以最好的方法是将其写入Redis。

添加签名超时机制

确保客户端签名唯一性的方法是在服务器上记录每个请求的签名。然而,随着请求的增加,记录的签名越来越多。对于每个请求,逐一比较所有先前请求记录的签名显然是不合理的。

因此,正确的方法不是简单地将签名写入文件MySQL或Redis。相反,您应该创建一个文件缓存,或者将临时表写入数据库,或者使用Redis缓存。

然而,如果我们只比较缓存期内的签名,攻击者仍然可以使用缓存清除的过期签名执行重放攻击。因此,我们引入了超时机制。如果请求所携带的时间戳大于当前服务器时间间隔大于正弦缓存时间,则不会响应请求。这确保了攻击者无法使用缓存清除的签名进行重放攻击。

当然,超时不能设置得太小,因为客户端请求到达服务器需要一定的时间。因此,超时设置应满足

(服务器的当前时间-客户端提交的时间戳)<超时<签名缓存过期时间

引入超时机制的另一个优点是防止中间人