在使用 RESTful Web 服务对超过 3 个 MLOC 的 RESTful 应用程序进行代码审查和代码辅助应用程序渗透测试后，我可以告诉你，John Wilander 在REST 和无状态会话 ID中概述的问题是主要的、日益严重的问题. 如果你的 RESTful Web 服务没有这个问题（这是一个非常大的问题），我会感到震惊。它基本上使 REST 成为安全噩梦。如果您遵循 John 的建议并使用 SSL/TLS 实现会话，那么您已经解决了您的第一个也是主要的问题。我把它想象成一个非常大的应用程序开发项目。

此外，这种架构的许多组件可能存在风险。Chris Gates 对面向公众的 OAS 进行了大量研究，例如他最近关于Oracle Web Hacking的专栏，其中包括在他的 git 存储库中运行 Metasploit 模块的代码的链接。Sensepost发布了一个工具 (go-derper) 并在上一次 BlackHat-US/Defcon 上针对 memcached 工作。

最后，RESTful 服务肯定会像平常一样存在 SQL 注入、DRO、CSRF 和 XSS 问题——并且这些注入的存储版本的出现将主导直接/反射攻击。

REST 与 SOAP 的问题在于 SOAP 通常会生成 WSDL。REST 可以具有 WSDL（使用 WSDL 2.0）或类似描述的 WADL。但是，这不太可能，并且没有入口点列表，很难测试 RESTful 服务。需要源代码、文档或现有的测试工具。SOAPSonar是一种商业选项，而WS-Attacker仍然是当前用于测试的最佳开源选项之一。

我可以看到一些 Firefox / Chrome插件和/或网络代理（例如Fiddler、Burp、Web2Proxy）也很有用，但这需要花费大量时间来手动构建测试装置。如果测试人员可以使用现有的测试工具（例如soapUI、HttpUnit），那么这些工具可以通过Web 代理运行，最好是支持XML/JSON 的Web 代理，如Web2Proxy、Web2Fuzz、AppCodeScan 和wsScanner（它们是Shreeraj Shah 的著作《Web 2.0 Security - Defending Ajax, RIA, and SOA 》中讨论过。

XML 本身可以使用 Untidy 等工具进行测试，W3AF的作者与W3AF相同，W3AF有自己的代理，称为 spiderMan（如果实现正确，可能非常适合测试 REST）。我不确定 Acunetix WVS（最新版本，上周发布）是否支持 Netsparker Pro（或 Burp Pro Scanner）那样的代理，但如果支持，那么 Acunetix 可能是测试存储注射，因为我听说它对这些类型的检查有很好的支持。如果有人拥有 Acunetix WVS 完整版的许可证，请告诉我们。AcuSensor 技术在这里也非常有用，HP Fortify PTA 也是如此——尤其是在入口点未知的情况下。

换句话说，使用黑盒方法和技术测试 RESTful 服务注定会失败。识别入口点的问题，即使是源代码，也是许多 RESTful 服务通常使用代码间接技术配置和开发，例如几个著名的 Web 2.0 和 Web 服务模式——以及依赖注入、IoC、 AoP 等。更糟糕的是，这种间接性通常有多个级别，没有 Views 文件夹或其他简化。这使得使用以安全为重点的自动化静态分析工具（例如 LAPSE+、CAT.NET、Yasca、Graudit、FindBugs、CodePro AnalytiX、FxCop、Fortify SCA、Checkmarx CxSuite、Appscan Source Edition、Armorize CodeSecure、Coverity、Klocwork、 GrammaTech 等等）。Cigital 有一个名为ESP的解决方案 这被认为是大型安装、基于 SOA 的企业应用程序组合的最佳实践（请注意，ESP 通常由几个应用程序渗透测试人员全年支持，他们知道如何手动审查源代码以及识别应用程序层的复杂运行时分析漏洞——因此它并不意味着仅用作工厂）。

总而言之，几乎可以肯定的是，它需要手动审查所有主要和次要的构建组件可供审查者使用。