假设有一个带有加密数据的 Web 应用程序。例如一个网站，患者可以在该网站上给他们的医生留下笔记。
患者登录，留下便条，该便条使用对称加密加密并插入数据库，如果他回来，用户仍然可以看到他的便条，该便条被解密并且他可以看到它。医生登录，进入病人的笔记，它被解密和打印。
但是该应用程序容易受到 SQL 注入的攻击。黑客找到了它，他在 Web 应用程序中打开了一个帐户并创建了一个虚拟笔记。然后，他使用 SQL 注入并复制其他人的加密笔记并将其内容粘贴到他的笔记（他在表中的行）。当他返回应用程序查看它时，它被解密。
如何防止黑客查看其他加密笔记？
如果我正确理解您的问题，您的系统将使用相同的密钥为患者和医生加密和解密消息。
在这种情况下，假设您可以读取另一个用户的消息并将其作为您自己的消息插入数据库，理论上您的攻击是可能的。
加密方面的缓解措施将是每个用户的唯一密钥或使用公钥/私钥对来加密数据，每个用户再次拥有唯一的密钥，以增加安全性并在发生违规时限制损坏。
其他机制包括通过清理输入来适当防御 SQL 注入，以及用户验证系统以确保任何注册用户都是合法患者，这减少了攻击者的数量，但不应单独依赖。
这里的问题是每个音符都使用相同的加密密钥进行加密。这使得应用程序比它需要的更容易受到攻击。
请考虑以下设置：
不要将此作为完美系统的蓝图。有很多方法可以做到这一点，而且可能比这更好。但这是一个系统示例，其中仅对数据库的读写访问（例如在 SQLi 的情况下）不会立即让攻击者访问所有明文数据。
编辑：如果您希望所有医生都能阅读所有笔记，事情会变得更加不稳定。任何对整个数据库具有写入权限的人都可以将自己变成医生。所以你需要尽可能地限制对医生表的写访问！
不要给 DB 用户 Web 应用程序正在使用对该表的写入权限，并使用另一个更受限制的系统（例如，仅在某些 Intranet 上可用）来创建新医生。或者要求医生表中的每一行都经过加密签名或类似的东西。或者更好的是，阅读Lie Ryan 的好答案。
结论：这里的要点是加密需要的不仅仅是算法、消息和密钥。当您开始考虑如何处理键时，事情变得复杂，您需要高度依赖上下文的解决方案。
我认为你太沉迷于特定的攻击了。我的意思是，您担心对 notes 表具有完全 CRUD 访问权限（可能还有更多？）的 SQL 登录会尝试阅读其他医生的笔记？
是的，最好使用不同的密钥加密医生的笔记（即使它很简单：[AppWideKey]+[DoctorID]）但你的重点可能应该是，“如果 SQL 注入攻击成功，黑客将以 AppUserX 的身份登录 SQL。我怎样才能最大限度地减少 AppUserX 可以造成的损害？答案通常是：让他们使用存储过程来获取他们的数据，只让存储过程做最少的事情来完成应用程序的需求，并且不要让用户直接访问表。
您需要使用自己的密钥加密每个笔记。您应该为每个音符使用一个新的对称密钥。此对称密钥称为会话密钥。
现在问题变成了如何将会话密钥分发给接收者并且只分发给接收者。为此，您需要公钥加密。
您应该为系统中的每个参与者（患者和医生）颁发他/她自己的个人密钥对。公钥可以存储在未加密的服务器上，但私钥不应存储在未加密的服务器上。您应该使用用户的密码加密服务器上的私钥，或者应该要求用户为自己安全地存储他们的私钥。
患者可以通过生成新的会话密钥并用它加密消息，然后用医生的公钥加密会话密钥来向特定医生发送私人消息。您还可以通过针对多个公钥加密会话密钥来向多个收件人发送消息。
或者，您可能希望拥有一个证书颁发机构来检查参与者的身份（例如，通过要求有照片的 ID）并签署参与者的公钥以断言已完成身份检查，并附加断言参与者角色的签名属性（s ）。
至此，您有了点对点加密机制，这些本质上就是 S/MIME 和 PGP 方案的工作原理。
您可以在此基础上构建群组消息，以便患者和/或医生可以向大型群组发送消息（例如，患者可以将加密消息发送到足病医生组，而不允许牙科组阅读消息），无需任何人知道个人成员的身份。这称为多播加密。
您构建群组消息传递的方式是您需要创建群组密钥对。组密钥对由分发给组的所有成员的私钥和分发给需要向组发送消息的任何人的公钥组成。这仅允许成员和非成员向该组中的每个人发送消息。要发送群组消息，请使用群组的公钥加密该消息的会话密钥。
请注意，在大多数情况下，每次群组成员发生变化时（例如，有人离开群组，或有新人进入群组），您都需要创建一个新的群组密钥。