可信应用程序执行
假设我们有两个应用程序:
MasterApp
SlaveApp
MasterApp 正在使用一些参数执行 SlaveApp,fe: slaveapp --param1 100 param2 "hello"
您无法直接看到这一点,但有人可能会尝试检查参数提供给slaveapp,并从控制台执行它。
我希望 SlaveApp 只能由 masterApp 执行,以便用户无法在控制台模式下运行它(或作为从属应用程序或其他应用程序)。我正在考虑提供一些 unique_string
和 md5(unique_string + salt)
,但如果有人检查参数,他可能会明白发生了什么。有没有办法仅通过提供一些独特的、可信的参数来做到这一点,这些参数不能使用两次(并且没有像带有私钥/公钥的文件等资源共享)?
Assume that we have two applications:
MasterApp
SlaveApp
MasterApp is executing SlaveApp with some arguments, fe: slaveapp --param1 100 param2 "hello"
You can't see that directly, but somebody may try to inspect arguments provided to slaveapp, and execute it from console.
I want slaveapp to become executable only by masterapp, so that user can't run it in console mode (or as slave or another app). I was thinking about providing some unique_string
and md5(unique_string + salt)
, but if somebody will inspect arguments he may understand what's goin' on. Is there some way to do it only by providing some unique, trusted argument that can't be used twice (and there is no resource sharing like files with private/ public keys etc)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
只加密使用预定义加密密钥传递的参数并包含某种类型的 check_string (即 EPOCH 时间)怎么样?然后解码salveapp中的参数并验证check_string(在本例中为EPOCH时间)是否在某个范围内或者是某个值。
这是一个简单的 ruby 示例,它位于单个文件中,因此您需要将其修改为 handel 命令行参数等。
How about just encrypting the paramaters passed with a pre-defined encryption key and including a check_string of some type (i.e. EPOCH time). Then decode the paramaters in salveapp and verify the check_string (in this example that EPOCH time) is within a certain range or is a certain value.
Here is a simple ruby example, its in a single file so you would need to modify it to handel command line arguments ect.
如果你的通信通道只成为master -> ,那么基本上不可能避免重放攻击。奴隶。使用时间戳对请求进行签名可能会有所帮助,但即使这样也并不完美(特别是如果攻击者对时钟有一定控制的话)。
更好的策略是在主从之间建立双向通信。我不确定你使用的是什么语言,但通常有一种方法可以让主站在分叉后与从站对话,而不仅仅是命令行。
使用该通道,您可以让从属设备生成随机数,将其发送到主设备,让主设备对其进行签名,将其发送回从设备,然后检查从设备中的签名。
It is basically impossible to avoid replay attacks if your communication channel only goes master -> slave. Signing the request with a timestamp in it could help, but even that isn't perfect (especially if the attacker has some control of the clock).
The better strategy is to establish a two-way communication between master and slave. I'm not sure what language you're working in, but usually there's a way for the master to talk to the slave after it is forked, other than just the command line.
Using that channel, you can have the slave generate a random nonce, send that to the master, have the master sign it, send it back to the slave, and check the signature in the slave.
确保从应用程序由主应用程序运行的同一用户拥有,并确保它不是世界可读或可执行的。
Make sure the slave app is owned by the same user the master app runs as, and make sure it's not world readable or executable.