表单数据客户端/服务器端加密的最佳实践
我正在规划一个项目，需要将敏感数据从客户端传输到服务器端，然后传输到 AWS Simple Storage 存储桶。
这是我的计划：
使用 SSL/HTTP(S)，可以通过 Web 表单安全地发布数据，然后由我的 Web 服务器上的 PHP 脚本检索该数据。
服务器收到数据后，PHP 脚本将立即使用适用于 PHP 的 AWS 开发工具包将其发送到 AWS，并使用 AES-256 在服务器端加密数据的指令 - 请参阅 AWS 加密。
问题是在步骤 1 和 2 之间，数据不会被加密，因为它必须首先到达我的网络服务器进行处理。我正在考虑让脚本将数据写入服务器上的文本文件，然后再将其发送到 AWS，然后在发送后立即从服务器中删除临时文件。这样做有什么风险吗？有没有办法将文件流而不是实际文件发送到 AWS Simple Storage 存储桶，从而避免将临时文件写入服务器？
我是否忽略了实现 100% 加密数据传输的最初目标的更好方法？
I am planning a project that requires the transmission of sensitive data from the client-side to the server-side, and then on to an AWS Simple Storage bucket.
This is my plan:
Using SSL/HTTP(S), the data can be posted securely via a web form, which is then retrieved by a PHP script on my web-server.
Once the data is received by the server, the PHP script will immediately send it to AWS using the AWS SDK for PHP with a directive to encrypt the data on the server-side with AES-256- See AWS Encryption.
The problem is that between steps 1 and 2, the data will not be encrypted because it has to hit my web-server first for processing. I'm thinking of having the script write the data into a text file on the server before sending it to AWS, then immediately deleting the temp file from the server after it is sent. Is there any risk in doing this? Is there a way to send a file-stream, rather than an actual file to an AWS Simple Storage bucket, thus avoiding the need to write a temp file to the server?
Am I overlooking better methods of achieving my original goal of data transmission that is encrypted 100% of the way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您将某些内容提交到磁盘，那么有足够动机的攻击者可以安排在该文件到达驱动器盘片时窃取该文件 - 在大多数现代操作系统上收到对磁盘/目录的任何更改的通知是相当微不足道的，因此他们可以简单地监视您的临时目录（无论您在哪里写入这些文件）并将它们复制出来。
即使您立即删除该文件，该文件仍然存在于存储系统的各个缓存中，并且作为磁盘盘片上“可以随时重写”的扇区。在数据被其他内容覆盖之前，即使删除后，更专业的攻击者仍然可以检索文件。
除此之外，拥有足够访问权限的人可以简单地访问 PHP 进程的内存空间并从中提取文件。
所以..你必须问自己的问题是“我的威胁模型是什么”？以及“我在这个文件中存储什么数据？”
如果数据包含信用卡号码，那么您就已经违反了 PCI 标准 - CC 号码永远不能以纯文本/可读格式存储在任何地方。
If you're committing something to disk, then a sufficiently motivated attacker can arrange to steal that file the moment it hits the drive platters - it's fairly trivial to get notified of any changes to a disk/directory on most any modern OS, so they can simply monitor your temp directory (wherever you're writing those files) and copy them out.
Even if you immediately delete the file, the file is still present in the storage system in various caches, and as "can be written over anytime" sectors on the disk platter. Until the data's been overwritten by something else, an even more dedicated attacker can still retrieve the file even after deletion.
Beyond that, someone with enough access rights could simply reach in your PHP process's memory space and extract the file from there.
So.. the question you have to ask yourself is "what is my threat model"? And "what data am I storing in this file?"
If the data includes credit card numbers, then you're already in violation of PCI standards - the CC number can NEVER be stored anywhere in plaintext/readable format.
不是加密专家，所以无法提供帮助，但是...
如果您不相信网络服务器的物理安全性足以依赖标准 Unix 系统强化，那么您可能需要获得更好的网络服务器。
您在中间服务器上使用的任何加密都会受到以下事实的影响：解密密钥必须存储在服务器上才能解密数据并将其发送到 AWS。如果密钥可被窃取，则即使加密，数据也不安全。如果不能窃取，那么数据怎么能被窃取呢？
强制系统仅使用 RAM 而无法写入磁盘是很棘手的，并且忽略了这样一个事实：具有 root 访问权限的人也可以在数据被加密之前直接从 Web 服务器进程的 RAM 中读取数据（有困难）。
一旦有人获得 root 权限，除非密钥存储在其他地方，否则就没有真正的防御，因此我建议在浏览器中使用公钥，在 AWS 中使用私钥。忘记一半解密吧。如果 AWS 不能做到这一点，那就不要使用它。 这个帖子建议他们这样做，并提供教程此处，但从外观上看您需要使用 Java。
Not an encryption expert, so can't help there, but...
If you don't trust the webserver's physical security enough to rely on standard Unix system hardening, you probably need to get a better webserver.
Any encryption you use on the intermediate server will suffer from the fact that the decryption key must be stored on the server in order for the data to decrypted and then sent on to AWS. If the key is stealable, the data is not secure even when encrypted. If it's not stealable, then how can the data be stealable?
Forcing the system to use only RAM with no possibility of writing to disk is tricky and ignores the fact that someone with root access can also read data (with difficulty) directly from the RAM of the webserver process before it gets encrypyed.
Once someone has root, there's no real defence unless the key is stored elsewhere, so I would recommend using a public key in the browser and a private key within AWS. Forget about decrypting it half way. If AWS can't do that, then don't use it. This post suggests that they do, with a tutorial here, but you'll need to use Java by the looks of it.