问题描述
是否可以接受来自我的应用程序的请求？比如说我有一个名为最佳应用的iOS应用程序，它使用Django作为其后端。我如何做到这一点，只有来自Best App的请求才被接受，其他一切都被拒绝？
Is it possible to only accept requests that our coming from my applications? Say for example I have an iOS app called 'Best App' and it uses Django as its backend. How can I make it so that only requests coming from Best App are accepted and everything else is rejected?
我正在考虑在请求中检查HTTP_USER_AGENT如果HTTP_USER_AGENT是最佳应用，我将允许请求通过。但是我最近发现，任何人都可以从Chrome等应用程序修改他们的USER_AGENT，并请求访问我们的资源。
I was thinking of checking the 'HTTP_USER_AGENT' key in the request and if the HTTP_USER_AGENT is 'Best App', I will allow the request to go through. But I recently found out that anyone can modify their USER_AGENT from applications like Chrome and make requests to access our resources.
有没有其他方法可以限制访问我的具体应用？我想通过提供白名单访问来向其他开发人员开放我的后端服务。但是现在，我想继续访问我们的后端私人。
Is there any other way that I can restrict access just to my particular application? I would like to open up my backend service to other developers by giving white-list access. But for now, I would like to keep access to our back-end private.
非常感谢您对此事的建议和见解。
Your advice and insight on this matter is greatly appreciated.
推荐答案
良好的应用安全解决方案是不平凡的。您不能使用任何简单的纯文本对象，如HTTP_USER_AGENT。一个常见的方法是API密钥，其中从注册页面获取的密钥与请求一起提供，但除非将此与其他秘密组合，否则可以通过假复制和提供应用程序。
Good application security solutions are non-trivial. You cannot use any simple, plain-text object like HTTP_USER_AGENT. One common approach is an "API Key" - where a key that is obtained from a registration page is supplied along with the request, but unless you combine this with some other "secret" it can be trivially copied and supplied by the "false" app.
一个相当强大的解决方案将是使用共享秘密的某种形式的挑战/响应。理论上确定的攻击者可以从你的应用中提取你的秘密并使用它，但这需要合理的努力 - 首先他们需要解密你的应用包，然后提取秘密。流程就像 -
One reasonably strong solution would be some form of challenge/response using a shared secret. A determined attacker could, theoretically, extract your secret from your app and use it, but that requires a reasonable deal of effort - first they need to decrypt your app bundle and then extract the secret. The flow is something like -
- 应用程序将请求发送到Web服务进行身份验证，提供API密钥。
- Web服务查找API密钥来确定共享密钥
- Web服务将挑战字符串发送回应用程序
- 应用程序哈希值为秘密并将其发送回网络服务
- Web服务应用相同的哈希值并比较答案
- 如果哈希比较，则Web服务将会话密钥返回到应用
- 应用程序发送所有后续请求的会话密钥
- 在某些时候，您需要使会话密钥无效 - 应用程序注销，超时，请求数量
- App sends request to web service for authentication, supplying API key.
- Web service looks up API key to determine "shared secret"
- Web service sends challenge string back to app
- App hashes challenge string using shared secret and sends it back to the web service
- Web service applies same hash and compares answer
- If hashes compare, web service returns session key to app
- App sends session key with all subsequent requests
- At some point you need to invalidate the session key - either app logout, timeout, number of requests
为了保护这种方法免受中间人攻击，您需要通过SSL运行它，并确保您的应用程序验证服务器证书。
To protect this approach from man-in-the-middle attacks you need to run it over SSL and ensure that your app validates the server certificate.
您还应该实施某种形式的防范强制尝试，例如在x失败后锁定API密钥c
You also should implement some form of protection against brute-force attempts, such as locking an API key after 'x' failed challenges
这篇关于Django：只接受来自我的应用程序的请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！