我已经接管了支持时间和费用输入系统的工作。阿帕奇的 CGI。 CGI 程序是用 bash 编写的 :) 我将在其中添加一些功能并将其公开给更多用户，但在此之前想了解其他需要查看的内容 - first 在安全性、漏洞、CGI 陷阱等方面。
用户并不多，但该应用程序的性能非常好，并且在 bash 中始终如一地大量编写。页面看起来像 ASP/JSP/PHP 格式，大量使用了这里的文档。参数从单独的 C 程序中推断出来，会话信息存储在 DB (MySQL) 中，并且 SQL 参数/注入被正确转义。
我很伤心，好像这个堆栈真的需要被剥离吗？ 在大部分直接用 bash 编写的整个应用程序中需要注意什么？
【问题讨论】：
标签： linux security bash shell cgi
像了解系统中所有代码的恶意用户一样思考（代码中的模糊性无法防御！-）：您将如何颠覆系统？
您能否向其提供恶意标头、URL 或查询参数，从而使您恶意注入的文本最终被系统吞噬并用于攻击文件系统、数据库等？ SQL 注入是一种攻击途径，但可能还有其他途径，除非系统对处理从用户那里收到的所有内容非常偏执——不要使用它（没有非常仔细的检查和清理！）来形成文件名、系统命令和以此类推，不要存储它以供以后执行，等等。
没有什么真正特定于 bash 或特定于 cgi 的东西——只是你需要确保安全的常见或花园形式的偏执狂（甚至没有像 perl 的“污点”概念这样的拐杖——这并不能完全解决一切[[当然远非如此]]，但它确实为您节省了一些的努力；-)。
【讨论】：
您的应用的曝光率如何？它是在 Internet 上还是只能通过 Intranet 获得？
应用的数据库是否包含任何敏感信息？
旧应用最常见的问题是 SQL 注入。请记住测试通过表单发送到应用程序的每个字段。我认为这是您在 bash 应用程序中应该注意的第一件事——传入的数据直接在 SQL 语句中使用，而无需适当的转义/引用。
如果您愿意，您也可以担心 XSS 和会话劫持...
应用的可维护性如何？代码清晰吗？
【讨论】：