我们有数百个使用 asp、.net 和 java 开发的网站,我们支付大量资金让外部机构对我们的网站进行渗透测试,以检查安全漏洞。有没有(好的)软件(付费或免费)可以做到这一点?
或者.. 是否有任何技术文章可以帮助我开发此工具?
我们有数百个使用 asp、.net 和 java 开发的网站,我们支付大量资金让外部机构对我们的网站进行渗透测试,以检查安全漏洞。有没有(好的)软件(付费或免费)可以做到这一点?
或者.. 是否有任何技术文章可以帮助我开发此工具?
您可以使用 Web 应用程序的自动化测试工具有几个不同的方向。
首先是商业网络扫描仪,其中 HP WebInspect 和 Rational AppScan 是最流行的两种。这些是“一体式”、“即发即弃”的工具,您可以下载并安装在内部 Windows 桌面上,然后提供 URL 以抓取您的站点,扫描已知漏洞(即, Bugtraq),并探测跨站点脚本和 SQL 注入漏洞。
其次,还有源代码扫描工具,其中 Coverity 和 Fortify 可能是最著名的两个。这些是您安装在开发人员桌面上的工具,用于处理您的 Java 或 C# 源代码并查找众所周知的不安全代码模式,例如输入验证不佳。
最后,还有渗透测试工具。到目前为止,安全专业人员中最受欢迎的 Web 应用渗透测试工具是 Burp Suite,您可以在http://www.portswigger.net/proxy找到它。其他包括 Spike Proxy 和 OWASP WebScarab。同样,您将在内部 Windows 桌面上安装它。它将作为 HTTP 代理运行,您将浏览器指向它。您将像普通用户一样使用您的应用程序,同时它会记录您的操作。然后,您可以返回到每个单独的页面或 HTTP 操作并探测它是否存在安全问题。
在复杂的环境中,特别是如果你正在考虑任何 DIY,我强烈推荐渗透测试工具。原因如下:
商业网络扫描仪提供了很多“广度”,以及出色的报告。然而:
他们往往会错过一些东西,因为每个应用程序都是不同的。
它们很昂贵(WebInspect 起价为 10 万)。
您正在为不需要的东西付费(例如 90 年代已知的不良 CGI 数据库)。
它们很难定制。
它们会产生嘈杂的结果。
源代码扫描器比网络扫描器更彻底。然而:
它们甚至比网络扫描仪还要贵。
它们需要源代码才能运行。
为了有效,它们通常要求您对源代码进行注释(例如,挑选输入路径)。
他们有产生误报的倾向。
商业扫描仪和源代码扫描仪都有成为架子的坏习惯。更糟糕的是,即使它们有效,其成本也相当于让咨询公司审核 1 或 2 个完整的应用程序;如果您信任您的顾问,那么您肯定会从他们那里获得比从工具中获得更好的结果。
渗透测试工具也有缺点:
它们比即用即忘的商业扫描仪更难使用。
他们假设在 Web 应用程序漏洞方面具有一定的专业知识——你必须知道你在寻找什么。
他们很少或根本没有正式报告。
另一方面:
它们要便宜得多——最好的 Burp Suite,只需 99EU,并且有免费版本。
它们很容易定制并添加到测试工作流程中。
它们更擅长帮助您从内部“了解”您的应用程序。
以下是您使用渗透测试工具对基本 Web 应用程序执行的操作:
通过代理登录应用程序
创建应用程序主要功能区域的“命中列表”,并分别练习一次。
在您的渗透测试应用程序中使用“蜘蛛”工具来查找应用程序中的所有页面、操作和处理程序。
对于蜘蛛发现的每个动态页面和每个 HTML 表单,使用“fuzzer”工具(Burp 称其为“入侵者”)使用无效输入来运行每个参数。大多数模糊器都带有基本的测试字符串,包括:
SQL 元字符
HTML/Javascript 转义和元字符
这些的国际化变体以规避输入过滤器
众所周知的默认表单字段名称和值
众所周知的目录名、文件名和处理程序动词
花几个小时过滤产生的错误(一个表单的典型模糊测试可能会产生 1000 个错误)以查找可疑响应。
这是一种劳动密集型的“裸机”方法。但是,当您的公司拥有实际的应用程序时,裸机方法会得到回报,因为您可以使用它来构建回归测试套件,这些套件将在每个应用程序的每个开发周期中像发条一样运行。这是一场胜利,原因有很多:
您的安全测试将花费可预测的时间和每个应用程序的资源,这使您可以进行预算和分类。
您的团队将获得最准确和全面的结果,因为您的测试将根据您的应用程序进行调整。
它的成本将低于商业扫描仪和顾问。
当然,如果你走这条路,你基本上就是把自己变成了公司的安全顾问。我不认为这是一件坏事。如果您不想要这种专业知识,WebInspect 或 Fortify 无论如何也帮不了您太多。
我知道你专门询问了渗透测试工具,但由于这些问题已经得到充分回答(我通常会使用 AppScan 和训练有素的渗透测试者),我认为重要的是要指出渗透测试并不是“检查安全漏洞的唯一方法” ",而且往往不是最有效的。
源代码审查工具可以让您更好地了解您的代码库,并发现许多渗透测试无法发现的缺陷。
其中包括 Fortify 和 OunceLabs(价格昂贵,适用于多种语言)、VisualStudio.NET CodeAnalysis(适用于 .NET 和 C++,VSTS 免费,不错但不是很好),OWASP 的 LAPSE for Java(免费,不错不是很好),CheckMarx(不便宜) ,用于 .NET 和 Java 的 fanTASTic 工具,但开销很大)等等。
您必须注意的重要一点 - (大部分)自动化工具没有找到所有漏洞,甚至没有关闭。您可以期望自动化工具可以找到大约 35-40% 的 secbug,而专业的渗透测试人员会发现;自动与手动源代码审查也是如此。
当然,适当的 SDLC(安全开发生命周期),包括威胁建模、设计审查等,将更有帮助...
McAfee Secure 不是解决方案。他们提供的服务就是个笑话。
见下文:
http://blogs.zdnet.com/security/?p=1092&tag=rbxccnbzd1
http://blogs.zdnet.com/security/?p=1068&tag=rbxccnbzd1
http://blogs.zdnet.com/security/?p =1114&标签=rbxccnbzd1
就付费解决方案以及 Nikto(免费解决方案)和其他开源工具而言,我听说过关于 SpiDynamics WebInspect 的好消息。如果您还需要检查该层,Nessus 是一个出色的基础设施工具。您可以选择一个带有多个名为 Nubuntu 的工具的 live cd(Auditor、Helix 或任何其他基于安全的发行版也可以),然后谷歌搜索特定工具的一些教程。始终,始终确保从本地网络进行扫描。如果您未经授权从 WAN 扫描一个盒子,您将面临被数据中心封锁的风险。教训是艰难的。;)
Skipfish、w3af、arachni、ratproxy、ZAP、WebScarab:所有免费且非常好的 IMO
http://www.nessus.org/nessus/ -- Nessus 将帮助提出使您的服务器更好的方法。它本身并不能真正测试自定义应用程序,尽管我认为这些插件相对容易自己创建。
看看Rational App Scan(以前称为 Watchfire)。它不是免费的,但有一个漂亮的用户界面,功能非常强大,生成报告(定制并针对标准合规框架,如 Basel2),我相信您可以将其编写到您的 CI 构建中。
尼克托怎么样?
对于这种类型的测试,你真的想看看某种类型的模糊测试器。SPIKE Proxy是 Web 应用程序的几个模糊测试器之一。它是开源的,用 Python 编写。我相信 BlackHat 或 DefCON 有几个关于在某处使用 SPIKE 的视频,但我很难找到它们。
有几个高端专业软件包可以进行 Web 应用程序测试等等。更流行的工具之一是CoreImpact
如果您确实打算自己进行笔测试,我强烈建议您通读OWASP 项目的大部分文档。特别是 OWASP 应用程序安全验证和测试/开发指南。彻底测试应用程序所需的思维方式与正常的开发思维方式略有不同(不是应该不同,但通常是不同的)。
老鼠代理呢?
一种半自动化的、主要是被动的 Web 应用程序安全审计工具,基于对复杂 Web 2.0 环境中现有用户发起的流量的观察,针对潜在问题和安全相关设计模式的准确和敏感检测和自动注释进行了优化.
检测各种安全问题并确定其优先级,例如动态跨站点信任模型注意事项、脚本包含问题、内容服务问题、XSRF 和 XSS 防御不足等
Ratproxy 目前被认为支持 Linux、FreeBSD、MacOS X 和 Windows (Cygwin) 环境。
我知道你专门询问了渗透测试工具,但由于这些问题已经得到充分回答(我通常会使用 AppScan 和训练有素的渗透测试者),我认为重要的是要指出渗透测试并不是“检查安全漏洞的唯一方法” ",而且通常不是最有效的。
源代码审查工具可以让您更好地了解您的代码库,并发现许多渗透测试无法发现的缺陷。
其中包括 Fortify 和 OunceLabs(价格昂贵,适用于多种语言)、VisualStudio.NET CodeAnalysis(适用于 .NET 和 C++,VSTS 免费,不错但不是很好),OWASP 的 LAPSE for Java(免费,不错不是很好),CheckMarx(不便宜) ,用于 .NET 和 Java 的 fanTASTic 工具,但开销很大)等等。
您必须注意的重要一点 - (大部分)自动化工具没有找到所有漏洞,甚至没有关闭。您可以期望自动化工具可以找到大约 35-40% 的 secbug,而专业的渗透测试人员会发现;自动与手动源代码审查也是如此。
当然,适当的 SDLC(安全开发生命周期),包括威胁建模、设计审查等,将更有帮助...