如何在不登录的情况下保护Web服务

Question

我有一个移动应用程序(目前是IOS,很快就是Android),它与Web服务进行通信.没有登录,数据不是私有的.基本上,应用程序POST一个标记(lon,lat)并获取最近的25个标记以显示在地图上.

这是一个非常简单的应用程序,我无法想象有人在努力滥用Web服务.但是,我可以看到有人在发布许多标记时很有趣.最让我担心的是有人运行一个脚本来推送许多请求(使用昂贵的带宽并使我的应用数据无意义).

我慢慢得出结论,这是不安全的.最好的答案是"不要这样做".不提供身份验证的Web服务.没有多少服务如此开放.Google的You Tube API已经开放,但大部分都没有.不幸的是,我别无选择.所以经过几天看这里是我的想法.请注意,我离安全专家很远,我相信我的方法可以改进.但它可能会指出你正确的方向.希望更有经验的人可以加入并纠正/改进.我发现这篇文章和评论特别有帮助.

消息级安全性

我将使用哈希加密来保护msgs.客户端和Web服务都保留共享密钥的副本,该密钥用作salt以从URL和所有POST参数创建哈希.散列作为附加参数传递,并且重建散列并在另一端进行比较(使用共享密钥作为salt).这一点非常好,直到您了解任何移动客户端代码可以在几分钟内进行逆向工程.在这一点上,这条防线毫无用处.

客户措施

客户端包括消息的速率限制,作为限制诚实用户发送的消息数量的措施.然而,对于越狱移动设备的攻击者来说,这是无用的.

服务器端安全性

因此,服务器端必须具有尽可能多的额外安全措施,并且假设您的客户端(和共享密钥)受到损害.这是我有的:

一个msg arg是UTC时间,用于限制重放攻击.这应该可以防止攻击者反复在服务器上触发相同的消息.

服务器通过IP执行速率限制.是的,IP很容易被欺骗,代理切换是孩子们的游戏,但是当你这么少时,一切都会有所帮助.

当然,服务器严格验证所有参数,使用参数化查询并且不返回异常.

运输级安全

不幸的是,我相信在没有注册过程的情况下无法发布个人客户端SSL证书.因为我正在使用msg哈希检查(并且我的数据不是私有的),我不完全确定SSL给表带来了什么.但是,我可能会使用SSL(具有一个应用程序范围的证书),因为它增加了另一个安全级别,可以轻松且廉价地部署(尽管每个消息的额外连接时间都要花费).

在我的方法中的Gaping伟大的大洞

我被警告说,如果应用程序变得流行,有人会破坏客户端的共享秘密.只是因为他们可以,他们可能会在互联网上发布它.所以这一切都归结为服务器端.不幸的是,我无法识别并阻止攻击者.我非常喜欢这个.

最后的辩护

经过几天的研究,这就是我的全部.但我想要更多.我特别感谢任何加强服务器端的想法.所以,我把所有的SO点都作为赏金.是的先生,全部97分!

Answer 1

实际上在您的特定情况下,由于它目前是仅限iOS的应用程序,因此有一个解决方案.

1. 用户首次下载并运行应用程序后,应用程序将点击/access_token/create提供GUID 的API,并通过Apple的推送通知将其中继回应用程序.

2. App存储此access_token,并在所有后续请求中使用它.您的实际API可以根据access_token进行速率限制.

基本上,您让Apple尽一切努力确保初始请求来自实际的iOS设备.

将此扩展到桌面客户端是可能的,但有点破坏UX.只需更改步骤1即可/access_token/create接受任意请求,如果请求不是来自iOS设备,则强制用户在发出access_token之前验证其电子邮件地址/解析验证码等.

Android设备(不熟悉它们)可能具有类似的推送通知机制,在这种情况下您可以使用它,或者可能没有推送通知机制,在这种情况下,您可能会让您的Android用户受到上述不便之处.

Answer 2

在谈到寻找垃圾邮件问题的全局解决方案时,我曾经听说过这个想法:强迫客户执行一些计时工作.

准确地说:找一些计算算法,可以计算一些z为一对x,并y在一眨眼的功夫,但它需要一定的时间相当数量的计算z只被给予x.我无法提供实际的算法,但我确信有很多这样的标准.

现在整个过程应如下所示:

1. 在第一个客户端请求生成一些session_id和为此session_id一对x和y.
2. 为您的客户提供session_id和x.
3. 客户端可以在收到数据后立即开始计算(在某些后台线程中与用户交互无关).
4. 要请求标记,客户必须提供session_id和计算z.
5. 您可以快速验证客户端z是否正常,因为您已经拥有x并且y可以轻松完成.
6. (选项1)对于每个session_id商店,请求的数量/频率.你怀疑它被滥用的那一刻 - 强制再生x和y.
7. (选项2)强制新的x并且y每次连续请求a session_id.

选择6到7之间实际上是调整,这取决于算法的复杂性与标记数据库的预期"公平"使用.如果你的估计是好的 - 邪恶的客户端永远不应该获得太多的数据或过载你的服务器.

希望能帮助到你.

Answer 3

在客户端你无能为力.您必须将整个应用程序(包括任何密钥或任何其他保护机制)提供给您的用户.如果恶意用户想要对您的Web服务进行恶作剧,他将不得不进行一些逆向工程来访问您的Web服务.你可以做得更难,但无论你怎么努力,你都无法阻止这种情况.

我只是实现一些服务器端速率限制(每个IP地址),不再担心这个问题.这是一场你无法获胜的战斗.如果有人真的想要伤害你的服务器,他可能只是DDOS而不知道你的web服务协议.

此外,在第一次连接时自动为每个用户生成唯一密钥或证书根本没有帮助.在攻击者对您的协议进行逆向工程后,他知道如何处理所有这些并且不必遵守您的规则.每次遇到速率限制时,没有什么能阻止他从你的服务器请求一个新密钥.

Kuba Wyrostek描述的方法可以工作 - 使客户端执行一些耗时的计算,您可以在允许处理请求之前快速检查.但这不会花太长时间,否则您的用户会抱怨电池寿命缩短.此外,攻击者可能会使用更强大的桌面硬件而不是其他iPhone.

最后一点 - 你真的认为这是必要的吗？您不希望用户必须注册,因此您的数据或服务不会太重要.那么,任何人都需要从逆向工程应用程序中获得什么,并充斥您的服务器请求？