如何提高 Delphi 中的内存安全性？

Question

Delphi 中可以“擦除”字符串吗？ 让我解释一下：

我正在编写一个应用程序，其中将包含一个 DLL 来授权用户。 它将加密文件读入 XML DOM，使用其中的信息，然后释放 DOM。

很明显，未加密的 XML 仍然位于 DLL 的内存中，因此容易受到检查。 现在，我不会过度保护这一点 - 用户可以创建另一个 DLL - 但我想采取一个基本步骤来防止用户名在内存中停留很长时间。 然而，由于引用，我认为无论如何我都无法轻易擦除记忆。 如果我遍历 DOM（这是一个 TNativeXML 类）并找到每个字符串实例，然后将其变成类似“aaaaa”的内容，那么它实际上不会将新字符串指针分配给 DOM 引用，然后保留旧字符串内存中有等待重新分配的地方吗？ 有没有办法确保我正在删除唯一的原始副本？

或者 D2007 中是否有一种方法告诉它从堆中擦除所有未使用的内存？ 所以我可以释放 DOM，然后告诉它擦除。

或者我应该继续我的下一个任务并忘记它，因为它真的不值得打扰。

Answer 1

我认为这不值得打扰，因为如果用户可以使用 DLL 读取进程的内存，那么同一用户也可以在任何给定时间点停止执行。 在擦除内存之前停止执行仍将允许用户完全访问未加密的数据。

IMO 任何足够感兴趣并且能够执行您所描述的操作的用户都不会因您的 DLL 擦除内存而造成严重不便。

Answer 2

关于此问题有两个一般要点：

首先，这是“如果您必须询问，您可能不应该这样做”的领域之一。 请不要误解这一点； 我的意思并不是对你的编程技能不尊重。 只是编写安全、加密功能强大的软件要么是专家，要么不是。 就像懂得“一点点空手道”比完全不懂空手道要危险得多。 有许多第三方工具可用于在 Delphi 中编写安全软件，并提供专家支持； 我强烈鼓励任何对 Windows 中的加密服务、加密的数学基础以及击败侧通道攻击经验不深的人使用它们，而不是尝试“自己动手”。

要回答您的具体问题：Windows API 有许多有用的函数，例如 CryptProtectMemory。 然而，如果您加密了内存，但系统其他地方有漏洞，或者暴露了侧通道，这会带来一种错误的安全感。 这就像在门上锁上锁但让窗户开着一样。

Answer 3

像这样的事情怎么样？

procedure WipeString(const str: String);
var
  i:Integer;
  iSize:Integer;
  pData:PChar;

begin
    iSize := Length(str);
    pData := PChar(str);

    for i := 0 to 7 do
    begin
      ZeroMemory(pData, iSize);
      FillMemory(pData, iSize, $FF); // 1111 1111
      FillMemory(pData, iSize, $AA); // 1010 1010
      FillMemory(pData, iSize, $55); // 0101 0101
      ZeroMemory(pData, iSize);
    end;
end;

Answer 4

DLL 不拥有分配的内存，但进程拥有。 一旦进程终止，无论 DLL 是否挂起（因为它正在被另一个进程使用），由您的特定进程分配的内存都将被丢弃。

Answer 5

如何将文件解密为流，使用 SAX 处理器而不是 XML DOM 进行验证，然后在释放之前覆盖解密的流？

Answer 6

如果您在完全调试模式下使用 FastMM 内存管理器，则可以在释放内存时强制它覆盖内存。

通常该行为用于检测野指针，但它也可以用于您想要的用途。

另一方面，请确保您理解 Craig Stuntz 所写的内容：不要自己编写这些身份验证和授权内容，尽可能使用底层操作系统。

顺便说一句：Hallvard Vassbotn 写了一篇关于 FastMM 的精彩博客：
http://hallvards.blogspot.com/2007/ 05/use-full-fastmm-consider-donating.html

问候，

杰罗恩·普鲁默斯

Answer 7

请小心尝试将字符串视为指针的函数，并尝试使用 FillChar 或 ZeroMemory 擦除字符串内容。

• 这都是错误的（字符串是共享的；你正在欺骗当前正在使用该字符串的其他人）
• 并且可能导致访问冲突（如果该字符串碰巧是一个常量，那么它位于只读数据页上进程地址空间；并且尝试写入它是访问冲突

）

procedure BurnString(var s: UnicodeString);
begin
    {
        If the string is actually constant (reference count of -1), then any attempt to burn it will be
        an access violation; as the memory is sitting in a read-only data page.

        But Delphi provides no supported way to get the reference count of a string.

        It's also an issue if someone else is currently using the string (i.e. Reference Count > 1).
        If the string were only referenced by the caller (with a reference count of 1), then
        our function here, which received the string through a var reference would also have the string with
        a reference count of one.

        Either way, we can only burn the string if there's no other reference.

        The use of UniqueString, while counter-intuitiave, is the best approach.
        If you pass an unencrypted password to BurnString as a var parameter, and there were another reference,
        the string would still contain the password on exit. You can argue that what's the point of making a *copy*
        of a string only to burn the copy. Two things:

            - if you're debugging it, the string you passed will now be burned (i.e. your local variable will be empty)
            - most of the time the RefCount will be 1. When RefCount is one, UniqueString does nothing, so we *are* burning
                the only string
    }
    if Length(s) > 0 then
    begin
        System.UniqueString(s); //ensure the passed in string has a reference count of one
        ZeroMemory(Pointer(s), System.Length(s)*SizeOf(WideChar));

        {
            By not calling UniqueString, we only save on a memory allocation and wipe if RefCnt <> 1
            It's an unsafe micro-optimization because we're using undocumented offsets to reference counts.

            And i'm really uncomfortable using it because it really is undocumented.
            It is absolutely a given that it won't change. And we'd have stopping using Delphi long before
            it changes. But i just can't do it.
        }
        //if PLongInt(PByte(S) - 8)^ = 1 then //RefCnt=1
        //  ZeroMemory(Pointer(s), System.Length(s)*SizeOf(WideChar));

        s := ''; //We want the callee to see their passed string come back as empty (even if it was shared with other variables)
    end;
end;

获得 UnicodeString 版本后，您可以创建 AnsiString 和 WideString 版本：

procedure BurnString(var s: AnsiString); overload;
begin
    if Length(s) > 0 then
    begin
        System.UniqueString(s);
        ZeroMemory(Pointer(s), System.Length(s)*SizeOf(AnsiChar));

        //if PLongInt(PByte(S) - 8)^ = 1 then //RefCount=1
        //  ZeroMemory(Pointer(s), System.Length(s)*SizeOf(AnsiChar));

        s := '';
    end;
end;

procedure BurnString(var s: WideString);
begin
    //WideStrings (i.e. COM BSTRs) are not reference counted, but they are modifiable
    if Length(s) > 0 then
    begin
        ZeroMemory(Pointer(s), System.Length(s)*SizeOf(WideChar));

        //if PLongInt(PByte(S) - 8)^ = 1 then //RefCount=1
        //  ZeroMemory(Pointer(s), System.Length(s)*SizeOf(AnsiChar));

        s := '';
    end;
end;

Answer 8

很混乱，但你可以记下你在堆中填充敏感数据时使用的堆大小，然后在释放该堆时执行 GetMem 为你分配一个跨越（例如）200% 的大块。 对该块进行填充，并假设任何碎片对于检查者来说都没有多大用处。
布里

Answer 9

如何将密码保留为 XML 中的哈希值，并通过将输入密码的哈希值与 XML 中的哈希密码进行比较来进行验证。

编辑：您可以仅在最后一刻对所有敏感数据进行加密和解密。

Answer 10

是否可以将解密的 XML 加载到字符或字节数组而不是字符串中？ 那么就没有写时复制处理，因此您可以在释放之前用#0回填内存？

将 char 数组分配给字符串时要小心，因为 Delphi 在这里有一些智能处理，以与传统的打包 char 数组 [1..x] 兼容。

另外，你可以使用 ShortString 吗？

Answer 11

如果您使用 XML（即使是加密的）来存储密码，您的用户就会面临风险。 更好的方法是存储密码的哈希值，然后将哈希值与输入的密码进行比较。 这种方法的优点是，即使知道哈希值，您也不知道生成哈希值的密码。 添加强力标识符（计算无效密码尝试次数，并在达到一定次数后锁定帐户）将进一步提高安全性。

您可以使用多种方法来创建字符串的哈希值。 我相信，一个好的起点是查看涡轮动力开源项目“LockBox”它有几个创建单向哈希键的示例。

编辑

但是知道哈希值（如果是一种方式）有什么帮助呢？ 如果您真的很偏执，您可以通过只有您知道的可预测的内容来修改哈希值......例如，使用特定种子值加上日期的随机数。 然后，您可以在 xml 中仅存储足够的哈希值，以便可以将其用作比较的起点。 伪随机数生成器的好处是，它们总是在给定相同种子的情况下生成相同系列的“随机”数。