我可能对整个过程有点偏执,但我想做正确的事情,以确保只有合法用户可以为我们的服务创建帐户,我们不包括 api secret隐藏在我们的二进制文件中,可能是“逆向工程”
我们想要点击“点击Twitter”和“使用Facebook登录”,我们可以使用相应的SDK来获取authToken。
例如。:
如前所述https://dev.twitter.com/twitter-kit/ios/twitter-login 提供SDK中的以下信息,
authTokenproperty
authTokenSecretproperty
userNameproperty
userIDproperty
但我必须将钥匙嵌入
[[Twitter sharedInstance] startWithConsumerKey:@"your_key"
consumerSecret:@"your_secret"];
我们要验证此authToken实际上是合法的,我们的服务器需要验证此信息。构建整个过程的正确方法是什么?
FBSession *session = [[FBSession alloc] initWithAppID:APP_ID permissions:permissions
urlSchemeSuffix:nil tokenCacheStrategy:[[FBSessionTokenCachingStrategy alloc]
initWithUserDefaultTokenInformationKeyName:@"TEST"]];`
如果黑客能够对此APP_ID或Twitter密钥进行反向工程,我们如何在我们的服务器上验证此信息以确保这是合法的?
最佳做法是什么?
答案 0 :(得分:1)
让我们把这个问题转过一会儿。恶意用户可以完全控制客户端的副本(总是如此),他们可以用它做什么?
攻击者可以使用他们控制的任何帐户通过您的客户端进行身份验证。然后,他们可以使用您的凭据进行Twitter / Facebook API调用。这是一个问题吗?由于攻击者拥有这些帐户的凭据,因此不会向他们提供他们尚未拥有的任何控制权。他们可以使用它来排除API速率限制,并且他们的活动可能显示为来自您的应用程序,但是在您仍然允许使用您的应用程序时,您可以做很多事情来阻止它。也许它提供了使您的API凭证可更新的理由,但任何更新都将发送给仁慈和恶意用户。
您看到了哪些其他威胁?如何使用这些权限以及如何利用这些权限?
您是否识别使用这些帐户的用户?控制客户端的攻击者是否可以使用此伪造凭证生成新帐户或尝试控制其他用户的帐户?
您是在存储或传输生成的oauth会话凭据吗?攻击者是否可以拦截他们以控制其他用户帐户?
答案 1 :(得分:0)
关于保持消费者保密等安全,这是另一个非常好的答案的问题:How to keep the OAuth consumer secret safe, and how to react when it's compromised?
回答另一个问题,验证后端的用户身份:您应该做的是将代表该用户使用twitter或facebook API所需的身份验证令牌转移到您的后端(当然最好通过安全方式SSL等),并从后端发出GET /v2.2/me
(facebook graph api)等请求。现在您可以比较数据并知道用户确实已经为您提供了真实的Facebook或Twitter帐户。
答案 2 :(得分:0)
Twitter / FB为用户提供标识,但不为您的应用提供标识。您应该为您的客户端应用程序提供单独的凭据(告诉您的服务器端这是一个受信任的应用程序)。在这种情况下,您的服务器端可以信任来自您应用的通信。