【问题标题】:How to Verify Whether Request Headers were Added by a Specific Web Application如何验证请求标头是否由特定 Web 应用程序添加
【发布时间】:2020-05-04 09:07:44
【问题描述】:

目前我正在做一个需要高安全性的项目。由于最近的一些需求变化,我们使用前端 http 拦截器为每个请求添加了一些特殊的标头(否则它将成为前端模块的巨大变化),它们对系统非常关键。

最近我们观察到可以使用一些浏览器插件修改这些标题,这是一个关键问题。因此,我需要一种方法来确定这些标头是否包含从我的前端添加的原始值并且它们没有被修改。

这些标头值的暴露不是一个大问题。但修改是。

.

.

我的解决方案:

1) 每次模块初始化时生成一个 RSA 密钥对,并将公钥发送到具有该选项卡唯一 ID 的后端服务。

2) 将私钥保存在我前端的服务中,并创建一个公共函数来为给定输入生成签名。

3) 每次调用前端拦截器,都会根据各自的header值计算一个签名值,并附加为另一个header值。

4) 每次请求到达api网关时,都会使用应用初始化阶段保存的公钥验证签名。

.

我的上述解决方案是否存在安全风险。如果有更好的方法解决上述问题,欢迎提出建议:)

【问题讨论】:

  • 这是一个非常幼稚的解决方案,安全性为零(即它不能解决您的问题)。你想要达到的目标是不可能的。客户端上运行的任何应用程序都是用户。你可以把它想象成你的应用程序在服务器上,用户可能会也可能不会使用编程的客户端来帮助他发出请求,但是用户可以发出他想要的任何请求,而你不能防止这种情况发生。
  • 从更实际的角度来看,用户可能想在不修改请求的情况下使用您的应用,或者他可能修改请求,或者他可能修改您的应用,或者他可能根本不使用它......无论您的应用程序中有什么(如生成的 RSA 密钥),用户也拥有它。无论您的应用程序提出什么请求,用户也可以在以任何他想要的方式对其进行修改后提出请求。底线是,您的 API 必须是安全的,您的客户端应用程序不能针对运行它的用户或基础设施安全。

标签: security encryption web-applications digital-signature owasp


【解决方案1】:

考虑使用 JWT 发送这些标头...您可以使用对称签名(例如:HS256)或非对称签名(例如:RS256),具体取决于您是否同时拥有前端和后端的所有权或前端是公开的。 .

更多关于创建JWT和验证它的细节,请参考https://jwt.io/

从你提供的细节来看,这是我得到的想法......对于确切的工作,你没有提供它是web api还是web application等。

【讨论】:

    猜你喜欢
    • 2013-08-11
    • 2010-09-09
    • 2014-09-27
    • 1970-01-01
    • 1970-01-01
    • 2020-03-24
    • 2020-02-21
    • 2012-11-06
    • 2010-12-23
    相关资源
    最近更新 更多