本文是小编为大家收集整理的关于如何从只使用Facebook登录的应用程序中安全地提交分数？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我们的Android App 只有Facebook登录.
这是服务器中发生的事情:
当使用Facebook的用户访问令牌发送发布请求时，创建了用户.
每当用户通过邮政请求创建用户，就会生成API令牌并作为响应发送，如下所示:
{"message":"User Successfully Created","api_token":"ACITyBKf0jKrfqOFumTMcaEEJ8jU151crRdESMPmBj8zbeENslULHfNXlKeo"}
我之所以这样做，是因为服务器中生成的 API令牌存储在Android App的本地存储中，并且需要提出其他请求.
现在，如果用户已经存在于服务器中，则响应将为
{"message":"User Already Exists!!","api_token":"ACITyBKf0jKrfqOFumTMcaEEJ8jU151crRdESMPmBj8zbeENslULHfNXlKeo"}
这是用户删除应用程序并再次安装的情况.
现在，要提交分数，要发送一个补丁请求:
标题:
Content-Type:application/x-www-form-urlencoded api_token:ACITyBKf0jKrfqOFumTMcaEEJ8jU151crRdESMPmBj8zbeENslULHfNXlKeo fb_id:xxxxxxxxxx
身体:
distance:2 golds:19 xp:23
(注意:我使用 Postman 测试了上述请求)
现在，问题是我发现了一个漏洞.
一个人可以随时找出其Facebook用户访问令牌和Facebook ID.因此，如果他们使用该用户访问令牌提出发布请求，他们将收到API_Token(在"用户已经存在！"响应中).一旦他们拥有api_token和fb_id，他们就可以提出一个补丁请求以将自己的分数修改为他们想要的任何东西.
我在做什么错?如何将服务器固定在这样的黑客攻击中?
请帮助我.我是API设计的初学者.
谢谢
推荐答案
如果他们的API令牌在应用程序中完全可以使用，那可能是一件坏事.如果他们在应用程序中不可用，则说他们只是伪造应用程序内请求并检索原始数据，那么他们可能会试图破解系统.
如果是这样，则可能首先通过帖子发送未加密的API密钥是一个坏主意.如果他们的API键是他们开始为您的系统做坏事，为什么首先将其交给他们呢?
因为您的应用需要记住它们.那这样的事情呢:
新用户，Server MD5 HASHES API密钥，并将其发送给将其存储. 现有用户，Server MD5 HASHES API密钥并将其发送给将其存储(如果需要) 发生官方现有分数更改发生:APP RE-MD5哈希已将已悬浮的API密钥发送给补丁请求.服务器具有带有双Hashed API键的数据库，它找到了您的数据库并将您识别为用户，并且正常情况从那里进行.
问题描述
Our android app only has facebook login.
Here's what happens in server:
A user is created when a POST request is sent using facebook's user access token in body.
Whenever a user gets created via POST request, an api token is generated and sent as a response as follows:
{"message":"User Successfully Created","api_token":"ACITyBKf0jKrfqOFumTMcaEEJ8jU151crRdESMPmBj8zbeENslULHfNXlKeo"}
I did this because the api token that is generated in the server is stored in android app's local storage and is needed to make other requests.
Now, if the user already exists in the server, the response would be
{"message":"User Already Exists!!","api_token":"ACITyBKf0jKrfqOFumTMcaEEJ8jU151crRdESMPmBj8zbeENslULHfNXlKeo"}
This is in case the user deletes the app and installs again.
Now, to submit score, a PATCH request is to be sent with:
Headers:
Content-Type:application/x-www-form-urlencoded api_token:ACITyBKf0jKrfqOFumTMcaEEJ8jU151crRdESMPmBj8zbeENslULHfNXlKeo fb_id:xxxxxxxxxx
Body:
distance:2 golds:19 xp:23
(Note: I tested the above request using postman)
Now, the problem is that I spotted a loophole.
A person can find out their facebook user access token and their facebook id anytime. So, if they make a POST request with that user access token, they will receive the api_token (In the "User Already Exists!!" response). And once they have api_token and fb_id, they can make a PATCH request to modify their scores to whatever they want.
What am I doing wrong? How can I secure my server from being hacked like this?
Please help me. I am a beginner in api design.
Thanks
推荐答案
If their API token is available to them in the app at all, that's probably a bad thing. If its not available to them in the app, say they're just forging in-app POST requests and retrieving the raw data, then they're probably trying to hack or pentest the system.
If that's the case, maybe sending the unencrypted API key via POST in the first place is a bad idea. If their API key is all they need to start doing bad things to your system, why ever give it to them in the first place?
Because your app needs it to remember them. What about something like this:
New user, server md5 hashes their API key and sends it to them to be stored. Existing user, server md5 hashes their api key and sends it to them to be stored (if needed) Official Existing Score change occurs: app re-md5 hashes the already hashed api key, sends that with the PATCH request. Server has database with doubly hashed api keys which it finds yours and identifies you as the user, and things go on normally from there.
更多相关问答
联系站长