Perl 的污染模式有用吗？
perl -T
你用它吗？它可以帮助您找到 Perl 脚本中的安全漏洞吗？
perl -T
Do you use it? Does it help you finding security holes in your Perl scripts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
更重要的是:)它可以在您的安全问题成为问题之前阻止。当然，这不是安全银弹...我们曾经在任何外部公开的脚本（即任何 mod_perl 应用程序）中使用它（几年前，当我参与 Perl 项目时），我们发现它非常有用，并且将此作为我们的政策。它做了一些检查，而且很方便..（任何事情都可以使事情自动化）
Perl 安全 - perlsec也强烈推荐：
More than that :) it stops your security issues before they become one. It is not a security silver bullet of course... we used to use it (a few years back when I was involved in Perl projects) in any script that was exposed externally (i.e. any mod_perl app) and we found it very useful and made it our policy. It does a few checks and it is handy.. (anything makes things automated)
Perl Security - perlsec recommends it strongly too:
绝对是！
Most definitely!
掌握 Perl 的“安全编程技术”一章几乎完全致力于污点检查以及如何使用它。
许多人会告诉您它可以保护您，但他们巧妙地撒了谎。它是一个开发人员工具，可以帮助您找到代码中一些（仅一些）需要小心的地方。它不会解决您所有的安全问题。
The "Secure Programming Techniques" chapter of Mastering Perl is almost completely devoted to taint checking and how you should use it.
Many people will tell you it protects you, but they subtly lie about that. It's a developer tool that helps you find some (only some) spots in your code where you need to be careful. It's not going to solve all of your security problems.
我认为当开发每个人都熟悉的新代码时，污点模式效果最好。
如果你有别人写得不好的代码，并且你在污染模式下运行它——perl 将死掉，而不是执行污染规则中“不安全”的操作。
在污点模式 Perl 中，一些漏洞被修补，但不是全部。 system("$unfiltered_user_input") 将会死掉，但 Perl 仍然可以将 $unfiltered_user_input 数据写入具有固定名称的文件中（因为打印受污染的数据被认为是“安全的”），然后使用 system() 执行该文件。但没有什么可以检验一切。
在旧版应用程序上使用它需要权衡。当 Perl 发现对受污染的数据进行不安全操作时，它就会终止——这意味着必须有人介入并决定净化数据意味着什么，需要什么正则表达式，然后应用程序才能再次可靠。
有些人更喜欢不安全、可靠、低成本（目前），而不是安全、破碎、需要找到开发人员。从长远来看这并不是好事……但这并不罕见。
I think taint mode would work best when new code is being developed that everyone is familiar with.
If you have someone else's code that is poorly written, and you run it in Taint mode -- perl will die rather than perform what by the tainting rules are 'unsafe' operations.
In taint mode perl some holes are patched but not all. system("$unfiltered_user_input") will die but Perl could still write $unfiltered_user_input data to a file with a fixed name (because printing tainted data is considered 'safe') and then execute that file with system(). But nothing can check everything.
There's a tradeoff there for using it on legacy apps. When Perl finds an unsafe operation on tainted data it will die -- which means someone must go in and decide what it means to untaint the data, what regexp are needed, before the application will be reliable again.
Some people would prefer insecure, reliable, low cost (for now) to -- secure, broken, need to find the developers. Not that thats good in the long run... but it is not unusual.
是的，出于上述所有原因，污点模式很有用。
您可能不会考虑污染数据的一个地方是与数据库交互时。幸运的是，DBI 支持阻止受污染的数据进入您的数据库，并且它将来自数据库的数据视为已受污染的数据，以便您无法对其执行任何不安全的操作。您必须为此专门打开选项；默认情况下它们是关闭的。有关详细信息，请参阅DBI 文档。
Yes, taint mode is useful for all the reasons mentioned above.
One place that you may not consider tainted data is when interacting with a database. Fortunately, DBI has support for stopping tainted data from getting into your database, and it treats data coming from your database as being tainted so that you can't do anything unsafe with it. You have to specifically turn on the options for this; they're off by default. See the DBI docs for more.
哦，天啊，不。污点模式应该在 15-20 年前就从 Perl 中取消。它不会阻止任何事情，因为您无法验证某些命令的响应。它让人们相信他们是安全的，但他们所做的只是
/(.*)/。它几乎破坏了 Windows 上的所有内容（甚至无法获取准确的临时目录）。不要使用污点Oh, gods, no. Taint mode should have been yanked from Perl 15-20 years ago. It prevents nothing as you cannot possibly validate the response of certain commands. It gets people to believe they're secure, but all they do is
/(.*)/. It breaks nearly everything on Windows (even being able to get an accurate temporary directory). DO NOT USE TAINT