Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the watch-your-language dept.

"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.

60 of 97 comments (clear)

  1. Never heard of it by Anonymous Coward · · Score: 1

    Never heard of it and not in use in major areas. Nothing to see here. Just overhyped.

    1. Re:Never heard of it by benjfowler · · Score: 1

      Swagger's the RESTful web service equivalent of WSDL. It isn't quite as featureful, but is quite a bit nicer to read. Also, many web apps embed Swagger UI, which gives you a nice way to browse and play with your web service endpoints. The quality of the tools in the Swagger universe are mixed to say the least -- Swagger UI and Swagger Editor are really quite nice. Swagger Code Generator, in my experience, is not so good.

  2. Re:That's what you get for using OSS by NotInHere · · Score: 2

    Have you heard of von neumann architectures? Did you know that nearly every computer in use today is such a device?

  3. Web Programmers Gonna Web by hhas · · Score: 1

    Congratulations to the Swagger team on achieving their impressive goal of officially codifying every RESTful anti-pattern ever invented, and let's wish them all the best in formally implementing every known security hole next.

  4. Re: That's what you get for using OSS by davidwr · · Score: 1

    Save this as a batch file and modify or re-write it for your environment.

    Usage:
    instructionstocash takes instructions from stdin and outouts the literal string "cash!" to stdout.

    --cut here--
    #!/bin/sh
    #instuctionstocash
    echo 'cash!'

    --cut here--

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  5. Re: That's what you get for using OSS by davidwr · · Score: 1

    Damn typos. Finding and fixing typos is left as an exercise for the reader.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  6. was it intended to be secure? by ooloorie · · Score: 4, Informative

    I hadn't see Swagger before, but it looks like a nicer design than previous web service description languages.

    The "vulnerability" related to Swagger in some tools that the REST API specification (in Swagger format) into a library that talks to that API. Specifically, malicious specifications can inject code into the library. I don't think this is a major problem in practice. These translation tools are invoked by people who want to write clients for specific services; usually, that means that you know the service provider and understand your trust relationship. In addition, this is not a fully automatic process, since you'll be programming against the library that the tool generates anyway.

    Keep in mind that the alternative to a REST specification that the service provider gives you a bunch of REST client libraries, and it's far easier to hide malicious code in those client libraries than in a REST specification.

    I don't think it's fair to call this a significant "vulnerability", although it might still be nice if Swagger tools detected these cases and alerted the developer to it.

    1. Re:was it intended to be secure? by cjonslashdot · · Score: 2, Interesting

      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.

    2. Re:was it intended to be secure? by darpo · · Score: 1

      "The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients" http://stackoverflow.com/a/151...

    3. Re:was it intended to be secure? by cjonslashdot · · Score: 2

      Yes, that has been the argument. But it has proven to be a red herring. Systems are semantically coupled if they interoperate. The syntax of that coupling can either help to maintain consistency, or not. REST does not help: it is entirely up to the programmer to check everything and make sure though tons of testing that everything still works. In contract, a compiler based approach helps enormously. Real real way to decouple systems is to _logically_ decouple them, so that, e.g., backward compatibility is intentionally retained, and API methods are designed to be general purpose instead of special purpose - and those issues are independent of the syntax.

    4. Re:was it intended to be secure? by hhas · · Score: 1

      REST isn't a mess, it's actually a very clean, logical, and elegant state-centric approach to interconnecting vast numbers of highly heterogenous state machines. It's the entire web programming "profession"'s atrocious inability to get what REST actually means, as to what they reinterpret it to mean, to the point where their total misconceptions are now raised to the status of "industry standard".

      Protip: Any software developer who uses the phrase "REST API" has a deep detailed technical understanding of REST that is 100% perfectly wrong. Which nowadays is pretty much all of them. Remarkable.

      --
      It is difficult to get a man to understand something, when his salary depends on his not understanding it. -- Upton Sinclair

    5. Re:was it intended to be secure? by hey! · · Score: 4, Interesting

      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.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    6. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Well I must misunderstand REST then! Although every single REST project I have been on has treated REST as an API syntax. But is this splitting hairs? I know that the concept is that one transfers state from one place to another. But in practice the paradigm is driven by the UI framework (e.g., Angular, etc.), and given the component-oriented react oriented patterns of today, one is not transferring state: one is making API calls. That is what apps need, and they are using REST because of AJAX, and it has produced a mess. JSON is a maintainability nightmare, for example, with people specifying data structure syntax by showing examples, instead of using something complete and normative like BNF (or JSON schema now that there finally is such a thing).

    7. Re:was it intended to be secure? by hhas · · Score: 3, Insightful

      Well I must misunderstand REST then!

      Very likely. It's not about "APIs"; never has been. The web was original designed to be a vastly distributed document publishing system, where everyone could read and everyone could write. The first "web browser" was actually a WYSIWYG editor, kinda like Word except that instead of opening and saving documents on your local drive it opened and saved them across the internet. HTTP was the transport mechanism for that, and crucially it made no statements on what those documents were or how they were encoded; all it did was carry them between web server and web client. HTML was simply conceived as a new document format designed to be particularly well suited to the web, as established document formats back then were rather lacking in hyperlinking support; but there was nothing in the conception, design, or implementation of the web that said HTML was anything special or by any means the only document format that could be used.

      So all the groundwork was done and all the pieces correctly in place to build a world-wide web as it was intended to be.

      But TBL was lazy and impatient, and rather than making the time and effort port his entire "web browser" application from NeXT to Windows &co he just ported the read part only, because that was the simplest bit. Of course, back then there weren't any other apps (e.g. Word) that knew how to open and save documents across the web, so everyone who saw this read-only web browser in action naturally assumed that that was how the web was intended to work. Nobody piped up to say that actually, the other 80%'s still lying on a workbench in Cern waiting for Timmy to finish his tea, and Version 2.0 will be out Real Soon Now so wait for that before going too far, because if you think that 20%'s great then the full 100% will blow you away!

      And then of course the likes of Netscape and Microsoft took this initial idea and codified and standardized and productized and turned it into a whole new "vision" of the web, a horribly crippled, gelded web where everyone could still read from it, but nobody could write directly to it; and the only people who could write to it at all were the tiny tech priesthood who knew how to manually transcode documents to HTML format, then stick them manually onto a web server by arcane backdoor FTP.

      ...

      From that point forward, our entire World-Wide Web was officially Fucked Up Beyond All Recognition, with a constantly diminishing chance of ever being put right again before it could get worse. And then, of course, because nobody outside of TBL's original circle even realized - or was ever told - that the web was specifically designed to let you shift any kind of information from A to B (even automatically transcoding it if B told A it would prefer it in a specific format), it was only a matter of time till Ingeniously Clever And Inventive People like Dave Winer rolled in and decided what the web really needed now was a brilliant New Feature that would allow it to transmit data other than HTML - and hence gave birth to XML-RPC and SOAP and ultimately the ad-hoc RPC-over-HTTP-with-XML/JSON-encoded-parameters that is what today's so-called "REST APIs" are actually doing.

      So now we have this utterly bizarre situation where ever web app has this schizophrenic split personality, where HTML-based information exchange is treated as this one huge special case over here, under /..., while information exchange conducted in any other format is conducted way over there, in /api/v2.1/..., each with a totally different data graph and verbs (or pseudo-verbs) for interacting with those graphs. And yet it's all the same bloody information! Refactoring 101 Fail, or What? There should just be one graph, one set of verbs (solely for getting and setting), and the only thing that ever changes is the MIME types that are attached to requests and responses (as Accept

    8. Re:was it intended to be secure? by hhas · · Score: 1

      Please go read my other post then, preferably while washing your mouth out with Drano.

    9. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      "The first "web browser" was actually a WYSIWYG editor" Which one was that? Are you referring to Mosaic? If so, I did not know that it had editing capability. As I recall, REST came along as a response to SOAP, which was overly complex for what people were using it for. The most common feature of SOAP was SOAP-RPC, so it was natural for people to want to use REST for that. I 100% agree that HTTP is being misused - and REST as ell. What we need is a protocol other than HTTP for remote procedure calls. Unfortunately, everyone assumes that every new application over the Web must use HTTP. Do you recall IIOP (CORBA)? Sysadmins would not let it through their firewalls, so people turned to HTTP in order to be able to do remote procedure calls over the Internet. People need and want RPC for a myriad of applications. REST and HTTP are terrible for that. IIOP exists, but no one uses it. Now we have gRPC which pushes RPC over HTTP (without REST), but it is still using HTTP. This sidesteps the issue but it might be the best we can hope for.

    10. Re:was it intended to be secure? by hhas · · Score: 1

      Doh! My reply to you's just got posted as AC. HTH (Though you can still tell by the length, I'm sure.)

    11. Re:was it intended to be secure? by hhas · · Score: 1

      Good grief, and I've AC'd my other reply too! Hey, I blame Firefox for crashing on me halfway through (it's trying to keep you from the Truth!).

    12. Re:was it intended to be secure? by MikeBabcock · · Score: 1

      You read a modern spec? stop the presses.

      Seriously, what HTTP was designed to do is described here https://tools.ietf.org/html/rf...

      Read that one and you'll understand why people think REST is almost silly.

      --
      - Michael T. Babcock (Yes, I blog)
    13. Re:was it intended to be secure? by ooloorie · · Score: 1

      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.

      CORBA came out in 1991 and SunRPC in 1988. REST didn't arrive until 2000. So, the history of this is that people tried to make CORBA and RPC (and Microsoft's versions of the same) work for about a decade before they gave up and switched to REST.

      CORBA's and gRPC's IDLs are a good match to programming languages, which is why they appeal to some programmers. But Internet-scale distributed systems don't behave like programming language interfaces, so treating them as such just doesn't work well. That's something most of the world learned in practice in the 1990s, but apparently the message hasn't gotten through to some corners of the world yet.

    14. Re:was it intended to be secure? by eWarz · · Score: 1

      Did you even read that RFC you linked? You'll also note that's a 20 year old RFC. HTTP 1.0. At minimum you should read the HTTP 1.1 spec before you start trash talking others.

    15. Re:was it intended to be secure? by eWarz · · Score: 1

      What do you think that JSON documents are for?

    16. Re:was it intended to be secure? by hhas · · Score: 1

      Encoding information? JSON's just another serialization format; it says nothing about what information a document should contain or how it is organized (beyond being arranged in a tree shape, of course). Some folks prefer it over XML cos it's more lightweight and trivial to work with in JS, though of course there's nothing to stop a RESTful resource offering up representations of itself in both encodings - e.g. application/vnd.initrode.employee.v2+xml and application/vnd.initrode.employee.v2+json - or any other encoding for that matter - plain text, RDF, s-exprs, HTML, XSLX, and so on - if that's what clients are interested in consuming. RESTful content negotiation is about the server saying "here's the information I can provide you with in the encodings I support" and letting the client pick the one that best suits its needs and preferences.

    17. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Yes, and before SunRPC, I remember that Apollo Computer had an RPC toolkit. Actually, CORBA did work - quite well. I used it a-lot back then. XML based messaging came along - way before Internet scale was a concern - because it went over HTTP, thus "tunneling" through firewalls. CORBA required you to open ports, and sysadmins would not do that. From there, the nightmare of WSDL emerged, and then REST replaced WSDL, and programmers signed with relief because it was so much simpler. By that time, the OMG had updated CORBA so that it could to through firewalls, but it was too late: since IT is fad-driven, CORBA was "out of style". Then "internet scale" started to become an issue. And Google has found that REST cannot meet the needs of Internet scale, so they have developed gRPC, which is just like CORBA, and is (like CORBA) much, much faster and uses much, much less bandwidth than REST. Google's clearly stated reason for developing gRPC is that REST is too slow and uses too much bandwidth.

    18. Re:was it intended to be secure? by hhas · · Score: 1

      https://developers.slashdot.or...
      https://developers.slashdot.or...
      https://developers.slashdot.or...
      https://developers.slashdot.or...

      Doesn't cover all the philosophy or mechanics, but should do for starters. Ask specific questions where more information is needed.

      Oh, and Fielding's writeup from his work on HTTP, natch:

      https://www.ics.uci.edu/~field...

      All good on the theory, hopeless on worked examples for actually testing if your interpretation actually matches his intent, but guess that's how academia rolls.

      BTW, if you're wondering why not even the dog will kiss you, it's because you have a mouth like an open sewer.

    19. Re:was it intended to be secure? by ooloorie · · Score: 1

      gRPC and REST don't even solve the same problem. Google is using RPC extensively, but mainly in the context of their own internal distributed systems, with an army of testers and developers, massive integration testing, and a single codebase. REST is for highly heterogeneous systems, languages, developer skills, a huge range of latencies, and numerous failure and security models. RPC can be a useful tool for the kinds of distributed systems Google is building to support their services; it is not a good tool for the kind of applications that REST is being used for, and there is tons more of the latter than the former.

      As for CORBA, going through firewalls was the least of its problems; it was just badly designed. That's why Google, IBM, Microsoft, and Sun all developed their own systems. So, if you want RPC, by all means, use gRPC. But chances are that any form of RPC is probably not the right solution to your problem to begin with and you should be using something different.

      Google Trends pretty much tells the story: http://tinyurl.com/ho8gs7f

    20. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      It seems to me that REST tries to solve a problem that does not exist. Programmers want RPC. The notion of REST is too abstract for most programmers. Also, Google's internal systems are Internet-scale - they are the ones providing that scale! Of late, Google has turn away from several current cherished paradigms, including REST and dynamic languages, returning to older concepts that have stood the test of time.

    21. Re:was it intended to be secure? by ooloorie · · Score: 1

      Of late, Google has turn away from several current cherished paradigms, including REST and dynamic languages, returning to older concepts that have stood the test of time.

      Google hasn't "turned away" from anything, Google never embraced REST or dynamic languages much in the first place. Google has always been a stodgy C++/Java shop, and they can get away with using such unproductive tools because they have gobs of money and tens of thousands of programmers. I'm not sure where you work, so it may come as a surprise, but 99.99% of software development doesn't work that way. That's why Python, PHP, and REST are so popular.

      Also, Google's internal systems are Internet-scale - they are the ones providing that scale!

      The "Internet scale" we are talking about here isn't one big honking corporate serving lots of people; Google is good at that, and RPC can be an OK paradigm to build that on. The "Internet scale" we are talking about here is millions of different clients and servers, and thousands of different platforms they run on; constantly changing interfaces; developers who don't have Stanford graduate degrees in computer science; small shops that just want to get an app working and sell/deploy a few thousand copies.

    22. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Stodgy? Some of the languages that I have used extensively over the years (more or less chronologically): Basic, Fortran, Algol, PL/I, Pacal, Ada, C, Module2, C++, VHDL (I helped to develop this language, and wrote compilers for it), Java, Ruby, Go. Other languages that I have used here and there: Lisp, Prolog, Python, AspectJ, Scala, Groovy. Which are the most productive for an organization (not an individual) over the long term? Without a doubt, Java. Reason: It is by far the most maintainable and refactorable as teams turn over. Second choice: C++. Some of the worst for maintainability: all the dynamic languages, and Go. I think that Google knows what it is doing, and the fact that it defies many of today's trendy tools tells me that just maybe those tools are popular because they are popular - not because they are good. As Alan Kay has said, "Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture..."

    23. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Another thought: I don't want to dismiss what you said above about Internet scale: it is actually quite insightful: "The 'Internet scale' we are talking about here is millions of different clients and servers..." It is true that for for query applications, the REST model is logically a good one. However, the REST protocol (i.e., HTTP with character data) is horribly inefficient. If one compresses it, that helps a-lot, but that is really a workaround. gRPC uses (by default) Protocol Buffers, which is reportedly ten times more efficient/responsive in terms of bandwidth and latency. Also, for applications in which the user performs updates to data, an RPC model makes more sense. Once can use gRPC with a REST-like paradigm: it all depends how one defines one's responses. It is kind of moot though because programmers use toolkits like React and Angular, and a component-oriented approach has become popular today (we are back to a popularity contest) - driven largely by the frameworks that embed a "react" pattern - i.e., the MVC is gone, and each component performs transactions against a back end microservice. For this pattern, gRPC and microservices in containers is a perfect combination - and Internet-scalable.

    24. Re:was it intended to be secure? by ooloorie · · Score: 1

      I think that Google knows what it is doing

      They do. But that doesn't mean that you do. What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints.

      As Alan Kay has said, "Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture..."

      I suggest you read the entire interview, because Alan Kay was, in fact, criticizing people with just your views. About C++, he also said "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind".

    25. Re:was it intended to be secure? by ooloorie · · Score: 1

      gRPC uses (by default) Protocol Buffers, which is reportedly ten times more efficient/responsive in terms of bandwidth and latency.

      Protocol buffers have a couple of serious problems. First, they are not designed for large messages (>1Mbyte); so forget about using them for things like audio, video, image, or document upload... like most of what people actually do with REST. That limitation goes to the core of their APIs, which don't support incremental decoding or non-copy memory transfers very well. Protocol buffer data types also don't map well onto programming languages. And they aren't self-describing. There are several other binary protocols that address these issues. gRPC also becomes extremely cumbersome when dealing with asynchronous operations, failures, and load balancing; that's because Internet-scale distributed systems don't work like procedure calls.

      Once can use gRPC with a REST-like paradigm

      You could, but why would you want to? Adding gRPC to REST doesn't fix any of the problems with REST, while adding all the limitations and problems that gRPC has on top of those of REST.

      a component-oriented approach has become popular today (we are back to a popularity contest) - driven largely by the frameworks that embed a "react" pattern

      React patterns are based on message passing, not remote procedure calls. You can emulate message passing with procedure calls (and that's what you do when you use gRPC in such a context), but that's really just a workaround for the lack of a good message passing library, and you pay for it with all those issues that I mentioned above.

      gRPC is good for what it is: an old-fashioned protocol for building large, monolithic, long-term, distributed systems within big companies full of Java and C++ programmers. To replace REST on the Internet, as well as for supporting microservices, however, we need something different.

    26. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      "not designed for large messages...": Hmmm - isn't there a way to attach a file - i.e., a MIME "part"? Since PB uses HTTP2, it would be hard for me to imagine that they left that out. But if you are right, I agree it would be a terrible problem. Perhaps attaching files is part of gRPC but not PB?

      Not sure I understand your comment about non-copy memory transfers, since PB/gRPC are remote (out-of-process) communication tools.

      Yes, you are right, that message passing (e.g., UDP) is more scalable when one has a single server. But if you can massively scale the servers, the limitations of RPC-like communication go away.

    27. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      "What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints." - that is VERY true.

      I agree that C++ is too complex. The problem is, alternatives are even worse for other reasons. Ruby is HORRIBLE from maintainability and performance points of view. To write maintainable Ruby, one has to use TDD, which is deeply incompatible with how many people think. (See the debates between David Heinemeyer Hanson and Kent beck: http://martinfowler.com/articl...) And I have used Ruby a-lot, so I am not guessing. And Go is really awful because it throws out enormously useful features like virtual methods and exception handling, and Go also has lots of "gotchas" - my favorite is comparing a reference with nil and getting false, then type asserting it, comparing the asserted value with nil, and then getting true. Things like that will result in lots of bugs, and there are many gotchas like that. So I have turned back to C++ because, if used well (i.e., conservatively), one can write very efficient and maintainable programs - IF used well. Efficiency matters at Internet scale because if a Ruby program requires 10,000 VMs but a C++ program requires only 100, that is a very large cost saving.

    28. Re:was it intended to be secure? by ooloorie · · Score: 1

      "not designed for large messages...": Hmmm - isn't there a way to attach a file - i.e., a MIME "part"? Since PB uses HTTP2, it would be hard for me to imagine that they left that out. But if you are right, I agree it would be a terrible problem. Perhaps attaching files is part of gRPC but not PB?

      Not that I know of. And what would be the point? That would amount to a REST call with metadata attached in PB format, which is kind of like a bicycle for fish.

      Not sure I understand your comment about non-copy memory transfers, since PB/gRPC are remote (out-of-process) communication tools.

      High-performance networking tries to avoid memory copies as much as possible. That is, once received, the data should never have to get copied unless you need to process it in some way.

      Yes, you are right, that message passing (e.g., UDP) is more scalable when one has a single server.

      Asynchronous message passing refers to a style of programming similar to (but different from) OOP. It really has nothing to do with UDP other than a superficial similarity.

      But if you can massively scale the servers, the limitations of RPC-like communication go away.

      A "procedure call" generally means something that is synchronous, strict, sequential, and runs in the same address space. Distributed programming in general has none of those properties. RPC systems first try to emulate those properties as much as possible, and then provide various workaround for the fact that the real world doesn't work like that, ending up with complex frameworks that don't behave much like procedure calls in the general case. That works well for tightly coupled distributed applications written in procedural languages, like Google's original search engine and similar applications. It doesn't work well for large, highly heterogeneous systems that need to work over the Internet or in many other contexts. (Incidentally, I might add that gRPC doesn't even have a load balancer yet; I suspect writing one isn't easy given gRPC's design.)

      RPC libraries have their uses. But my point is: they are no replacement for REST, and they really inhabit a small niche in the space of distributed systems.

    29. Re:was it intended to be secure? by ooloorie · · Score: 1

      I didn't really voice an opinion on the merits of C++ either way. You had said that "of late, Google has turn[ed] away from several current cherished paradigms", implying that there is some kind of repudiation of dynamic languages going on. I just pointed out that Google never was much into dynamic languages in the first place, and that just because C++ is a good choice for Google's core applications doesn't mean it's a good choice for most programmers. As a C++ programmer myself, I think it's great that Google supports C++ programming. But C++ programming is a very specialized skill, and most people are better off using something different.

    30. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      "Not that I know of. And what would be the point? That would amount to a REST call with metadata attached in PB format, which is kind of like a bicycle for fish." - that would indeed be ridiculous, but I would expect the attached binary content to be unencoded, as it is in an HTTP binary encoded part. There is a major use case for that: queries that send binary data. E.g., I have been using the docker engine and docker registry REST APIs, and many of the methods include both query parameters and binary object parts (i.e., attached files) in the same request or response. I think we need to look at the gRPC specs to see if it handles this case.

      "Asynchronous message passing refers to a style of programming similar to (but different from) OOP. It really has nothing to do with UDP other than a superficial similarity." - I disagree. The debate between synchronous calls and messaging is as old as the Internet. You are right that these do indeed distinguish different programming paradigms: in synchronous calls one handles the response inline, whereas an asynchronous approach requires and event-oriented design with compensating transactions at the application level. The asynchronous approach is much, much more complex for the programmer to implement, because of the large number of states that must all be handled, but it is warranted when requests have lots of latency or when there are lots of clients compared to the number of servers - so many that it would be difficult to maintain that many stateful connections. With an elastic back end, however, the latter concern goes away.

    31. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Yes, C++ is probably not for most programmers. To use it well, you have to spend a-lot of time with it, and do a-lot of reflection (reflection in the sense of mentally thinking about it). And you are probably right about Google not changing its attitude on dynamic versus static. But doesn't that say something? They have to handle very large things - they have had to from the beginning. The fact that they stay away from dynamic languages - what does that say? I guess you can tell that I am not a fan of dynamic languages. I started my career writing compilers and so I feel strongly about the benefits of static analysis. I have spent a-lot of time writing vagrant and chef scripts (not anymore - vagrant and chef are obsoleted by docker and orchestration), and I remember the pain of that process - wishing that there were a statically compiled alternative, so that I did not have to run the scripts, wait for the VMs to boot, and then get through all the provisioning just to find that there is a syntax error somewhere in my Ruby. Another experience: I wrote a large application (a performance testing tool) in Ruby, over a period of about six months. I then ported it to Java, and in the process I discovered countless issues that could potentially be problems down the road - issues that I only discovered because the Java compiler found them - things that would have required a comprehensive unit test suite for the Ruby version to find them. A third experience: Over the last year I have been working mostly in Go, and while I don't like Go _at all_ it has some things going for it: one if them is that it is pretty strongly typed, and I have found that I can do massive refactoring of the Go codebase and introduce _zero_ new errors as a result - try that with a dynamic language!

    32. Re:was it intended to be secure? by ooloorie · · Score: 1

      I think we need to look at the gRPC specs to see if it handles this case.

      Be my guest. I'm just telling you don't hold your breath for gRPC to take off.

      The debate between synchronous calls and messaging is as old as the Internet.

      No, I'm sorry, but you still don't understand. Asynchronous message passing is a programming language abstraction, not a network abstraction; it's what Alan Kay originally envisioned for Smalltalk methods.

      The asynchronous approach is much, much more complex for the programmer to implement, because of the large number of states that must all be handled

      The asynchronous approach is much, much more complex to implement on top of an RPC system. That's my point: RPC systems are a bad abstraction because they make asynchronous programming unnecessarily difficult.

    33. Re:was it intended to be secure? by ooloorie · · Score: 1

      And you are probably right about Google not changing its attitude on dynamic versus static.

      I think your premises are flawed. Google uses a mix of C++, Python, Java, JavaScript, and Go, and all of those languages support both static and dynamic type checking. And Google clearly isn't happy with C++, otherwise they wouldn't have hired someone to develop Go. Furthermore, Go has substantially weaker static type checking than C++, so it doesn't look like Google is as adamant about static typing as you seem to be.

      I started my career writing compilers and so I feel strongly about the benefits of static analysis.

      Static analysis is nice, but you can only analyze information that is actually available at compile time, and a lot of information is not; that's why languages like C++ have added features like RTTI and dynamic casting. Furthermore, static type analysis can become enormously complex and be more hassle than it's worth, which is why Java uses type erasure and Go doesn't even provide generics at all. On the other hand, many dynamically typed languages are completely type safe and allow you to add type annotations that catch type errors early and easily; and with JIT compilation, they can even generate better code than static analysis. In practice, the differences between statically and dynamically typed languages are pretty fluid and ill-defined, and the choices are often not as clearcut as you seem to think.

    34. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      "The asynchronous approach is much, much more complex to implement on top of an RPC system." - can you please give an example? I have implemented message based programs - and you are right, that it is a programming construct independent of the network - but IME message based applications are very complex to design: one must identify all of the states. But I am willing to learn! Thanks!

    35. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Go and C++ are so different, and C++'s type safety might be stricter, but the type safety of Go is pretty strict. Nuances aside, thus practically speaking, I have found that languages like Ruby lead to very unmaintainable code. That was my point. Dynamic type features (which Go has to some extent) don't change that, because one uses those to add dynamic features to one's application, such as adding a new component a runtime, or dispatching to a method based on dynamic information such as a command that has been input. Dynamic type features are not usually used throughout a program, but rather only in special circumstances. But I have found that Ruby's lack of type checking can lead to very fragile code when one refactors.

    36. Re:was it intended to be secure? by ooloorie · · Score: 1

      "The asynchronous approach is much, much more complex to implement on top of an RPC system." - can you please give an example?

      http://www.grpc.io/docs/tutori...

      Note that the API still requires requests and responses, so it forces clients and servers to keep track of state even if the computation otherwise doesn't require it. That's because procedure calls are an abstraction that intrinsically involves a notion of state.

      In a message passing architecture, the primitive by which you invoke functionality on objects is intrinsically stateless, and so network libraries implementing message passing don't force users to deal with state either. That is, all you need to say to send an asynchronous message is "send(&context, request)"; the API doesn't force you to write code to deal with responses on every RPC call. Although originally conceived by Kay for Smalltalk, the first large scale implementation was in Erlang, and there are libraries supporting this programming style in many languages now.

    37. Re:was it intended to be secure? by ooloorie · · Score: 1

      Go and C++ are so different, and C++'s type safety might be stricter, but the type safety of Go is pretty strict. Nuances aside, thus practically speaking,

      Type safety isn't the same as typing strategy. C++'s type safety is weaker than Go's (since there are types like "void *"), but it has a more expressive static type system.

      I have found that languages like Ruby lead to very unmaintainable code.

      I think you're overgeneralizing from your limited experience with a tool-poor scripting language to dynamic languages in general. You can write unmaintainable code in any language: C++, Go, Haskell, Ruby, Python, etc. Writing maintainable code in dynamic languages requires a different skillset on the part of the programmer, but in return, a lot of problems become quite a bit easier to solve. It's a matter of tradeoffs. Even refactoring works quite differently in dynamic languages.

    38. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      Aha. Now I know where the disconnect is in our discussion on this. I have been thinking in terms of updates, and you have been (it sounds like) been thinking in terms of fetching data. Yes, for fetching data, you are right, asynchronous is far more efficient, if one can get away with a best effort (eventual consistency) approach, which is usually the case for UIs.

      For transactions that do updates, a synchronous approach is far easier to implement, because one does not have to keep track of application state, because (1) one handles failures immediately, and (2) the transaction is atomic (if it is not, then you have to manage state at the application level). E.g., consider a user who reserves an airline seat, but between the time the user received notice of the available seats, the selected seat is given away. The user does not now the seat was given away (and their UI has not refreshed yet), so they click Submit to reserve the seat. In a synchronous approach, the Submit will fair right then, and so their UI will immediately receive a failure response and can update it self accordingly. But in an async approach, the user will receive a success response, and might even close their browser before a failure message is received. Thus, the application then has to have additional logic to record that the user was not notified of the transaction failure, and will likely have to email the user to let them know that their seat reservation failed. Much more complicated.

      I.e., message oriented is simpler for getting data, but synchronous is simpler for updates. Do you agree?

    39. Re:was it intended to be secure? by cjonslashdot · · Score: 1

      "limited experience with a tool-poor scripting language..." - which are you referring to, Ruby? If so, Ruby is not tool-poor.

      "...but in return, a lot of problems become quite a bit easier to solve." - Yes, I agree with you. Perhaps our disagreement is our perspective: I advise organizations, and so I tend to be on the side of maintainability - and that requires languages and tools that are naturally maintainable - not ones that require great effort to craft maintainability. I think that you advocate for the developer - and particularly the advanced developer. Yes, I agree that scripting languages enable you to code more quickly, although I have found the refactoring can introduce lots of bugs with scripting languages, unless you have a very high coverage unit test suite, which I try to avoid, and compilers help me to avoid that - saving me a huge amount of effort, and instead allowing me to focus on behavioral tests which are far more stable when one refactors.

      I will note that I have seen very, very expert developers create mountains of unmaintainable code very rapidly, and not even know that their code was unmaintainable.

    40. Re:was it intended to be secure? by ooloorie · · Score: 1

      E.g., consider a user who reserves an airline seat, but between the time the user received notice of the available seats, the selected seat is given away. The user does not now the seat was given away (and their UI has not refreshed yet), so they click Submit to reserve the seat. In a synchronous approach, the Submit will fair right then, and so their UI will immediately receive a failure response and can update it self accordingly. But in an async approach, the user will receive a success response, and might even close their browser before a failure message is received

      You're thinking of this in a very procedural way: the web form handler calls the seat server, waits for a seat reservation or an error, and then returns a page with success or failure to the user. That's not how people write scalable web applications. Procedural stacks are far too costly to keep around. The way people implement this is usually using some kind asynchronous framework: node.js, Akka, Erlang, or message queueing.

      Message queueing is perhaps the easiest to explain: the web form handler transforms the reservation form into a seat reservation request and enqueues that on the reservation server; the reservation server processes the reservation and sends on the result to another server that generates the appropriate response. The whole thing is like a pipeline, and no stage in the pipeline waits for any other stage to complete.

      Another framework that is based on asynchronous calls is node.js; it's pretty tedious but fairly widely used. The code would look something like this:

      app.get("/form", function(request, response) {
          async.parallel([
            cb => cb(null, reservation_server.reserve_seat(request)),
            cb => cb(null, accounting_server.charge_account(request))
          ],
          function(err, results) {
              if (err) { response.send("error message"); return; }
              async.parallel([
                  cb => cb(null, reservation_server.commit(results[0])),
                  cb => cb(null, accounting_server.commit(results[1])),
                  cb => cb(null, response.send("got reservation for...")
              ]);
          }
      );

      Note that none of the server calls are synchronous, and they actually never return to the calling procedure.

    41. Re:was it intended to be secure? by ooloorie · · Score: 1

      Ruby? If so, Ruby is not tool-poor.

      Scripting languages and dynamic languages are not the same thing. Ruby is a scripting language and really doesn't have a lot of the tools that exist for a heavy duty dynamic language like, say, Smalltalk.

      I advise organizations, and so I tend to be on the side of maintainability - and that requires languages and tools that are naturally maintainable

      People can easily create completely unmaintainable code in C++ or Haskell. Static typing is neither necessary nor sufficient for maintainability.

      I will note that I have seen very, very expert developers create mountains of unmaintainable code very rapidly, and not even know that their code was unmaintainable.

      I create tons of unmaintainable code. Maintainability is just one of many attributes of software. Requiring maintainability when it's not needed is inefficient.

  7. Re:That's what you get for using OSS by Jesus_666 · · Score: 1

    Microsoft is open-sourcing their stuff now too. Use Windows 7 and disable updates if you want to be safe.

    --
    USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
  8. Re:Can I be hit if I don't use swagger? by Camel+Pilot · · Score: 1

    I think swagger is like WSDL using json instead of xml

  9. REST and security are orthogonal concerns by hhas · · Score: 2

    "The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients"

    Which is why RESTful HTTP isn't RPC, because we already know it's the wrong tool for this job. The fundamental problem is that today's web has an entire programming cult[ure] raised on OOP to the point where they're pathologically incapable of imagining any kind of interaction model except synchronous local message passing, so instead of bothering to RTFM until they understand correctly how REST works, the lazy toads simply reinterpret "REST" to mean what they already know. Which is 180 the opposite to what it actually is.

    Actually, the best way to think about RESTful interactions is as a form of declarative programming, where you say how you want the state of a remote application to look, and then leave that application to figure out for itself how to transition into that state. That's why HTTP only has verbs for performing state changes; any other behaviors a RESTful application might manifest arise purely as side-effects to those state transitions.

    But you try explaining this to a modern industry web developer, not only will they not believe you they won't even understand what words you just said. Dunning-Kruger wept.

  10. Re:That's what you get for using OSS by Zontar+The+Mindless · · Score: 1

    Now I'm confused. Should we use Windows 7, or should we use hot grits?

    --
    Il n'y a pas de Planet B.
  11. Re:Would Rust have prevented this? by davester666 · · Score: 4, Informative

    From my fairly basic reading of the issue, it is NOT a problem of ANY of the listed languages, but a problem with using/integrating the Swagger API in your web app using any language.

    --
    Sleep your way to a whiter smile...date a dentist!
  12. Re:Can I be hit if I don't use swagger? by darkain · · Score: 1

    Seconding this... NEVER heard of Swagger before... At first I thought that was the new hip name FOR this exploit (WHY THE FUCK DO THEY ALL NEED NAMES NOW)

  13. Swagger Codegen is a pile of crap by Anonymous Coward · · Score: 1

    Been there, done that, got the scars to prove it.

    I've found that compared to the tooling we were all using 15 years ago to build SOAP web services (fond memories of fighting incompatible implementations...), Swagger tooling is far worse, implements far fewer even obvious use cases, and is laden with bugs. In my recent work, Swagger Codegen was the worst I used. It is a flaming piece of shit which appears to be maintained by the same sort of teenagers with short attention spans that brought you crap like "left pad" on npm.

    Even before the now-revealed security bugs, I found it was completely unfit for purpose. Attempting to generate Java server stubs, I could not get the piece of garbage to generate code that could COMPILE. It doesn't handle restriction by simple types, which is quite possibly the SIMPLEST thing you can do with a schema.

    Angry that I wasted a day on this garbage. And apologies to anybody who worked on that code who might be reading this. I realise I might be looking a gift horse in the mouth -- but anybody who has the cheek to release such a piece of shit even as Free software and pass it off as a working piece of software ought to be fucking ashamed of themselves. It indicates a profound disrespect for the time and energy of potential users.

  14. Re:Would Rust have prevented this? by benjfowler · · Score: 1

    Specifically, Swagger Code Generator, which FWIW, is a bit crap to begin with.

  15. Re:Can I be hit if I don't use swagger? by benjfowler · · Score: 1

    Sure you've never seen Swagger UI before? Because just about everyone I've spoke to who's ever dabbled in server-side development is familiar with it:

    Demo: http://petstore.swagger.io/

  16. Re:Can I be hit if I don't use swagger? by Mats+Svensson · · Score: 1

    I have never heard of it either,
    Looks like another one of those new trendy things that let people who cant program think they can program.

    - Just type blipetyblop., and you will have a complete system up and running.
    - Oh cool, my boss will be pleased!
    - Now type blippty-format-c-blop
    - Okidoki...

    Oh no, turns out the blipetyblop-framework has a vulnerability!

  17. Wetware still wet by Mats+Svensson · · Score: 1

    So the vulnerability, is that people who put unknown code in their systems sometimes gets screwed?
    Well, we better fix that then.

  18. Poor Post Title, Not-So-Severe Issue by Carcass666 · · Score: 1

    The OFA outlines this issue. What they are saying is that because the Swagger is a JSON document, if you use a code generator that simply regurgitates its values without validation, you could end up with code executing in the context of whatever is consuming the API. The issue is with code generators, and not the swagger documentation .

    An example they give as an attack on HTML is the following (with angle brackets instead of square ones, obviously):

    "info": { "description": "[script]alert(1)[/script]",

    I guess the idea is that you have used Swagger code generator to create code to call the RESTful APIs you are interested in. The code generator includes this description (which seems kind of odd) in the generated code, giving you an alert when a page including this code is loaded. They also give an example of attacking the "paths" property (which includes information on what URLs can be used to call specific APIs) which would execute code on the back end. I could see this being more a legitimate problem.

    A few things though before we all freak out:

    • If you are calling APIs from a party you don't know and trust, you are doing it wrong,
    • If you are calling APIs without reviewing them and their documentation, you are doing it wrong. If you are looking at a Swagger document and somebody put in an PHP or Ruby injection attack, it will stick out like a sore thumb.
    • For vulnerability to be exploited that party you trust with your data will have to insert malicious definitions into their Swagger file, and include enough definitions to attack all of the platforms that code will be generated for.
    • Because Swagger is now an open specification (Open API), the code generators in question can be updated pretty easily,

    Titles like ZDNet's "Severe Swagger vulnerability compromises NodeJS, PHP, Java" are gratuitous hyperbole. Slashdot's title is a little better because it at least refines the panic to "tools", but still not great. There is an issue here, but the internet is not going to go down in flames over this one.