Search the Community

Developing cloud-native applications involves establishing smooth and efficient communication among diverse components. To kick things off, let's delve into how a range of tools, from XML to gRPC, enable and enhance these critical interactions. XML (often with SOAP):<order> <bookID>12345</bookID> <quantity>2</quantity> <user>JohnDoe</user> </order>PositivesHighly structured: XML's structure ensures consistent data formatting. For instance, with <bookID>12345</bookID>, you're certain that the data between the tags is the book's ID. This reduces ambiguity in data interpretation. Self-descriptive: The tags describe the data. <user>JohnDoe</user> clearly indicates the user's name, making it easier for developers to understand the data without additional documentation. NegativesVerbose: For a large order list with thousands of entries, the repeated tags can significantly increase the data size. If you had 10,000 orders, that's 10,000 repetitions of <order>, <bookID>, and so on, leading to increased bandwidth usage. Parsing can be slow: For the same 10,000 orders, the system would need to navigate through each start and end tag, consuming more processing time compared to more concise formats. JSON (commonly with REST):{ "order": { "bookID": "12345", "quantity": 2, "user": "JohnDoe" } }PositivesLightweight and easy to read: The format is concise. If you had an array of 10,000 orders, JSON would handle it without the repetitive tags seen in XML, resulting in smaller data sizes. Supported by many languages: In JavaScript, for instance, JSON is natively supported. You can convert a JSON object to a JavaScript object with a simple JSON.parse() function, making integration seamless. NegativesDoesn't support data types natively: In our example, "bookID": "12345" and "quantity": 2 look different, but JSON treats both as text. This can lead to potential type-related bugs or require additional parsing. No built-in support for streaming: If you wanted to update book prices in real-time, JSON wouldn't support this natively. You'd need workarounds or additional technologies. GraphQL:Query: { order(id: "5678") { bookID user } }Response: { "data": { "order": { "bookID": "12345", "user": "JohnDoe" } } }PositivesFetch exactly what you need: If you had a mobile app with limited screen space, you could fetch only the necessary data, like bookID and user, optimizing bandwidth and load times. Single endpoint: Instead of managing multiple endpoints like /orders, /books, and /users, you'd manage a single GraphQL endpoint, simplifying the backend architecture. NegativesOverhead of parsing and processing queries: For each query, the server needs to interpret and fetch the right data. If you had millions of requests with varied queries, this could strain the server. Might be overkill for simple APIs: If you only needed basic CRUD operations, the flexibility of GraphQL might introduce unnecessary complexity. gRPC:Protocol Buffers definition: message OrderRequest { string id = 1; } message OrderResponse { string bookID = 1; int32 quantity = 2; } service OrderService { rpc GetOrder(OrderRequest) returns (OrderResponse); }PositivesEfficient serialization with Protocol Buffers: If you expanded globally, the compact binary format of Protocol Buffers would save significant bandwidth, especially with large datasets. Supports bi-directional streaming: Imagine you are having a feature where readers could chat about a book in real-time. gRPC's streaming would allow instant message exchanges without constant polling. Strongly-typed: With int32 quantity = 2;, you're ensured that quantity is always an integer, reducing type-related errors. NegativesRequires understanding of Protocol Buffers: Your development team would need to learn a new technology, potentially slowing initial development. Might be unfamiliar: If the team was accustomed to RESTful services, transitioning to gRPC might introduce a learning curve. Let's get to today's topic. What is gRPC?Imagine you have two computers that want to talk to each other. Just like people speak different languages, computers also need a common language to communicate. gRPC is like a special phone line that lets these computers chat quickly and clearly. In technical terms, gRPC is a tool that helps different parts of a software system communicate. It's designed to be fast, efficient, and secure. Instead of sending wordy messages, gRPC sends compact, speedy notes. This makes things run smoothly, especially when you have lots of computers talking at once in big systems like online shopping sites or video games. gRPC, which stands for Google Remote Procedure Call, is an open-source communication framework designed for systems to interact seamlessly. At its core, gRPC is about enabling efficient communication between computer programs, particularly when they're located on different servers or even across global data centers.Simplified Guide to gRPCImagine you have two friends, one who knows a secret recipe (let's call them the Chef) and another who wants to learn it (let's call them the Learner). However, there's a catch: they live in different towns. gRPC is like a magical phone that doesn't just let them talk to each other but also allows the Learner to watch and learn the recipe as if they were standing right next to the Chef in the kitchen. In the world of computer programs, gRPC does something quite similar. If you've created an app (which we'll think of as the Learner) that needs to use functions or data from a program on another computer (our Chef), gRPC helps them communicate effortlessly. Here's how it works: Defining the Menu: First, you tell gRPC about the dishes (or services) you're interested in, along with the ingredients (parameters) needed for each one and what you hope to have on your plate in the end (return types).The Chef Prepares: On the server (the Chef's kitchen), the menu is put into action. The server prepares to make those dishes exactly as described, ready to whip them up on request.The Magical Phone (gRPC): This is where gRPC comes in, acting as the phone line between the Learner and the Chef. It's not just any phone; it's a special one that can transmit tastes, smells, and cooking techniques instantly.Ordering Up: The Learner (client) uses a copy of the menu (known as a stub, but it's simpler to think of it as just a "client menu") to place an order. This "client menu" knows all the dishes the Chef can make and how to ask for them.Enjoying the Dish: Once the Learner uses the magical phone to request a dish, the Chef prepares it and sends it back over the same magical connection. To the Learner, it feels like the dish was made right there in their own kitchen.In technical terms, gRPC lets different pieces of software on different machines talk to each other as though they were part of the same program. It's a way of making remote procedure calls (RPCs), where the Learner (client) calls a method on the Chef (server) as if it were local. This magic makes building and connecting distributed applications much simpler and more intuitive. Technical AspectsHere's a closer look at its technical aspects. We'll consider a cloud-native application for a food delivery service. A user wants to order food from a restaurant using this app. Protocol Buffers: To represent an order, instead of a lengthy JSON, we use a concise Protocol Buffer definition. This ensures that the order details are transmitted efficiently between the user's device and the restaurant's system. message FoodOrder { string dishName = 1; int32 quantity = 2; string specialInstructions = 3; }gRPC uses Protocol Buffers (often shortened to "protobuf") as its primary mechanism for defining services and the structure of the data messages. Protobuf is a binary serialization format, making it both smaller and faster than traditional text-based formats like JSON or XML. Streaming Capabilities: As the restaurant prepares the order, the user can receive real-time updates on the cooking status. This is achieved using gRPC's streaming. This means the user gets instant notifications like "Cooking", "Packing", and "Out for Delivery" without constantly asking the server. rpc OrderUpdates(string orderId) returns (stream StatusUpdate);Language Agnostic: The user's app might be written in Java (for Android) or Swift (for iOS), but the restaurant's system uses Python. Thanks to gRPC's multi-language support, when the user places an order, both systems communicate flawlessly, irrespective of their programming languages. Deadlines/Timeouts: Imagine you're exploring new restaurants on the app. You don't want to wait indefinitely for results to load; you expect a prompt response. Here, gRPC's deadline feature plays a crucial role. When the app requests a list of restaurants from the server, it sets a deadline. This deadline is the app saying, "I can wait this long for a response, but no longer." For example, the app might set a deadline of 3 seconds for fetching the restaurant list. This deadline is communicated to the server, ensuring that the request is either completed in time or terminated with a DEADLINE_EXCEEDED error. This approach respects the user's time, providing a fail-fast mechanism that allows the app to quickly decide on an alternative course of action, such as displaying a helpful message or trying a different query. response = client.GetRestaurantList(timeout=3.0) In others, you might set a deadline based on the current time plus a duration: Deadline deadline = Deadline.after(3, TimeUnit.SECONDS); List<Restaurant> response = client.getRestaurantList(deadline); Closing RemarksWe've taken a trip through the world of communication tools in cloud-native app development, exploring everything from the structured world of XML, the simplicity of JSON, the flexibility of GraphQL, to the efficiency of gRPC. Each of these tools plays a key role in helping our apps talk to each other in the vast world of the internet. Diving into gRPC, we find it's more than just a way to send messages. It's like a bridge that connects different parts of our digital world, making it easy for them to work together, no matter the language they speak or where they are. To master the fundamentals of Cloud Native and Kubernetes, enroll in our KCNA course at KodeKloud: Explore the KCNA Learning Path. View the full article

Written by: Jacob Thompson The Apache XML Security for C++ library, code named xml-security-c, is part of the Apache Santuario project. The library implements the XML Digital Signature and the XML Signature specifications, making them available to C++ developers. By default, the library resolves references to external URIs passed in Extensible Markup Language (XML) signatures, allowing for server-side request forgery (SSRF). There is no way to disable this feature through configuration alone, and there is no patch available; the developer must either scan their codebase to find every usage of xml-security-c and override the URI resolver to avoid SSRF, or manually patch and recompile the library to remove the capability entirely. We recommend that C++ developers using XML audit their code bases for usage of this library and determine whether they have introduced a security vulnerability, and if so, modify their code to avoid SSRF. Background Server-side request forgery (SSRF) is a class of security vulnerability in which an untrusted party tricks a server into making an HTTP request by passing the server a malicious input. Although the attacker usually cannot view the response, requests to the loopback interface (127.0.0.1), RFC 1918 addresses (e.g., 10.0.0.0/8 or 192.168.0.0/16), or any other destination occur from the point of view of the server, allowing requests that would otherwise be restricted by firewall rules or that would be impossible to perform externally. Consider the obvious consequences if a server's uninterruptible power supply offers a web service bound to 127.0.0.1:8080 without authentication and that accepts a GET request http://127.0.0.1:8080/ups/changePowerState?state=off—and what happens if this service is reachable via server-side request forgery. The Extensible Markup Language (XML) is complex and contains many optional features that are not suitable or even useful in the common case of a server accepting untrusted XML documents on an external interface. Some allow cross-site request forgery just by initializing an XML parser in its default configuration and passing an untrusted document. For example, XML External Entities allow a document to define custom entity values (analogous to &lt; meaning < in HTML) to be replaced by the response from an external URL or the contents of a local file rather than a static string. Despite no real-world relevance to a server accepting and parsing untrusted, potentially malicious documents, this feature was enabled by default in many parsers and plagued the 2010s decade; XML External Entity Injection was promoted to an item in the OWASP Top Ten in 2017. Current versions of many XML parsers have now been hardened to treat support for external entities, document-type definitions, schemas, and so forth as an opt-in feature that is disabled by default. In this post, we present a different form of server-side request forgery affecting XML documents. We have found this issue being actively exploited; it was recently addressed by Ivanti in CVE-2024-21893. XML Signatures External URI Feature The XML Signature specification standardizes a way to digitally sign XML documents. The specification includes features that, from a security perspective, introduce additional paths to server-side request forgery into XML, beyond XML External Entity Injection. The XML Signature Syntax and Processing Version 2.0 specification states that "We RECOMMEND XML Signature applications be able to dereference URIs in the HTTP scheme," which, absent other protections such as egress firewall rules, allows for SSRF. This recommendation is carried over from version 1.1 of the specification and therefore version 1.x signatures are also affected. Figure 1 shows a simple XML document that, when parsed by xml-security-c version 2.0.4 and earlier, causes the parser to make an HTTP request to http://www.example.com/ssrf. <test> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm= "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#Manifest"/> <ds:Reference URI="http://www.example.com/ssrf"> <ds:Transforms> <ds:Transform Algorithm= "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm= "http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>AAAAAAAAAAAAAAAAAAAAAAAAAAA=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA==</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509SubjectName>CN=nobody</ds:X509SubjectName> </ds:X509Data> </ds:KeyInfo> </ds:Signature> </test> Figure 1: Sample XML document to trigger SSRF in affected xml-security-c library Prior Work Other open-source projects have already identified and modified their software to work around this issue. The Shibboleth xmltooling project reported a server-side request forgery vulnerability as CVE-2023-36661 and implemented a workaround in the xmltooling code to override the default, non-secure URI resolver in xml-security-c with a custom one that does nothing. While this mitigation is sufficient to resolve the issue in xmltooling—so long as every possible instance of xml-security-c is located and fixed—the root cause arguably lies in the xml-security-c library not being secure by default. Fixing the issue in xmltooling rather than upstream did not help other users of xml-security-c who were not aware of the need to reconfigure it. Dangerous XML features such as the ability to make external network requests just by parsing a document should, in our view, be disabled in the default configuration and then only enabled when parsing documents from a trusted source. In fact, a different library under the Apache Santuario project, Apache XML Security for Java, has a "secure validation" feature that is enabled by default. Among other characteristics, the secure validation feature "[d]oes not allow a Reference to call the ResolverLocalFilesystem or the ResolverDirectHTTP (references to local files and HTTP resources are forbidden)." Thus, Java developers, unlike C++ developers, are already protected against SSRF in the default configuration of the Java port of the library. The secure validation feature never made it to the C++ version. Disclosure Mandiant reported the non-secure default configuration in xml-security-c to the Apache Software Foundation (ASF). As external URI resolution is a legitimate feature in the XML Digital Signature specification, the ASF did not issue a CVE or a new release of xml-security-c. The Apache Santuario project did add a new disclaimer for xml-security-c shown in Figure 2, suggesting that XML Signatures and XML Encryption are difficult to implement securely; that xml-security-c is not secure by default and does not provide hardening configuration options; and that the library is not modular, making it difficult to ever add such features. Going forward, Apache Santuario is no longer supported as a standalone library, and the Shibboleth project will be taking over the project as a component of Shibboleth only. The developers suggest finding another solution. Figure 2: Apache Santuario added a disclaimer suggesting to not use the xml-security-c library Recommendations C++ developers should first scan their projects to determine if they use the Apache xml-security-c library. If so, the software may have a server-side request forgery vulnerability unless the code is patched. In some cases, usage of xml-security-c may be very limited, or it may be inconvenient to recompile the library when it is obtained in binary form. If developers can pinpoint each use of the XSECProvider class, they can call the setDefaultURIResolver method on the XSECProvider object, passing a custom implementation of XSECURIResolver that simply does nothing. This avoids the need to recompile xml-security-c and ensures the software remains secure if it is ever linked against the stock xml-security-c. An alternative, and in our view superior approach, is to patch the xml-security-c library to make it secure by default with regard to URI resolution. Mandiant developed a patch to supersede the vulnerable XSECURIResolverXerces with a new default XSECURIResolverNoop that does nothing, thus fixing the SSRF. By applying the patch and recompiling, the library will not be susceptible to this form of SSRF. Note that any legitimate uses of external URIs would need to be changed to manually specify XSECURIResolverXerces as the default URI resolver. The patch is available for download now (note: the download is a ZIP file, which contains the patch as a TXT file). View the full article

Amazon Translate – a fully managed neural machine translation service that delivers high-quality, affordable, and customizable language translation in 71 languages and variants –now supports translation of XML Localization Interchange File Format – XLIFF documents. Starting today, customers can submit their XLIFF documents for batch processing by Amazon Translate. Amazon Translate only translates sections where the target segment is empty. If the target section contains non-empty strings or pre-translated strings, Amazon Translate will not modify or overwrite the translation. You only pay for what you translate. This feature allows customers to continue using Translation Memory to translate content prior to machine translation and keep the machine translation costs low. View the full article