使用 std::string 拼接 SQL 是高危操作，必须用参数化查询（如 libpqxx 的 prepared_statement 或 exec_params）；所有外部输入须视为不可信，反序列化需严格校验结构与范围。
用 std::string 拼接 SQL 就是高危起点
直接把用户输入拼进 SQL 字符串，比如 "SELECT * FROM users WHERE name = '" + name + "'" ，等于给攻击者开了个数据库后门。C++ 没有像 Python 的 f-string 或 Java 的 PreparedStatement 那种语言级防护，一旦拼接发生，' OR 1=1 -- 这类输入就会原样进入查询语句。
关键不是“能不能拼”，而是“拼之前有没有剥离执行语义”。所有外部输入——HTTP 参数、文件内容、命令行参数——都必须视为不可信字节流，不能假设它只含字母数字。
- 永远不要用
std::string::operator+或std::ostringstream构造完整 SQL 查询 - 如果底层库支持预编译（如
libpqxx、MySQL Connector/C++），必须启用prepare+execute流程 - 若只能用字符串拼接（例如某些轻量封装），至少对单引号、分号、
--、/*做转义，但这是兜底手段，不推荐作为主防线
libpqxx 中防止 SQL 注入的最小安全写法
libpqxx 是 C++ 里最常用的 PostgreSQL 客户端，它原生支持参数化查询，但默认不强制开启。很多开发者调用 exec() 直接传字符串，就绕过了防护。
正确做法是使用 prepared_statement 或带占位符的 exec_params()：
立即学习“C++免费学习笔记（深入）”；
auto prep = txn.prepared("get_user")("name", pqxx::prepare::tname{"text"})("id", pqxx::prepare::tname{"int4"});
prep.exec_params("Alice", 123); // 参数类型和值分离，数据库自行绑定注意两点：
-
prepared_statement必须在事务或连接生命周期内显式注册，不能只写exec("SELECT ... ?")——libpqxx不识别?占位符，只认命名参数（如$1,$2或自定义名） - 如果用
exec_params()，参数顺序和类型必须严格匹配 SQL 中的$1,$2，否则抛pqxx::sql_error - 避免混用：不要在同一个查询里一边用
$1占位，一边手动拼接字段名或表名（这些无法参数化，需白名单校验）
反序列化漏洞的本质是类型信任错位
C++ 本身没有内置的通用反序列化机制，所以漏洞往往出在第三方库或自研协议解析逻辑里。典型场景包括：JSON 解析后直接调用 std::any_cast<int></int>、从二进制流读取长度后无条件 new char[len]、用 std::istringstream 解析未限制字段数的 CSV。
问题核心在于：你假设输入结构符合预期，但攻击者可以构造畸形数据触发越界读写、整数溢出或类型混淆。
- 对 JSON 使用
nlohmann::json时，不用at<t>()</t>而用value<t>(default)</t>，避免 key 不存在时抛异常导致流程中断 - 解析二进制协议前，先验证 magic number 和总长度字段是否在合理范围（例如长度 > 0 && length
- 所有
std::vector::resize()、std::string::reserve()、new[]的尺寸来源，必须来自可信上下文（如配置项、已校验的 header 字段），不能直接受控于网络输入
为什么 std::string 不能自动防反序列化漏洞
很多人误以为用 std::string 替代 char* 就安全了，其实不然。比如这段代码：
std::string data = recv_from_network(); nlohmann::json j = nlohmann::json::parse(data); int id = j["id"].get<int>(); // 如果 j["id"] 是字符串 "123abc"，会抛 exception
表面看没内存越界，但实际风险在别处：
- 异常未捕获会导致进程终止，构成拒绝服务（DoS）
- 如果后续逻辑依赖
id做数组索引或循环次数，而没检查是否为合法整数，可能引发未定义行为 -
nlohmann::json::parse()默认不限制嵌套深度和 key 数量，超长恶意 JSON 可耗尽内存或栈空间
真正有效的防护是：在反序列化入口做深度/大小限流，在业务层对每个字段做存在性、类型、取值范围三重校验，而不是依赖容器类兜底。
最易被忽略的一点：日志中打印反序列化后的字段时，如果直接 std::cout ，可能泄露敏感字段；更糟的是，若 <code>j 包含控制字符或超长字符串，可能污染日志系统或触发解析器 bug。处理前务必脱敏或截断。
