数据库访问最佳实践指南 [英] Guidance on Database Access best practices
问题描述
我最近在我的工作场所继承了对 Web 应用程序(主要是 PHP，但也有大量 JavaScript)的控制权.我的首要任务之一是确保应用程序是安全的.不幸的是，应用程序中的数据库访问目前是通过自定义类完成的，而不是 MYSQLi 或 PDO.
I have recently inherited control of a web application (primarily PHP, but also a good chunk of JavaScript) at my workplace. One of my top priorities is to make sure that the application is secure. Unfortunately, database access in the application is currently done through a custom class, not MYSQLi or PDO.
我需要一段时间才能完全过渡到 PDO，但与此同时，我想尽我所能使应用程序尽可能安全.目前所有输入都通过 mysql_real_escape_string() 传递，我确保应用程序和数据库都以 UTF8 编码.
It will take me a while before I transition completely to PDO but in the meanwhile, I want to do all I can to make the application as secure as possible.
Currently all input is passed through mysql_real_escape_string() and I have made sure to have the application and the database all encoded in UTF8.
在我可以完全切换到 PDO 之前，我还能做些什么或我应该做些什么(最佳实践)来确保应用程序的安全?
Is there anything else I can do or I should do (best practices) to make the application secure BEFORE I can completely switch over to PDO?
感谢您的帮助:)
推荐答案
您可以做的一件事是将其部署到 Intranet(如果您有).您可能会惊讶于您网站的服务器被神秘手指扫描的频率如此之高，而另一端的南美大学则是异国情调.也许吧.
One thing you could do is hive it off to an intranet (if you have one). You may be amazed how frequently your site's server is getting scanned by mystery fingers with exotic South American university's on the other end. Maybe.
仔细检查并确保每个输入都经过验证并且完全符合您的期望.使用不同的 FILTER_ 努力学习 filter_var().mysql_* 本身并不是邪恶的，它只是过时了，而 *_real_escape_string() 与不是有关安全性，而是关于查询完整性.
Go through and make sure every input is validated and exactly what you expect. Lean hard on filter_var() with the different FILTER_s. mysql_* itself is not evil, it's just old, and *_real_escape_string() is not about security, it's about query integrity.
我已经知道这样做了:
switch ($_GET['color']) {
case 'green':
$color = 'green';
break;
case 'blue':
$color = 'blue';
break;
case 'yellow':
$color = 'yellow';
break;
default:
$color = NULL;
}
那是人为的，但你明白了.毫无疑问地提供您收到的数据，并在可能的情况下使用您的数据.保持简单，但不要简单化，不要认为像 PDO 查询这样的交钥匙"方法真的可以保护您网站的资产(或您的工作).
That's contrived, but you get the drift. Give the data you're receiving no benefit of any doubt, and when and where possible, use your data. Keep things simple, but not simplistic, and don't think "turnkey" approaches like PDO'ing your queries really protects your site's assets (or your job).
如果我必须验证字段名称，您打赌我正在做类似的事情:
If I have to validate field names, you bet I'm doing something like:
$field = preg_replace('/[^a-z_]/', $_POST['field']);
对疯狂的正则表达式感到疯狂......我尽量保持简单和直接.否则它们会让我发痒.
Getting crazy with insane Regular Expressions... I try to keep it simple and really straight forward. They make me itchy otherwise.
PDO 和 MYSQLI 是现代且优秀的工具，但它们不是安全问题的替代品或灵丹妙药.核心安全原则和对细节的仔细关注是您完成这项工作的方式.例如，如果您只是不明白为什么某件事被认为是坏主意"，请研究它，直到您明白为止.eval()，在坏人的手中，可以做坏事，就像一把刀.但是很容易得到".尝试会话固定或 XRSF/CSRF hacks.这是一场永无止境的奥德赛.
PDO and MYSQLI are modern and good tools, but they are not a replacement nor a panacea for security concerns. Core security principles and careful attention to detail is how you get that job done. For instance, if you just can't figure out why something is considered a "bad idea", research it until you get it. eval(), in the wrong hands, is capable of bad things, just like a knife. But it's easy to "get". Try session fixation, or XRSF/CSRF hacks. It's a neverending odyssey.
熟悉您的(新)代码，开始并继续研究，在任何地方实施严格的验证，不信任用户领域，并尊重增强安全性永无止境.
Get familiar with your (new) code, start and keep doing research, implement strict validation everywhere, trust nothing from userland, and respect that enhancing security never ends.
如果可以，请供应商定期对您的网站进行安全扫描.每月.我认为 Nessus 每年收费 1200 美元.这不是万无一失的，但比被任何体面的渗透测试人员在 20 分钟内发现的一些糟糕的低悬问题pWnd 更好.
If you can, pay a vendor to security scan your site regularly. Monthly. I think Nessus charges $1200/yr. It's not foolproof, but better than being pWnd by some crummy low hanging issue any decent penetration tester could uncover in twenty minutes.
对吗?
此外，不要过度关注此代码的想象问题，而忽略其他关键问题.如果您继承的这段代码运行的是 PHP 4.1，则有一个古老的 phpMyAdmin 向世界开放(psst，使用弱密码)，而服务器管理被忽略或实践不力，您就会遇到问题.
Also, don't micro-focus on imagined problems with this code and ignore other critical concerns. If this code you're inheriting is running PHP 4.1, there's an ancient phpMyAdmin open to the world (psst, with weak passwords), and the server administration was ignored or practiced ineptly, you got problems.
如果您有这样的服务器，谁需要 SQL 注入问题.如果您不了解 ssh 和隧道技术，您应该这样做.
Who needs a SQL injection concern if you got a server like that. If you don't know ssh and tunneling, you should.
保护(通过关闭和监控)端口，维护软件包的升级，使用 SUHOSIN(虽然它不再更新?)，可能会研究诸如反向代理(Varnish)和/或其他工具之类的东西像 Fail2ban 一样管理对基础设施的威胁.不要依赖安全模式或魔术引号等技术"，除非代码依赖它存在.
Secure (by closing and monitoring) ports, maintain upgrades on your software package(s), use SUHOSIN (although is it no longer being updated?), possibly look into things like reverse proxies (Varnish) and/or other tools like Fail2ban to manage threats to the infrastructure. Don't rely on "techniques" like safe mode or magic quotes, unless the code relies on it being there.
如果您正在与老维护者交谈，请询问他担心什么.我刚刚翻了一个我维护了八年的网站.我们进行了looong 谈话...
If you're on speaking terms with the old maintainer, ask him what he worried about. I just turned over a site I maintained over eight years. We had a looong talk...
- http://www.hardened-php.net/suhosin/(是吗?还在维护?)
- http://sectools.org/
- http://h-online.com/security
- http://security.stackexchange.com
- http://www.schneier.com/
- http://www.hardened-php.net/suhosin/ (Is it still maintained?)
- http://sectools.org/
- http://h-online.com/security
- http://security.stackexchange.com
- http://www.schneier.com/
这篇关于数据库访问最佳实践指南的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
