问题描述
我有一个与网络服务对话的移动应用程序（目前是IOS，很快就是Android）。没有登录，数据不是私有的。基本上，应用程序POST一个标记（lon，lat）并获取最接近的25个标记以显示在地图上。
I have a mobile app (currently IOS and soon Android) which talks to a web service. There is no login and the data is not private. Basically, the app POSTs a marker (lon, lat) and GETs the nearest 25 markers to display on a map.
这是一个非常简单的应用程序，我无法想象有人放滥用网络服务的努力。但是，我可以看到有人在发布许多标记时很有趣。最让我担心的是有人运行一个脚本来推送许多请求（使用昂贵的带宽并使我的应用数据毫无意义）。
It's a very trivial app and I cannot imagine anyone putting great effort into abusing the web service. However, I can see there is fun for someone in POSTing many markers. What most concerns me is someone running a script that pushes many requests (using expensive bandwidth and making nonsense of my app data).
我慢慢得出结论这不可能是安全。最好的答案是不要这样做。不提供身份验证的Web服务。没有多少服务如此开放。谷歌的You Tube API已经开放，但大多数都没有。不幸的是，我别无选择。所以经过几天的考虑，这是我的想法。请注意，我离安全专家很远，我相信我的方法可以改进。但它可能会指出你正确的方向。希望有经验的人可以在这个问题上加以纠正/改进。我发现和评论特别有帮助。
I am slowly reaching the conclusion this cannot be secure. The best answer is "do not do this". Do not provide a web service without authentication. Not many services are so open. Google's You Tube API is open but most are not. Unfortunately, I have no choice. So after days of looking at this here's my thinking. Be aware I am very far from a security expert and I am confident my approach could be improved upon. But it might point you in the right direction. Hopefully, someone more experienced might chime in and correct/improve upon this. I found this article and comments particularly helpful.
消息级别安全性
我将使用散列加密来保护msgs。客户端和Web服务都保留共享密钥的副本，该密钥用作salt以从URL和所有POST参数创建哈希。散列作为附加参数传递，并且重建散列并在另一端进行比较（使用共享密钥作为salt）。这是非常好的，直到您了解任何移动客户端代码可以在几分钟内进行逆向工程。在这一点上，这条防线完全无用。
I will secure the msgs with a hash encryption. The clients and web service all retain a copy of a shared secret which is used as a salt to create a hash from the URL and all the POST arguments. The hash is passed as an additional argument and the hash is rebuilt and compared at the other end (using the shared key as a salt). This is pretty good until you understand that any mobile client code can be reverse engineered in minutes. At which point this line of defense is utterly useless.
客户措施
客户端包括消息的速率限制，作为限制诚实用户发送的消息数量的措施。然而，对于越狱移动设备的攻击者来说，这是无用的。
The client includes rate limiting of messages as a measure to restrict the number of messages sent by honest users. Yet again this is useless against an attacker who jailbreaks the mobile device.
服务器端安全性
因此，服务器端必须具有尽可能多的额外安全措施，以保证您的客户端（和共享密钥）受到损害。这就是我所拥有的：
So the server side must have as much additional security measures as possible, to stand alone on the assumption that your client (and shared secret) is compromised. Here is what I have:
一个msg arg是一个UTC时间，用于限制重放攻击。这可以防止攻击者反复在服务器上触发相同的消息。
One msg arg is a UTC time which is used to limit replay attacks. This should prevent an attacker from firing the same msg at the server repeatedly.
服务器通过IP执行速率限制。是的，IP容易被欺骗，代理切换是孩子们玩的，但是当你这么少时，一切都会有所帮助。
The server performs rate limiting by IP. Yes, IPs are easily spoofed and proxy switching is childs play but everything helps when you have so little.
当然，服务器严格验证所有参数，使用参数化查询和不会返回例外情况。
Of course, the server strictly validates all arguments, uses parametised queries and doesn't return exceptions.
运输级安全性
不幸的是，我是相当自信，如果没有注册过程，就无法发布个人客户端SSL证书。并且因为我正在使用msg哈希检查（并且我的数据不是私有的），我不完全确定SSL给表带来了什么。但是，我可能会使用SSL（具有一个应用程序范围的证书），因为它增加了另一个安全级别，可以轻松且廉价地部署（尽管每个消息的额外连接时间都是成本）。
Unfortunately, I am fairly confident that issuing individual client SSL certs is not possible without a registration process. And because I am using the msg hash check (and my data is not private) I am not entirely sure what SSL brings to the table. However, I will probably use SSL (with one app wide cert) because it adds another level of security that is easily and cheaply deployed (albeit at a cost of additional connection time for every msg).
我的方法中的大洞大洞
我被警告如果应用程序变得受欢迎，有人会妥协在客户端共享秘密。只是因为他们可以，他们可能会在互联网上发布它。所以这一切都归结为服务器端。不幸的是，我无法识别并阻止攻击者。我非常喜欢这个。
I am warned that should the app become popular that someone will compromise the shared secret on the client. Just because they can and they will probably post it on the internet. So really it all comes down to the server side. Unfortunately, I have no way to identify and block an attacker. This I would dearly love.
最终辩护
经过数天的研究，这就是我的全部。但我想要更多。我特别感谢任何加强服务器端的想法。所以，我把所有的SO点都作为赏金。是先生，全部97分！
After days of research this is all I have. But I want more. I would particularly appreciate any ideas to beef up the server side. So, I have put all my SO points up as a bounty. Yes sir, all 97 points!
推荐答案
实际上在您的特定情况下，由于它目前只是iOS应用程序，因此有一个解决方案。
Actually in your particular case, since it is currently an iOS only app, there is a solution.
-
用户首次下载并运行应用程序后，应用程序点击
/ access_token / create带有GUID的API，并通过Apple的推送通知将其中继回应用程序。
After the user downloads and runs the app for the first time, the app hits a
/access_token/createAPI that comes up with a GUID and relays it back to the Application via Apple's Push Notifications.
App存储此access_token，并在其上使用它所有后续请求。你的实际API可以根据access_token进行速率限制。
App stores this access_token, and uses it on all subsequent requests. Your actual API's can rate limit on the basis of the access_token.
基本上，你让Apple做了所有艰苦的工作确保初始请求来自实际的iOS设备。
Basically, you let Apple do all the hard work of ensuring that the initial request came from an actual iOS device.
将此扩展到桌面客户端是可能的，但有点破坏了UX。只需更改步骤1以允许 / access_token / create 接受任意请求，如果请求不是来自iOS设备，则强制用户验证其电子邮件地址/解决在发给他们access_token之前的验证码等。
Extending this to Desktop clients is possible, but somewhat ruins the UX. Just change step 1 to allow /access_token/create to accept arbitrary requests, and if the request is not from a iOS device, then force the user to verify their email address/solve a captcha etc before issuing them an access_token.
Android设备（不熟悉它们）可能有类似的推送通知机制，在这种情况下你可以使用它，或者可能没有推送通知机制，在这种情况下，您可能会对Android用户造成上述不便。
Android devices (not really familiar with them) may have a similar Push Notification mechanism, in which case you can use that, or may not have a Push Notification mechanism, in which case you can subject your Android users to the inconvenience listed above.
这篇关于如何在不登录的情况下保护Web服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！