基于单个 URL 请求对设备/用户进行身份验证

发布于 2024-11-29 00:54:28 字数 445 浏览 0 评论 0原文

我们目前有一个 J2EE 系统,它实现了 OWASP 前 10 名安全措施的大部分,目前的应用程序允许用户使用存储在数据库中的用户/密码组合登录。

我有一个映射到 /* 的 java 过滤器来检查会话和会话属性是否存在,以确定用户的登录状态。

好吧,最后问题来了:我们正在与一家制造设备的公司集成,当某个事件发生时,通过 GPRS 发送 URL 请求,这个 URL 是我们系统的链接。

我想(在不影响安全性的情况下)验证这个“设备”,不可能向该设备发送任何信息,因此需要验证单个请求,没有人能够“重放”

我不知道 的 URL如果无需某种相互认证就可以做到这一点。我考虑过要检查 IP 地址白名单,但网络不断更改 IP,并且设备仍然“无法识别”。请指教有什么想法吗?

PS:我的临时解决方案是向过滤器添加例外,但这不是长期的,而且完全不安全。 (SSL 也不是一个选项)

We currently have a J2EE system implementing most of the OWASP top 10 security measures, the application at the moment allows users to log on with a user/password combination which is stored in the database.

I have a java filter mapped to /* to check for session and session attribute presence to determine a user's logged in state.

Ok, finally here is the problem: We are integrating with a company that manufactures devices to send a URL request via GPRS when a certain event occurs, this URL is a link to our system.

I would (without compromising security) like to authenticate this 'device', it is not possible to send the device any information, so a single request needs to be authenticated an no one should be able to 'replay' that URL

I do not know if this is possible without some sort of mutual authentication. I thought about a white-list of IP addresses to check against, but the networks constantly change IP's and the device is still 'unidentified'. Please advise any ideas?

PS: my temporary solution was to add a exception to my filter, but this is not long term and totally insecure. (SSL is also not an option)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

自此以后,行同陌路 2024-12-06 00:54:28

您可以让设备使用私钥签署请求(包括唯一的请求标识符)。然后,服务器可以检查签名是否有效,只有在有效时才接受/应答请求。

请求 ID 可用于确保此类请求不会重播。对请求 ID 使用简单的计数器意味着可以很容易地检查给定的标识符是否已被使用(即请求是否正在重播)。

You could let the device sign the request (including a unique request identifier) with a private key. Then, the server can check if the signature is valid and only accept/answer the request when it is.

The request ID can be used to ensure that such requests are not replayed. Using a simple counter for the request ID would mean that it's very easy to check if a given identifier has already been used (i.e. if the request is being replayed).

生寂 2024-12-06 00:54:28

主要问题是,如果第三方获得该设备,则该设备包含的任何身份验证信息都可以供第三方使用。

因此,主要问题是(a)您到底想要验证什么(应该是设备本身还是它的所有者或设备的位置或......)以及(b)设备可以支持哪些功能 - 它是什么类型的设备以及它在运营方面可以做什么。

如果设备可以嵌入旨在保存私钥并阻止提取尝试的智能卡或加密令牌,那么数字签名将会很好地发挥作用。

如果设备可以具有受保护的内存,但无法执行加密操作(并且无法嵌入智能卡),那么我可以想到预先计算的一次性密码列表,每个设备都是唯一的。服务器将拥有全局列表的副本,并在使用该列表后从列表中删除密码。

The main problem is that whatever authentication info the device includes can become available to the third-party if he gets the device.

So the main questions are (a) what exactly you want to authenticate (should it be the device itself or it's owner or device's location or ... ) and (b) what features the device can support -- what kind of device it is and what it can do in operational aspects.

If the device can embed a smartcard or cryptotoken which are designed to hold private keys and counteract extraction attempts then digital signature will work great.

If the device can have protected memory but can not perform cryptographic operations (and can't embed a smartcard), then I can think of the list of precomputed one-time passwords, unique for each device. The server would have a copy of the global list, and remove the password from the list once the list is used.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文