CGI 脚本中的纯文本密码是否存在安全漏洞？
我读到，您的 Web 服务器可能会出现问题，这可能会导致 PHP 脚本在 Web 浏览器中显示为纯文本文件；因此，我已将大部分 PHP 脚本移至 Web 根目录之外的目录中。现在我一直想知道我的 cgi-bin 中的 CGI 脚本是否也会发生同样的情况。
我主要关心的是一个脚本，其中包含我的 MySQL 数据库的用户名和密码。如果这是一个可能的安全漏洞（至少就数据库内容而言），是否有一种方法可以将敏感数据放在不同的位置并从那里获取它（例如将其保存在不同目录的文件中并读取例如，来自该文件）？顺便说一句，我的脚本是用 Perl 编写的。
I've read that things can go wrong with your web server which may lead to display of PHP scripts as plain text files in a web browser; consequently I've moved most of my PHP scripts to a directory outside the web root. Now I've been wondering whether the same could happen to the CGI scripts in my cgi-bin.
My main concern is one script which contains a user name and password for my MySQL database. If this is a possible security hole (at least as far as the database content is concerned), is there a way of putting sensitive data in a different location and getting it from there (like saving it in a file in a different directory and reading it from that file, for example)? My scripts are written in Perl btw.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您已经得到了比我能提供的更好的答案，但请注意：
将密码存储为纯文本是非常糟糕的形式，句号。
同样，覆盖或删除文件而无需覆盖或删除文件也是非常糟糕的形式。请求许可。如果你这样做，它最终会咬你或你的客户的屁股。
You've already gotten better answers than I can provide, but as a note:
It's very bad form to store passwords as plaintext, period.
In the same way it's very bad form to overwrite or delete files without asking permission. If you do it, it will bite you or your client in the butt eventually.
是的。如果出现问题导致程序被服务而不是被执行，那么它们的任何内容都将被暴露。这与 PHP 的问题完全相同（除了考虑到 cgi-bin 目录通常配置的方式（即别名为 Web 根目录之外的目录），解决问题稍微困难一些。发生）。
是的。正是如此，只需确保该目录位于 webroot 之外即可。
为了提高安全性，请确保数据库仅接受来自需要访问它的最少主机集的连接凭据。例如，如果数据库与 Web 服务器位于同一服务器上，则仅让凭据适用于 localhost。在这种情况下，使数据库仅侦听本地主机网络接口也是一个好主意。
我会考虑使用 Config::* 模块之一来实现此目的。
Yes. If something goes wrong that causes the programs to be served instead of executed, then any of their content will be exposed. It is exactly the same issue as with PHP (except that given the way that cgi-bin directories are usually configured (i.e. aliased to a directory outside the web root), it is slightly harder for the problems to occur).
Yes. Exactly that, just make sure the directory is outside the webroot.
For additional security, make sure the database only accepts the credentials for connections from the minimum set of hosts that need to access it. e.g. if the database is on the same server as the web server, then only let the credentials work for localhost. Causing the database to only listen on the localhost network interface would also be a good idea in that case.
I'd look at using one of the Config::* modules for this.
值得一提的一个问题是共享托管所特有的。
如果您位于与其他用户共享的主机上，则可能无法向他们隐藏密码。
这取决于操作系统和网络服务器的配置详细信息。
例如，在 Linux 上有一个 Apache 配置是很常见的，在该配置上，用户提供网站以使文件对网络服务器用户可读或可写的唯一方法是使它们对所有人可读/可写用户。
您可能相信所有这些用户自己不会滥用此功能，但如果其中一个网站存在允许入侵者查看完整文件系统的漏洞，则入侵者可以在所有其他网站上利用该漏洞。
有针对此的对策，但它们使用户的事情变得复杂，因此许多托管服务商没有实施它们。
One concern worth mentioning is specific to shared hosting.
If you're on a host shared with other users, it may be impossible to hide the password from them.
This depends on configuration details for the OS and the webserver.
For instance, it is common to have an Apache configuration on Linux on which the only way for a user offering a website to make files readable or writable to the webserver user is to make them readable/writable to all users.
You may trust all of these users not to abuse this themselves, but if one of these websites has a vulnerability that allows intruders to view the full file system, the intruder can then exploit that on all other websites.
There are countermeasures against this, but they complicate things for the users, so many hosters don't implement them.
如果可以避免的话，在脚本中对密码进行硬编码绝对不是一个好主意。幸运的是，Postgres 和 MySQL 都支持从文件加载数据库凭据。对于 Postgres，您使用 ~/.pgpass，对于 MySQL，我相信它是 ~/.my.cnf。无论哪种情况，您都需要调整权限，以便只有运行脚本的用户才有权读取该文件。这种方法的优点是您不必编写代码来读取文件 - DB 客户端库会自动执行此操作。
It's definitely not a good idea to hardcode a password in a script if you can avoid it. Fortunately both Postgres and MySQL support loading DB credentials from a file. For Postgres you use ~/.pgpass and for MySQL I believe it's ~/.my.cnf. In either case you would adjust the permissions so that only the user running the script has permission to read the file. The advantage of this approach is that you don't have to write the code to read the file - the DB client library does it automatically.
这绝对是一个安全问题。您应该将加密的密码存储在单独的文件中，并确保只有您的应用程序可以访问它。
It is definitely a security concern. You should store the password encrypted in a separate file and make sure that only your app has access to it.
如果您使用配置为 cgi-bin 的目录，则除了 Apache 配置错误之外，无法显示文件。如果您在 cgi-bin 目录之外但在站点根目录内使用 Perl 程序，则可能会发生这种情况。
另外，您可以将数据库配置为仅接受来自本地套接字的连接，因此知道数据库密码是没有用的。
If you use directory configured as cgi-bin, there is no way for file to be shown except error with Apache configuration. If you use Perl programs outside cgi-bin directories but inside site root, it may happen.
Also, you may configure DB to accept connections only from local socket, so knowing DB password would be useless.