安全orm数据逻辑处理

如果我必须给从事数据库工作的开发人员一个建议，那就是：确保安全。您将及时了解的所有其他事情--如何构造表、如何使用ORM、如何优化查询、如何使用索引、如何进行多租户操作。但安全性可能不在需求清单上，当需求变得明显时，可能为时已晚。

所以我要集中精力做几件事：

• 防止SQL注入-确保使用ORM或准备好的语句，而不是使用字符串连接构建查询。否则，恶意参与者可以在查询中注入任何内容，并将其转换为DROP数据库查询，或者更糟的是--将所有数据提取出来。
• 在传输过程中支持加密-这通常必须得到应用程序的驱动程序配置的支持，例如信任特定的服务器证书。即使在同一个数据中心内，未加密的通信也是一个很大的风险，这就是数据库在传输过程中支持加密的原因。(您也应该考虑休息时的加密，但这更像是操作任务)
• 具有应用程序级别的审核日志。-从安全和遵守的角度来看，“谁做了什么”是一个非常重要的问题。没有任何原生数据库功能能够始终如一地回答“谁”这个问题--这是管理用户的应用程序。因此，构建一个审计跟踪层，记录谁对哪些实体/表做了什么更改。
• 考虑敏感数据的记录级加密。-数据库可由能够访问(或恶意访问)的人全部转储。数据泄露就是这样发生的。敏感数据(如健康数据、支付数据，甚至API密钥、机密或令牌)可以使用应用程序管理的密钥进行加密，因此仅对数据库的访问不会显示该数据。另一个经常用于信用卡的选项是令牌化，它将加密责任转移到令牌化提供程序。管理密钥是很困难的，但是即使是一个基本的方法也总比没有好。

安全通常被视为一种“操作”责任，这导致了许多工具试图在不触及应用程序的情况下解决上述问题--Web应用程序防火墙、数据库访问监视的试探法、提取当前用户的尝试等等。但是，应用程序是许多这些保护(虽然肯定不是唯一的地方)的合适位置，而且由于开发人员需要意识到风险和最佳实践。

https://www.douban.com/note/810650064/

我正在尝试让Wazuagent(OSSEC的分支，最流行的开源安全工具之一，用于入侵检测)与我们的自定义后端(即我们的暹粒收集器)允许我们为希望在每个端点上安装代理的客户重用功能，而不仅仅是一个“无代理”到达多个源的收集器。

但即使有一个我无法成功地解密这些消息。(我将提到Wazu和OSSEC，因为两者的功能几乎是相同的，除了河豚之外，Wazuu还添加了AES支持的区别)

这让我对可能的原因进行了为期两天的调查。第一个方面的发现是无文档化的Openssl自动填充密钥和IVs。然后，它引导我实际编写C代码(复制相关的Wazu/OSSEC片段)来调试这个问题。使用Wazu/OSSEC，我生成了一个密文，用Java和OpenSSLCLI生成了一个不同的文本。

https://m.douban.com/note/810650064/

我确保密钥，键大小，IV和模式(CBC)是相同的。它们被同等地填充，并且OpenSSL的EVP API被正确使用。所有这些都得到了确认，但仍然存在不匹配，因此我无法在另一端解密Wazu/OSSEC消息。

在发现0填充之后，我还发现了文档中的一个错误，它使用了FEDCA9876543210而不是在代码中找到的，其中0在9前面-FEDCA0987654321。但这也解决不了问题，只让我走近了一步。

这里关于IVS-Wazu/OSSEC的一个附带说明是使用静态IV，这是一个糟糕的实践。

所以，在调试C代码之后，我得到了一个简单的代码，可以用来再现问题和在发布这个问题5分钟后，我发现了另一个有答案的相关问题--在C中使用十六进制字符串是行不通的。相反，它们应该被编码：char *iv = (char *)"\xFE\xDC\xBA\x09\x87\x65\x43\x21\x00\x00\x00\x00\x00\x00\x00\x00";。因此，值不是对应于十六进制字符串的字节，而是十六进制字符串中每个字符的ASCII代码。我用以下代码验证了在接收Java结束时：

https://www.wenjuan.com/s/UZBZJvu8d4/

这对文档以及整个计划都有影响。因为Wazu/OSSEC AES的关键是：MD5(password) + MD5(MD5(agentName) + MD5(agentID)){0, 15}第二部分实际上被丢弃，因为MD5(密码)是32个字符(=32个ASCII代码/字节)，这是AES键的长度。这使得键派生自一个大得多的选项池--16字节可供选择，而不是256字节。

I 虽然这可以被看作是一个漏洞(由于密钥空间的减少)，但从安全的角度来看，它是相当小的，而且由于通信主要发生在公司网络中，我认为不需要立即私下报告和修复。

然而，我建议引入一个额外的配置选项，以便在不引起向后兼容性问题的情况下允许过渡到更新的协议。事实上，我会进一步推荐使用TLS/而不是一个本土的、基于AES的计划。可以通过TLS相互身份验证而不是通过共享秘密来实现相互身份验证。

在流行软件中发现问题是令人满意的，特别是当它们不是用“本地”编程语言编写的时候。根据经验，编码常常会引起问题，所以我们应该格外小心。