我最近继承了我工作场所的 Web 应用程序(主要是 PHP，但也有很大一部分 JavaScript)的控制权。我的首要任务之一是确保应用程序的安全。不幸的是，应用程序中的数据库访问当前是通过自定义类完成的，而不是 MYSQLi 或 PDO。
我需要一段时间才能完全过渡到 PDO，但与此同时，我想尽我所能使应用程序尽可能安全。
目前，所有输入都通过 mysql_real_escape_string() 传递，并且我已确保应用程序和数据库全部以 UTF8 编码。
在完全切换到 PDO 之前，我还能做些什么或应该做些什么(最佳实践)来确保应用程序的安全吗？
感谢您的所有帮助:)
最佳答案
您可以做的一件事是将其分离到内部网(如果您有的话)。您可能会惊讶于您网站的服务器被神秘手指扫描的频率，另一端是异国情调的南美大学。也许吧。
仔细检查并确保每个输入都经过验证并且完全符合您的期望。重点关注具有不同 FILTER_ 的 filter_var()。 mysql_* 本身并不是邪恶的，它只是旧了，而 *_real_escape_string() 与安全无关，它与查询完整性有关。
众所周知我会这样做:
switch ($_GET['color']) {
case 'green':
$color = 'green';
break;
case 'blue':
$color = 'blue';
break;
case 'yellow':
$color = 'yellow';
break;
default:
$color = NULL;
}
这是做作的，但你明白了。毫无疑问地提供您收到的数据，并在可能的时间和地点使用您的数据。保持事情简单，但不要简单化，并且不要认为像 PDO 查询这样的“交 key ”方法真的可以保护您网站的 Assets (或您的工作)。
如果我必须验证字段名称，你敢打赌我会做类似的事情:
$field = preg_replace('/[^a-z_]/', $_POST['field']);
对疯狂的正则表达式感到疯狂......我试图保持简单和直接。否则它们会让我发痒。
PDO 和 MYSQLI 是现代且优秀的工具，但它们并不是安全问题的替代品，也不是解决安全问题的 Elixir 。核心安全原则和对细节的仔细关注是完成这项工作的方法。例如，如果您只是无法弄清楚为什么某件事被认为是“坏主意”，请研究它直到您明白为止。 eval() 如果落入错误的人手中，就会像一把刀一样做出坏事。但“得到”却很容易。尝试 session 固定或 XRSF/CSRF 黑客。这是一场永无休止的冒险之旅。
熟悉您的(新)代码，开始并继续进行研究，在各处实现严格的验证，不信任来自用户的任何内容，并尊重安全性的增强永无止境。
如果可以的话，向 vendor 付费以定期对您的网站进行安全扫描。每月。我认为 Nessus 的收费为 1200 美元/年。这并不是万无一失的，但比被一些糟糕的低悬问题所困扰要好，任何像样的渗透测试人员都可以在二十分钟内发现这些问题。
对吗？
<小时/>此外，不要过于关注此代码的想象问题而忽略其他关键问题。如果您继承的这段代码运行的是 PHP 4.1，有一个古老的 phpMyAdmin 向世界开放(psst，密码较弱)，并且服务器管理被忽略或执行不当，您就会遇到问题。
如果你有这样的服务器，谁还需要担心 SQL 注入(inject)呢。如果您不了解 ssh 和隧道，您应该了解。
保护(通过关闭和监控)端口，维护软件包的升级，使用 SUHOSIN(尽管它不再更新？)，可能会研究反向代理(Varnish)和/或其他工具等例如 Fail2ban 来管理对基础设施的威胁。不要依赖安全模式或魔术引号等“技术”，除非代码依赖它的存在。
<小时/>如果您与旧维护者关系融洽，请询问他担心什么。我刚刚移交了一个我维护了八年多的网站。我们进行了漫长谈话...
关于php - 数据库访问最佳实践指南，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15286967/