Java, PHP, NodeJS, and Ruby Tools Compromised By Severe Swagger Vulnerability (threatpost.com)

"Researchers have discovered a vulnerability within the Swagger specification which may place tools based on NodeJS, PHP, Ruby, and Java at risk of exploit," warns ZDNet's blog Zero Day, adding "the severe flaw allows attackers to remotely execute code." Slashdot reader msm1267 writes: A serious parameter injection vulnerability exists in the Swagger Code Generator that could allow an attacker to embed executable code in a Swagger JSON file. The flaw affects NodeJS, Ruby, PHP, Java and likely other programming languages. Researchers at Rapid7 who found the flaw disclosed details...as well as a Metasploit module and a proposed patch for the specification. The matter was privately disclosed in April, but Rapid7 said it never heard a response from Swagger's maintainers.

Swagger produces and consumes RESTful web services APIs; Swagger docs can be consumed to automatically generate client-server code. As of January 1, the Swagger specification was donated to the Open API Initiative and became the foundation for the OpenAPI Specification. The vulnerability lies in the Swagger Code Generator, and specifically in that parsers for Swagger documents (written in JSON) don't properly sanitize input. Therefore, an attacker can abuse a developer's trust in Swagger to include executable code that will run once it's in the development environment.

Comments

Re:was it intended to be secure?

[cjonslashdot]

Swagger is nice but it is a workaround for what is really a mess: REST. HTTP was not intended to be used an an application level API, nor were XML or JSON. These are all bastard approaches. Compare these with the elegance of remote procedure call approaches such as CORBA and gRPC, where one specifies a method interface just like in a normal computer language, and the marshalling and unmarshalling code is generated by a compiler. The compiler is then the subject of rigorous validation based on the language spec, which leads to a much more robust toolset - a far better situation than someone's hack (i.e., tools like swagger). Also, an API specified in gRPC or CORBA's IDL that is one page will generally be 50 pages if specified as REST - even using Swagger - and the REST spec will have more ambiguity and complexity.

Re:was it intended to be secure?

[hey!]

Swagger is nice but it is a workaround for what is really a mess: REST. HTTP was not intended to be used an an application level API, nor were XML or JSON. These are all bastard approaches.

This is (a) a matter of opinion and (b) completely irrelevant to the bug in question, which is a problem with input sanitation which is a perennial source of security bugs recognized as far back as 1974 in the first edition of Elements of Programming Style.

Now as to the bastard-y of HTML as an API -- having actually read RFC 2616 myself and implemented some of it in raw TCP sockets for some very early mobile to server data connections, I beg to differ. REST is precisely what HTTP was designed to do. People who didn't read the RFCs simply went with what seemed simplest to them, which by in large was using GET and PUT interchangeably since they seemed to be just two ways of doing the same thing. That was very common practice in 2000 when Roy Fielding wrote his famous doctoral dissertation, the arguably most significant contribution of which is simply pointing out what had been the intended semantics of HTTP all along.

  Having tried my hand at SOAP and XML-RPC, I can also say why REST over JSON has been so successful: they make the programmer's job easier, which is what architecture is supposed to do.

"Architecture" has almost become a synonym for making things awkward and unnecessarily complicated, but what good architecture does is separate concerns so you don't have to deal with overwhelming amounts of detail at once. Of course good architecture has never stopped anyone from bolluxing themselves up and handing a steaming pile of logic turds over to someone else.