C++ const std:string& 传递给第三方 API 时的安全性

Question

我有一个第三方 API，希望我通过引用传递

std::string

。它表示正在接受

const

。这几乎没有任何意义，因为它只能将内存指针转换为非常量

char*

并修改我的字符串。

通过示例检查下面的代码。

我是否应该担心/怀疑第三方 API 要求我传递

const std::string&

（通过 const 引用）而不是

std::string

（通过值）？

他们告诉我这是因为他们想避免字符串复制，因为字符串可能很长。我是偏执还是有道理？

class Blah {

public:
    static void testBlah(const string& s) {
        char* blah = (char*) s.c_str(); // cast away from const char*
        blah[1] = 'b';
    }
};

int main() {

    cout << "!!!Hello There !!!" << endl; // prints !!!Hello World!!!

    const string s = "xxx"; // NOTE THE CONST !!!

    Blah::testBlah(s);

    cout << s << endl; // prints "xbx"

    return 0;
}

Answer 1

只需将其包装在您自己的可信类中即可：

#include <iostream>

class Blah {

public:
    static void testBlah(const std::string& s)
    {
        char* blah = (char*)s.c_str(); // cast away from const char*
        blah[1] = 'b';
    }
};

class Safe_Blah {
public:
    static void testBlah(const std::string s)
    {
        Blah::testBlah(s);
    }
};

int main()
{

    std::cout << "!!!Hello There !!!" << std::endl; // prints !!!Hello World!!!

    const std::string s = "xxx"; // NOTE THE CONST !!!

    //Blah::testBlah(s);
    Safe_Blah::testBlah(s);

    std::cout << s.c_str() << std::endl; // now prints "xxx"

    return 0;
}

Answer 2

接受对象

const&

的 API 承诺不修改该对象。 是的，虽然图书馆可能是邪恶的并且无论如何都会修改它，但这样做就会违背承诺。 如果您传递给它的对象被定义为

const

，则修改它将是 未定义行为。 从库开发人员的角度来看，这将非常糟糕。 基本上，库开发人员会邀请 Chutulhu 来以任意、随机、未指定和不可预测的方式破坏他们的用户应用程序。

如果不信任你的图书馆，你就输了。 就控制您调用的库的攻击者的安全性而言，C++ API 在任何方面都不是“安全”的。 当您调用库中的函数时，您将执行控制权传递给该库。 然后，该库将有权读取和写入应用程序的所有内存，并且如果它选择的话，可以用它自己的东西替换整个内存。 因此，如果您担心图书馆在您背后做坏事，那您就运气不好了。

Answer 3

当第三方 API 请求 const std::string& 时，意味着承诺不修改该字符串。 const 的使用可以在语言级别保证 API 应该尊重所传递对象的不变性。然而，正如您所发现的，这并不是一个万无一失的安全措施。虽然 API 设计者可能有最好的意图，但使用 const 并不能阻止他们放弃常量并修改字符串，从而可能导致未定义的行为。

在C++中，当const被丢弃并且原始对象确实是const时，任何修改都是未定义的行为。这意味着不仅在 API 设计方面违反了合同，而且还可能导致崩溃、数据损坏或其他不稳定的行为。

安全视角： 从安全角度来看，通过 API 传递敏感数据始终需要与库建立信任关系。如果第三方库的源代码可用，那么明智的做法是检查它是否存在任何此类强制转换或其他潜在的安全漏洞。如果来源不可用，则信任该库的决定应取决于其声誉、其提供的保证以及安全漏洞的潜在影响。

实际步骤：

审查和审计：尽可能审查第三方代码，尤其是对于安全关键型应用程序。 最大限度地降低风险：如果没有必要，请避免直接传递敏感或关键数据。 对敏感数据使用副本：正如建议的，在将数据传递到 API 之前制作数据副本可以减轻一些风险，但不是全部风险（例如，针对内存扫描攻击）。 如果您正在开发安全性至关重要的应用程序（例如 GBWhatsApp 等消息传递应用程序），那么了解这些微妙之处就变得至关重要。有关安全应用程序开发和 GBWhatsApp 等特定案例研究的更多见解，您可能会发现这篇文章很有帮助：探索安全消息应用程序实践。