Web应用程序安全性中的陈词滥调之一就是“如果您知道自己在做什么，那么选择哪个框架无关紧要。”根据我的经验，在网络安全行业的职业生涯背后，这个概念是完全错误的！
优秀的开发人员始终开发安全的应用
我们可以尝试编写一个安全的Web应用程序，只要花费足够的时间和精力，来实现自己的会话处理，并尽可能使其安全。但这听起来很费劲，对吧？
当我说有人可以在PHP中实现自己的CSRF保护时，这听起来很正常，因为这正是每个人都在做的事情！但是，这仍然是非常不明智的。同样，安全会话实现应该是框架的责任之一，开发人员不必实施安全的CSRF保护实施。
语言的安全性，框架的安全性
没有完美的框架！每个流行的框架都有漏洞，所有流行的Web应用程序也是如此。但是有些应用程序具有很好的安全跟踪记录，这通常来自于框架。ApacheStruts的OGNL表达式注入、PHP的各种低级漏洞问题以及Perl的严重缺陷都是这些漏洞的好例子。
PHP完美地说明了这一点。语言本身有很多漏洞，例如Zend_Hash_Del_Key_Or_Index漏洞或PHP的月份漏洞。想一想，即使开发人员知道如何避免PHP的无数陷阱，如果PHP本身存在漏洞，应用程序仍然会受到攻击。这没有涉及到任何设计问题，如PHP类型或对象注入。
如果您将目录设置为受保护的且由于攻击者使用不同的HTTP方法而攻破您的框架，那么这不是开发人员的错，那就是框架的错误。这就是框架重要的原因，因为即使您构建了最安全的应用程序，当您的框架易受攻击时，您的应用程序也是如此。
关于框架的这些问题：
框架是否正确处理unicode字符？功能是否会意外受到空字符的影响？当在cookie中发送一个特殊字符时，它是否会因敏感数据而溢出？
所有这些都是有关框架的问题-而不是您的应用程序带来的。选择具有良好安全跟踪记录的框架，否则，您必须阅读应用程序的源代码和框架的源代码，包括其所有公开的API端点、您调用的内部函数以及每次用户发出请求时框架调用的函数（例如，路由）。
框架特定问题
您不会在ASP.NET中看到很多RFI（远程文件包含），因为没有简单的方法可以引入它们。您不会在ASP.NET应用程序中看到许多代码执行问题（例如eval（）），因为没有简单的方法可以做到这一点。但是在过去的ASP中则会遇到这个问题。在PHP应用程序中，甚至preg_replace也能够使用/e修饰符来评估代码。是的，实际中也存在这些问题，例如PHPBB论坛很容易受到这个漏洞的影响。
默认安全性
有一些框架可以从“默认安全性”角度来设计某些功能。例如，在ASP.NET中看到HTTP头部注入（CRLF/HTTP响应分裂）问题是非常罕见的。那是因为默认情况下所有相关的.NET函数都会拒绝接受新行。作为开发人员，您真的必须走出自己的道路才能引入此漏洞。但是，在引入漏洞时，您会惊讶于一些开发人员的创造性。一些开发人员不可抗拒地要求引入以前认为不可能的漏洞，即使是最好的框架也无法修复。对不起，但这是事实。
框架开发人员自己甚至容易出现这种现象。最好的例子是PHP中的MagicQuotes，无数的应用程序很容易受到影响，这是多么可怕的事情。
内置安全功能
我认为每个体面的开发人员都知道使用自己的加密算法是愚蠢的，但不知何故，开发人员可以推出自己的CSRF保护、SQL注入过滤器、XSS保护库等。
以下是需要了解的框架的问题：
它是否支持参数化SQL查询（预准备语句）？它是否提供了一种分离数据和HTML并根据输出位置执行所需编码的方法，以防止跨站点脚本漏洞？它是否提供安全的会话实现？它是否提供安全的身份验证机制？它是否提供了执行OS命令的安全方法？（将参数和可执行文件分开以避免注入，就像参数化的SQL查询一样）它是否提供安全的存储选项？和路径规范化功能？
它是否提供了避免电子邮件标题注入的方法？是否有任何功能可以防止新的线路注入编写安全日志？是否有内置功能可以在输入上应用白名单？不幸的是，默认情况下几乎没有一个框架是完全安全的。但是，那些关心默认框架安全的开发人员应该得到更多的信任。这也意味着您不应该信任一个将上述大部分内容留给用户的框架，即该框架在开发时很容易使用。
文档和示例代码
围绕框架的文档也非常重要。看看一些较旧的TomcatJSP和IIS6ASP示例，令人难以置信的是，所有这些都有几个严重的漏洞。显然，编写易受攻击的示例应用程序是不够的，它们甚至需要在安装过程中自动部署，因此默认情况下您的环境容易受到攻击......
例如，.NET文档中的许多示例都是用参数化的SQL查询，听起来不错，但.NET文档包含许多其他缺陷和可怕的代码片段。为了提高示例的清晰度，一些代码示例已经被剥夺了重要的安全性和错误检查。
安全的应用程序所需的时间，精力和知识
所有这些因素都会影响开发安全Web应用程序所需的时间，精力和安全知识。如果框架使用一行代码为CSRF提供内置安全性，则会立即降低应用程序的复杂性，以及开发和测试所需的时间。此外，开发人员不需要成为安全专家就可以实现这样的检查，这使初学者更容易编写安全的应用程序。
您是否真的认为初级开发人员会知道可能会对Web服务执行跨站点请求伪造攻击？他们还缺乏关于应用程序安全性的大量知识，例如可以从CSS中执行JavaScript代码，这使得在样式表中使用用户输入时会更加小心。他们不知道他们需要将cookie标记为安全。他们不知道你可以通过使用BeEF等免费工具来绕过许多XSS保护。他们通常对安全性一无所知，特别是在涉及边缘案件时。许多开发人员可能永远不会了解这些问题，这就是为什么所选框架应该