REST特定のセキュリティの弱点
RESTfull Webサービスの使用を開始する必要があります。 SOAPベースのWebサービスには、通信をセキュリティで保護し、信頼を確立するための基準がすでに非常に多くあります。RESTについては知りません。
私が高く評価するのは、次の質問に対する答えです。
私のモバイルアプリは、RESTリクエストを送信するときにX 509証明書を使用します。WSセキュリティで許可されているように、メッセージレベルで保護するためのプロトコル、ベストプラクティスはありますか？
リクエストを送信するときに特定のHTTP動詞を使用する必要がありますか？またはそれらすべてにセキュリティ上の影響はありませんか？
RESTセキュリティトピックに関するリンクがある場合は、それらも共有してください:)
RESTful Webサービスと連携して、MLOCが3を超えたRESTfulアプリでコードレビューとコード支援アプリのペンテネーションテストを行った結果、 RESTおよびステートレスセッションでJohn Wilanderによって概説された問題がわかりますIDs が支配的で増大する問題です。 RESTful Webサービスでこの問題（これは非常に大きな問題です）がない場合、私はショックを受けるでしょう。基本的にRESTはセキュリティの悪夢になります。 Johnのアドバイスに従い、SSL/TLSを使用してセッションを実装すると、最初の主要な問題が解決します。これは非常に大規模なアプリケーション開発プロジェクトだと思います。
さらに、このようなアーキテクチャの多くのコンポーネントが危険にさらされている可能性があります。 Chris Gatesは、 Oracle Web Hacking に関する最近のコラム（ 実行コードへのリンクを含む）など、一般向けOASについて多くの研究を行ってきました彼の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 は現在もテストに最適なオープンソースオプションの1つです。
Firefox / Chrome プラグインやWebプロキシ（例： Fiddler 、 Burp 、 Web2Proxy ）も役立つ可能性がありますが、テストフィクスチャを手動で構築するには、かなりの時間を費やす必要があります。テスターが既存のテストハーネス（soapUI、HttpUnitなど）を利用できる場合、これらのツールは、Webプロキシ、できればWeb2Proxy、Web2Fuzz、AppCodeScan、wsScanner（これらはShreeraj Shahの著書 Web 2.0 Security-Defending Ajax、RIA、and SOA） で議論されています。
XML自体は、 Untidy などのツールを使用して、 W3AF と同じ作成者がテストできます。正しく実装されていれば、おそらく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は通常、手動でソースコードを確認し、アプリケーションレイヤーの脆弱性の複雑なランタイム分析を特定する方法を知っている複数のアプリペンテスターに一年中支えられているため、ファクトリーとしてのみ使用することを意図していません）。
要約すると、ほとんどの場合、レビュアーが使用できるすべてのメジャーおよびマイナービルドコンポーネントを使用して手動でレビューする必要があります。