Ash*_*Ash 4 php security hash image server
例如,如果您有一个允许成员之间发送私人图像的在线社区,例如数字笔友或约会网站。
在网络服务器上保护这些图像的最佳实践以及将它们显示给经过身份验证的用户的最佳实践是什么?
这是我到目前为止所做的:
在 root 之外似乎是存储图像以使其难以访问的最佳方法之一,但是如果服务器本身被直接黑客入侵怎么办?
有没有办法对图像文件进行哈希和盐处理,以便只有在哈希和盐匹配后才能显示图像,即使黑客拥有该文件?这可以通过 PHP 或 SQL 返回吗?我正在考虑将图像编码为base64,并使用每个用户随机生成的密码生成的盐对base64进行加盐(这可能吗?)或者有更好的方法吗?
对于基本保护,您所描述的内容可能已经足够,甚至可能太多,因为如果文件夹位于 www 根目录之外,则随机化文件夹名称不会增加太多安全性,但会增加复杂性。
根据您应针对您的场景进行的风险评估,您可以选择采取更多措施。当然,如果您发现可以用 10000 美元的成本降低 100 美元违规的风险,您可能不想这样做。所以先做数学。:)
我可以看到您的解决方案面临两个主要威胁,其中一个是访问控制逻辑中的错误,该错误允许用户下载他不应该访问的图像。另一种是攻击者获取您的 Web 服务器的访问权限并下载图像(由于您的 Web 服务器需要访问图像文件,这不一定是 root/admin 访问权限,这会增加风险)。
人们可以想到的一个想法是对服务器上的图像进行加密。然而,对于加密来说,密钥管理通常是问题所在,现在的情况正是如此。使用应用程序可以访问的密钥进行加密并没有多大意义,因为在成功应用程序级别攻击的情况下(以及服务器/操作系统级别攻击的情况下,攻击者也可以访问该密钥,因为用户运行您的网络服务器和/或应用程序必须有权访问该密钥)。
理论上,您可以为所有用户生成公钥/私钥对。当有人上传图像时,您将为图像生成对称密钥,使用该密钥加密图像,然后使用每个预期接收者的公钥加密对称密钥,并将加密密钥(和元数据)与图像一起存储。用户的私钥也应该加密,最好使用通过适当的密钥派生函数(如 PBKDF2)从用户密码派生的密钥。一个暗示是,您只能在用户登录时获取用户的私钥,因为您不存储他的密码,因此这是您唯一拥有它的时间。这意味着您必须至少将用户的解密私钥存储在服务器内存中,这并不真正安全(任何其他存储都更糟糕)。不过,这仍然可以提供针对离线攻击者的保护(例如,有权访问备份的人),并且还将攻击范围限制为在服务器受到损害时登录的受害用户(意味着在服务器受到损害之后,但在您意识到这一点之前) 。另一个缺点是该解决方案的复杂性 - 加密很难,如果没有经验,很容易搞砸。这也将减轻访问控制缺陷带来的威胁,因为无法使用登录用户的私钥解密意外的图像。
一种完全不同的方法是将应用程序分成几个组件:登录服务(类似于 SSO)、Web 服务器和后端图像服务。当您的用户登录到身份验证提供商 (AP) 时,在这种情况下,他将收到由 AP 签名的带有声明的令牌。当与 Web 应用程序交谈时,他将使用此令牌进行身份验证。该解决方案与之前的解决方案的区别在于,当用户请求图像时,Web 应用程序会将其令牌传递给图像服务,图像服务一方面可以将图像安全地存储在无法直接从互联网访问的盒子上,另一方面另一方面,它可以授权是否要针对收到的令牌返回图像(它可以使用 AP 或自行验证令牌,具体取决于您选择的实现)。在这种情况下,即使攻击者破坏了 Web 应用程序,他仍然无法从 AP 生成(签名)有效令牌来访问图像服务上的图像,并且破坏 Web 应用程序可能会困难得多图像服务。当然,如果网络服务器遭到破坏,攻击者仍然能够观察到流经的任何图像,这意味着在服务器受到攻击时登录的任何用户仍然会向攻击者丢失其图像。该解决方案增加的复杂性甚至比前一个解决方案还要糟糕,这意味着也很容易出错,而且开发和维护成本也很高。
请注意,这些解决方案都不能保护图像免受服务器管理员的攻击,这可能是也可能不是您的应用程序的要求。
我希望这个答案能够阐明使其比当前解决方案更加安全所涉及的困难。话虽如此,实施是关键,而细节(实际的代码级漏洞)可能最重要。
| 归档时间: |
|
| 查看次数: |
3446 次 |
| 最近记录: |