【问题标题】:Secure App with Api server with static jwt token使用带有静态 jwt 令牌的 Api 服务器保护应用程序
【发布时间】:2019-01-04 17:41:39
【问题描述】:

这可能已经被问过了,但也许 2018 年有更好的方法。我正在尝试保护我的 api 服务器,并且只授予对我创建的客户端应用程序的访问权限。移动/Web 客户端应用程序将 vue.js 用于客户端应用程序,并将 express.js 用于 api 服务器。

在客户端应用程序上创建一个静态令牌代码是明智之举。它将与每个 api 调用一起发送。然后在 api 服务器上有我对令牌的秘密。 api调用回传前验证token。

有没有更好的方法?它似乎工作正常,但也许有一些我不知道的东西。也许不时更换静态令牌和秘密?网络肯定是https。我通过每个 api 调用 req.body.clientAppToken

发送令牌

你怎么看?谢谢大家!

更新这是下面的 express api 中间件。

App 在每次请求时都会向 api 服务器发送一个手动创建的令牌。所有应用程序的令牌都是相同的。我使用存储在服务器上的秘密验证令牌。如果通过了,他们就会得到数据,如果没有,他们就不会。

const jwt = require('jsonwebtoken')
const config = require('../config/config')

module.exports = {
  authClientAppToken (req, res, next) {
    // start see if client app jwt is correct
    /* eslint-disable */
    console.log('req.body.clientAppToken', req.body.clientAppToken)
    try {
        let decoded = jwt.verify(req.body.clientAppToken, config.jwtAppSecret)
        next()
    } catch (err) {
        res.status(400).send({
            error: 'We got problems'
        })
    }
    /* eslint-enable */
    // end see if client app jwt is correct
  }
}

【问题讨论】:

    标签: api express single-page-application


    【解决方案1】:

    我正在尝试保护我的 api 服务器,并且只授予对我创建的客户端应用程序的访问权限。移动/Web 客户端应用程序将 vue.js 用于客户端应用程序,并将 express.js 用于 api 服务器的节点。

    残酷的事实是,您无法真正保护 Web 应用程序,因为任何类型的秘密,无论是 JWT 令牌、签名的 JWT 令牌、API 密钥还是您可能想要使用的任何其他内容,都可以在客户端只需使用浏览器开发工具,也就是 F12。

    在移动应用程序上,开发人员可能会认为,一旦他们发布了一个二进制文件,他们就可以在其中隐藏秘密并确保其安全,那么移动应用程序并不像在浏览器中使用 F12 那样容易查看,但它们足够简单使用Mobile Security Framework 之类的工具进行逆向工程,该工具将提取二进制文件中的所有代码,从而暴露存储在其中的所有秘密。但即使秘密是在运行时计算的,该工具也能够对您的移动应用正在执行的操作进行运行时自省,因此也能够提取动态计算的秘密。

    在客户端应用程序上创建一个静态令牌代码是明智之举。它将与每个 api 调用一起发送。然后在 api 服务器上有我对令牌的秘密。 api调用回传前验证token。

    因此,如前所述,在客户端生成或存储的任何秘密都可以在其预期范围之外被提取和重用。尽管如此,我仍然鼓励将它们用作多一层防御。

    它似乎工作正常,但也许有一些我不知道的东西。

    我建议您通过 this series of articles 了解移动 API 安全技术,以了解如何使用 https、证书固定、api 密钥、令牌、HMAC 来保护 API 服务器以及如何绕过它们。虽然本文是在移动 API 的上下文中,但几乎所有内容都适用于为 Web 应用程序提供服务的 API 的上下文。

    也许时不时地替换静态令牌和秘密?

    在令牌上使用较短的过期时间是明智的并建议使用,但它们只会缩短可被恶意重用的窗口,但不会防止 API 滥用。

    网络肯定是 https。

    虽然 https 应该始终单独使用,但它只能保证传输中的数据被加密并且无法被第三方读取,从而保护传输中的秘密,但不会阻止它们从应用程序本身进行逆向工程。

    有没有更好的办法?

    对于网络应用,您可以通过使用javascript obfuscation tool 来提高难度,实施reCaptcha V3,如果您想在您的 API 服务器上更高级地使用用户行为分析软件解决方案。

    关于移动应用程序,可以以不需要在其中存储秘密的方式构建它们,以便在每次调用中传递给 API 服务器。该技术称为移动应用程序认证,由移动 sdk 和云服务组成,它们协同工作以确保移动应用程序与上传到 Google Play 或 App Store 的移动应用程序相同。移动 sdk 在后台运行并与云服务通信,当应用程序是原始应用程序并且未在越狱或 root 设备中运行或成为中间人攻击的对象时,该云服务将发出有效的 JWT 令牌。有效的 JWT 令牌是由只有云服务和 API 服务器知道的秘密签名的令牌,移动应用程序在任何时候都不知道它,因此不可能进行逆向工程或伪造它。无效的 JWT 令牌与有效令牌的区别仅在于使用 API 服务器未知的秘密进行签名,从而使其与有效令牌无法区分。可以在Approov 找到这种类型的安全解决方案,这是我目前工作的地方。

    【讨论】:

    • 感谢您的信息!我会好好读一读!但是关于在客户端上有秘密。它不会是.. 它只是一个令牌,只有 api 服务器会知道验证令牌的秘密。然后它将批准 api 请求。我假设有人将不得不暴力破解令牌以获取其秘密。我想也许你可以通过使用超长的强秘密并更换令牌并每隔一段时间更改秘密来解决这个问题。我相信我会在您提供的信息中找到答案。
    • 在用于识别目的时,是否签名的令牌都被视为机密。在您的情况下,您想创建一个签名的 JWT 令牌以静态存储在应用程序中以供每次 API 调用使用?
    • 是的,我在应用程序上静态存储了一个令牌。我手动创建了它。在每次请求之前,它都会在 api 服务器上得到验证。如果未得到验证,则对服务器的调用将引发错误
    • 这样我就知道api请求来自我的应用程序,而不是一些随机的机器人
    • 不幸的是,正如我在分享的有关 API 安全技术的链接中所解释的那样,任何用于向 API 服务器识别应用程序的静态机密都很容易被任何攻击者绕过,包括机器人。攻击者只需对应用程序进行逆向工程以提取静态密钥,然后在机器人执行的所有 API 调用中重用它。使用针对移动应用的 Mobile Security Framework 或针对 Web 应用的 F12 等工具,对应用进行逆向工程以提取机密非常容易。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-07-28
    • 2019-12-15
    • 2018-12-26
    • 2014-08-12
    • 1970-01-01
    • 1970-01-01
    • 2018-05-20
    相关资源
    最近更新 更多