mysql - Base64 作为清理 Mysql 用户输入的方法

Question

我假设保证用户输入是 mysql 安全的唯一方法是使用只允许 mysql 安全输入的白名单，或者将输入编码为始终返回 mysql 安全的内容。 Base64 与 mysql_escape_string 一起对我来说就像是这种编码的候选者之一......除了用户可读性之外，还有什么理由不应该使用 Base64 进行输入卫生？它被认为是不好的做法吗？我也有一种感觉，如果问题由 mysql 处理，而不是依靠单个程序员来确保数据安全，那么所有为确保适当安全而进行的用户数据过滤本来可以更容易实现......例如通过使用单独的函数而不是基于查询的字符串，因此命令和用户输入在整个调用过程中保持分离......

Like: mysql_query("SELECT * FROM Users WHERE username=","$userinput");

或者可以使用编码:

$input = encode($_POST['UserInput']);
mysql_query("SELECT * FROM Users WHERE username='$input'");

Answer 1

不要“清理” 输入作为防止 SQL 注入(inject)的手段⁽¹⁾ - use placeholders (or proper escaping) ， 总是。始终如一。注意安全。问题已经解决了。

这个案例将是“安全的”due to the limited domain 的 base64_encode功能。 但是..

Is there any reason besides user readability that one should not use Base64 for input sanitation? Is it considered bad practice?

这是一种不好的做法，存储 base64 编码的值(这样显示的查询可能有效²)会带来一些负面的影响，因为它改变存储的信息:它破坏值的顺序，使信息不可简单搜索，需要额外的 “编码/解码”步骤，甚至消耗更多空间 - 哎哟!

因此，虽然可能存在对数据进行 base64 编码的特定情况，但这种方法不非常适合作为缓解 SQL Injection 的手段。 .

.. proper safety could have been easier to achieve if the problem was handled by mysql rather then relying on the individual programmer to ensure that the data is safe..

问题是由于通过文本协议(protocol) 访问 SQL，其中查询命令/形状和值 混合在一起。使用正确的转义技术(例如 mysql_real_escape_string)通过确保信息被转义来解决这个问题，以便 SQL 文本按预期解析 - 但是，与 base64 不同- 编码步骤它不会实际改变所提供的信息!

For example by using individual functions rather than a query based string, so that the command and user input remains separate throughout the call...

这is exactly what placeholders provide !占位符是普遍正确的方法，应予以鼓励。占位符 allow the query and values to be sent to the database separately当图书馆/数据库支持时；并通过以其他方式转义来模拟。正确使用占位符消除 SQL 注入(inject)以及用户代码将值混合到 SQL 命令文本中的需要，这也可以使查询更易于编写和维护。

为了防止“个别程序员”编写糟糕的查询，解决方案是防止临时查询分散在代码中:将数据访问操作收集到 Data Access Layer (DAL) 中(可能与 ORM 结合使用)并且仅公开相关操作，确保在 DAL 中正确使用 SQL。在较简单的项目中，DAL 也是集中管理卫生¹ 和其他验证逻辑的业务规则的合适位置。

---

¹ 更准确地说:

• 清理业务规则的值；这应该可以防止“不良信息”，例如用户名太短、包含受限字符或不符合业务要求。

• 使用占位符防止SQL Injection .这严格与将数据传输到 SQL 相关，与其中的信息无关。

---

² 而 MySQL 5.6.1 添加了 FROM_BASE64 ，这样编码可能只是在 SQL 命令文本中使用，这仍然会添加一个额外的显式解码步骤，并在使用这种编码方案时使查询复杂化。这种 base64 方法根本没有是必需的，因为已经有经过验证的技术可以防止 SQL 注入(inject)，并且没有在最初的问题中提出。