如何解决如何保护后端移动REST API仅与我的应用程序通信? HMAC-数字签名请求对于APIS 对于移动应用
当前,我有以下安全措施。
- 登录后按请求使用PassportJS的JWT令牌
- 目前仅对我的Login和Register端点进行费率限制
- 通过电子邮件向用户发送未知用户已从其他设备登录的信息
我还能做些什么来保护后端?
解决方法
您当前的安全措施
当前,我有以下安全措施。
- 登录后按请求使用PassportJS的JWT令牌
请记住,JWT令牌仅标识谁在请求中,而不标识什么在执行请求。
- 目前仅对我的Login和Register端点进行费率限制
恭喜您已采取此措施,但您应将其扩展到所有端点,并在每个端点的基础上调整速率限制。尝试找出 正常使用情况下的每秒正常速率,并将速率限制设置为略高于此速率,并进行监控以查看何时由于超出速率限制而导致请求峰值被阻止。
- 通过电子邮件向用户发送未知用户已从其他设备登录的信息
这是人们不常谈论甚至实施的一种措施,但这对于确保用户安全是非常重要的。您可以通过向用户电子邮件发送批准链接,仅允许新登录来自其他设备来进行增强。
WHO和访问API服务器之间的区别
在深入探讨您的问题What else could I be doing to secure the backend?
之前,我想先澄清一个误解,通常我会发现具有任何资历的开发人员,这与谁和什么正在访问API服务器。
我写了一系列有关API和移动安全的文章,在Why Does Your Mobile App Need An Api Key?文章中,您可以详细了解谁和什么之间的区别访问您的API服务器,但是我将从此处提取其主要操作:
什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例,还是机器人,自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛?
谁是移动应用程序的用户,我们可以通过多种方式进行身份验证,授权和标识,例如使用OpenID Connect或OAUTH2流。
因此,请考虑谁,您的API服务器将能够对用户进行身份验证和授权访问数据,并考虑什么作为使该数据访问的软件代表您已通过PassportJS JWT令牌进行身份验证的用户发出请求。
其他安全措施
我还能做些什么来保护后端?
您可能已经知道,您现在缺少使后端证明正在执行请求的措施,因为您当前的措施集中在谁该请求,由PassportJS JWT令牌表示。
为了让后端对自己确实希望从 接收到来自您的移动应用程序的请求更有信心,您需要从移动应用程序和后端这两个方面来进行处理。 / p>
HMAC-数字签名请求
因此,您可以先对移动应用向后端进行数字签名,然后在移动应用中查看here的简单方法:
private fun calculateAPIRequestHMAC(url: URL,authHeaderValue: String): String {
val secret = JniEnv().getHmacSecret()
var keySpec: SecretKeySpec
// Configure the request HMAC based on the demo stage
when (currentDemoStage) {
DemoStage.API_KEY_PROTECTION,DemoStage.APPROOV_APP_AUTH_PROTECTION -> {
throw IllegalStateException("calculateAPIRequestHMAC() not used in this demo stage")
}
DemoStage.HMAC_STATIC_SECRET_PROTECTION -> {
// Just use the static secret to initialise the key spec for this demo stage
keySpec = SecretKeySpec(Base64.decode(secret,Base64.DEFAULT),"HmacSHA256")
Log.i(TAG,"CALCULATE STATIC HMAC")
}
DemoStage.HMAC_DYNAMIC_SECRET_PROTECTION -> {
Log.i(TAG,"CALCULATE DYNAMIC HMAC")
// Obfuscate the static secret to produce a dynamic secret to initialise the key
// spec for this demo stage
val obfuscatedSecretData = Base64.decode(secret,Base64.DEFAULT)
val shipFastAPIKeyData = loadShipFastAPIKey().toByteArray(Charsets.UTF_8)
for (i in 0 until minOf(obfuscatedSecretData.size,shipFastAPIKeyData.size)) {
obfuscatedSecretData[i] = (obfuscatedSecretData[i].toInt() xor shipFastAPIKeyData[i].toInt()).toByte()
}
val obfuscatedSecret = Base64.encode(obfuscatedSecretData,Base64.DEFAULT)
keySpec = SecretKeySpec(Base64.decode(obfuscatedSecret,"HmacSHA256")
}
}
Log.i(TAG,"protocol: ${url.protocol}")
Log.i(TAG,"host: ${url.host}")
Log.i(TAG,"path: ${url.path}")
Log.i(TAG,"Authentication: $authHeaderValue")
// Compute the request HMAC using the HMAC SHA-256 algorithm
val hmac = Mac.getInstance("HmacSHA256")
hmac.init(keySpec)
hmac.update(url.protocol.toByteArray(Charsets.UTF_8))
hmac.update(url.host.toByteArray(Charsets.UTF_8))
hmac.update(url.path.toByteArray(Charsets.UTF_8))
hmac.update(authHeaderValue.toByteArray(Charsets.UTF_8))
return hmac.doFinal().toHex()
}
动态HMAC的后端验证已完成here:
router.use(function(req,res,next) {
log.info('---> VALIDATING DYNAMIC HMAC <---')
let base64_decoded_hmac_secret = Buffer.from(config.SHIPFAST_API_HMAC_SECRET,'base64')
// Obfuscate the static secret to produce a dynamic secret to use during HMAC
// verification for this demo stage
let obfuscatedSecretData = base64_decoded_hmac_secret
let shipFastAPIKeyData = new Buffer(config.SHIPFAST_API_KEY)
for (let i = 0; i < Math.min(obfuscatedSecretData.length,shipFastAPIKeyData.length); i++) {
obfuscatedSecretData[i] ^= shipFastAPIKeyData[i]
}
let obfuscatedSecret = new Buffer(obfuscatedSecretData).toString('base64')
hmac = crypto.createHmac('sha256',Buffer.from(obfuscatedSecret,'base64'))
if (hmacHelpers.isValidHmac(hmac,config,req)) {
next()
return
}
res.status(400).send()
return
})
尽管这是朝着正确方向迈出的重要一步,但可以通过使用Frida之类的工具对移动应用进行反向工程来绕过它:
将您自己的脚本注入黑盒进程。挂钩任何功能,监视加密API或跟踪私有应用程序代码,不需要任何源代码。编辑,点击保存,立即查看结果。全部没有编译步骤或程序重新启动。
可以通过使用“移动应用证明”概念来缓解这种情况,并且要了解更多信息,我建议您阅读我对问题{em>如何保护移动API REST的this answer应用程序?,特别是关于保护API服务器和可能的更好解决方案的部分。
您想参加“额外里程”吗?
在回答安全问题时,我总是喜欢引用OWASP基金会的出色工作。
对于APIS
OWASP API安全项目旨在通过强调不安全API中的潜在风险并说明如何减轻这些风险来为软件开发人员和安全评估人员提供价值。为了实现此目标,OWASP API安全项目将创建和维护“十大API安全风险”文档,以及用于创建或评估API的最佳实践的文档门户。
对于移动应用
OWASP Mobile Security Project - Top 10 risks
OWASP移动安全项目是一个集中式资源,旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目,我们的目标是对移动安全风险进行分类并提供开发控制措施,以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
,移动安全测试指南(MSTG)是用于移动应用安全开发,测试和逆向工程的综合手册。
OWASP在此处提供了REST安全备忘单。 https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
实际上,我们可以提及许多安全措施,但与您的清单类似的选择是,
如果要允许多设备用户访问服务,则可以添加到项目中的另一个安全功能是为每个用户管理活动设备。用户可以查看任何活动设备的日志并将其删除。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。