Security

Code scanning for vulnerability detection for exposure of security-sensitive parameters is a crucial practice in MuleSoft API development. Code scanning involves the systematic analysis of MuleSoft source code to identify vulnerabilities. These vulnerabilities could range from hardcoded secure parameters like password or accessKey to the exposure of password or accessKey in plain text format in property files. These vulnerabilities might be exploited by malicious actors to compromise the confidentiality, integrity, or availability of the applications. Lack of Vulnerability Auto-Detection MuleSoft Anypoint Studio or Anypoint platform does not provide a feature to keep governance on above mentioned vulnerabilities. It can be managed by design time governance, where a manual review of the code will be needed. However, there are many tools available that can be used to scan the deployed code or code repository to find out such vulnerabilities. Even you can write some custom code/script in any language to perform the same task. Writing custom code adds another complexity and manageability layer. Using Generative AI To Review the Code for Detecting Vulnerabilities In this article, I am going to present how Generative AI can be leveraged to detect such vulnerabilities. I have used the Open AI foundation model “gpt-3.5-turbo” to demonstrate the code scan feature to find the aforementioned vulnerabilities. However, we can use any foundation model to implement this use case. This can be implemented using Python code or any other code in another language. This Python code can be used in the following ways: Python code can be executed manually to scan the code repository. It can be integrated into the CICD build pipeline, which can scan and report the vulnerabilities and result in build failure if vulnerabilities are present. It can be integrated into any other program, such as the Lambda function, which can run periodically and execute the Python code to scan the code repository and report vulnerabilities. High-Level Architecture Architecture There are many ways to execute the Python code. A more appropriate and practical way is to integrate the Python code into the CICD build pipeline. CICD build pipeline executes the Python code. Python code reads the MuleSoft code XML files and property files. Python code sends the MuleSoft code content and prompts the OpenAI gpt-3.5-turbo model. OpenAI mode returns the hardcoded and unencrypted value. Python code generates the report of vulnerabilities found. Implementation Details MuleSoft API project structure contains two major sections where security-sensitive parameters can be exposed as plain text. src/main/mule folder contains all the XML files, which contain process flow, connection details, and exception handling. MuleSoft API project may have custom Java code also. However, in this article, I have not considered the custom Java code used in the MuleSoft API. src/main/resources folder contains environment property files. These files can be .properties or .yaml files for development, quality, and production. These files contain property key values, for example, user, password, host, port, accessKey, and secretAccesskey in an encrypted format. Based on the MuleSoft project structure, implementation can be achieved in two steps: MuleSoft XML File Scan Actual code is defined as process flow in MuleSoft Anypoint Studio. We can write Python code to use the Open AI foundation model and write a prompt that can scan the MuleSoft XML files containing the code implementation to find hardcoded parameter values. For example: Global.xml/Config.xml file: This file contains all the connector configurations. This is standard recommended by MuleSoft. However, it may vary depending on the standards and guidelines defined in your organization. A generative AI foundation model can use this content to find out hardcoded values. Other XML files: These files may contain some custom code or process flow calling other for API calls, DB calls, or any other system call. This may have connection credentials hard-coded by mistake. A generative AI foundation model can use this content to find out hardcoded values. I have provided the screenshot of a sample MuleSoft API code. This code has three XML files; one is api.xml, which contains the Rest API flow. Process.xml has a JMS-based asynchronous flow. Global.xml has all the connection configurations. api.xml process.xml global.xml For demonstration purposes, I have used a global.xml file. The code snippet has many hardcoded values for demonstration. Hardcoded values are highlighted in red boxes: Python Code The Python code below uses the Open AI foundation model to scan the above XML files to find out the hard-coded values. Python import openai,os,glob from dotenv import load_dotenv load_dotenv() APIKEY=os.getenv('API_KEY') openai.api_key= APIKEY file_path = "C:/Work/MuleWorkspace/test-api/src/main/mule/global.xml" try: with open(file_path, 'r') as file: file_content = file.read() print(file_content) except FileNotFoundError: except Exception as e: print("An error occurred:", e) message = [ {"role": "system", "content": "You will be provided with xml as input, and your task is to list the non-hard-coded value and hard-coded value separately. Example: For instance, if you were to find the hardcoded values, the hard-coded value look like this: name=""value"". if you were to find the non-hardcoded values, the non-hardcoded value look like this: host=""${host}"" "}, {"role": "user", "content": f"input: {file_content}"} ] response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=message, temperature=0, max_tokens=256 ) result=response["choices"][0]["message"]["content"] print(result) Once this code is executed, we get the following outcome: The result from the Generative AI Model Similarly, we can provide api.xml and process.xml to scan the hard-coded values. You can even modify the Python code to read all the XML files iteratively and get the result in sequence for all the files. Scanning the Property Files We can use the Python code to send another prompt to the AI model, which can find the plain text passwords kept in property files. In the following screenshot dev-secure.yaml file has client_secret as the encrypted value, and db.password and jms.password is kept as plain text. config file Python Code The Python code below uses the Open AI foundation model to scan config files to find out the hard-coded values. Python import openai,os,glob from dotenv import load_dotenv load_dotenv() APIKEY=os.getenv('API_KEY') openai.api_key= APIKEY file_path = "C:/Work/MuleWorkspace/test-api/src/main/resources/config/secure/dev-secure.yaml" try: with open(file_path, 'r') as file: file_content = file.read() except FileNotFoundError: print("File not found.") except Exception as e: print("An error occurred:", e) message = [ {"role": "system", "content": "You will be provided with xml as input, and your task is to list the encrypted value and unencrypted value separately. Example: For instance, if you were to find the encrypted values, the encrypted value look like this: ""![asdasdfadsf]"". if you were to find the unencrypted values, the unencrypted value look like this: ""sdhfsd"" "}, {"role": "user", "content": f"input: {file_content}"} ] response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=message, temperature=0, max_tokens=256 ) result=response["choices"][0]["message"]["content"] print(result) Once this code is executed, we get the following outcome: result from Generative AI Impact of Generative AI on the Development Life Cycle We see a significant impact on the development lifecycle. We can think of leveraging Generative AI for different use cases related to the development life cycle. Efficient and Comprehensive Analysis Generative AI models like GPT-3.5 have the ability to comprehend and generate human-like text. When applied to code review, they can analyze code snippets, provide suggestions for improvements, and even identify patterns that might lead to bugs or vulnerabilities. This technology enables a comprehensive examination of code in a relatively short span of time. Automated Issue Identification Generative AI can assist in detecting potential issues such as syntax errors, logical flaws, and security vulnerabilities. By automating these aspects of code review, developers can allocate more time to higher-level design decisions and creative problem-solving. Adherence To Best Practices Through analysis of coding patterns and context, Generative AI can offer insights on adhering to coding standards and best practices. Learning and Improvement Generative AI models can "learn" from vast amounts of code examples and industry practices. This knowledge allows them to provide developers with contextually relevant recommendations. As a result, both the developers and the AI system benefit from a continuous learning cycle, refining their understanding of coding conventions and emerging trends. Conclusion In conclusion, conducting a code review to find security-sensitive parameters exposed as plain text using OpenAI's technology has proven to be a valuable and efficient process. Leveraging OpenAI for code review not only accelerated the review process but also contributed to producing more robust and maintainable code. However, it's important to note that while AI can greatly assist in the review process, human oversight and expertise remain crucial for making informed decisions and fully understanding the context of the code.

In today's digital landscape, data privacy and accurate analytics are paramount for businesses striving to make informed decisions. Google Analytics 4 (GA4) brings a new dimension to data privacy and tracking methods, including cookie-less tracking and server-side tracking. Growing worries about privacy have prompted security rules from entities like the General Data Protection Regulation and the California Consumer Privacy Act. Responding to these regulations, Google has revealed its plan to disable third-party cookies by late 2023. Due to inadequate data gathering through cookies, businesses are encountering substantial setbacks in their marketing approaches. For instance, Facebook has projected losses of $10 billion due to the recent iOS data regulation policy. This post delves into the integration of server-side tracking and GA4, shedding light on how these innovations enhance data privacy and align with GDPR regulations. Google Analytics 4: Elevating Data Privacy and GDPR Compliance How Does Google Analytics 4 Improve Data Privacy With GDPR Compliance? Google Analytics 4 (GA4) is a significant evolution from its predecessor, Universal Analytics, designed to prioritize data privacy and compliance with GDPR regulations. It employs an event-based model rather than relying heavily on cookies, which assists data privacy. This model reduces the reliance on personal identifiers, which enhances user anonymity and minimizes risks associated with tracking. Event-Based Model and Data Minimization As mentioned above, GA4 embraces an event-driven tracking approach, which allows website owners to define and track events that matter most to their business objectives. This shift reduces the need for collecting and processing personally identifiable information (PII). Instead of extensive user-level data, GA4 focuses on aggregating event data, which makes it harder to trace actions back to individual users. Enhanced Consent Management GA4 offers improved consent management tools, allowing businesses to collect user consent for tracking and data processing activities. This aligns perfectly with GDPR's requirement for obtaining explicit user consent before data collection and processing. These consent features empower users to have more control over their data, which contributes to a more transparent and compliant tracking environment. How Does Cookie-Less Tracking Work in Google Analytics 4? GA4 has introduced cookie-less tracking in its plethora of features, which is a revolutionary approach in the realm of data privacy. Event Tracking and User-Centric Approach Google Analytics 4 utilizes events to track user interactions, such as clicks, page views, and conversions. These events are attached to a unique user ID, which will help understand user behavior without relying on third-party cookies. This not only respects user privacy but also provides valuable insights into user journeys. Machine Learning and User Predictions The machine learning capabilities in GA4 can be used to predict user behavior and trends based on event data. This allows businesses to understand user intent and preferences without compromising individual identities. These predictions are based on patterns observed across multiple users, ensuring anonymity. Server-Side Tracking in Google Analytics 4 What Is Server-Side Tracking in Google Tag Manager? The adoption of server-side tracking is a game-changer in analytics. It has shifted the processing of tracking data from the user's browser to a server, reducing the exposure of user data to potential vulnerabilities. Reduced Reliance on Client-Side Data Server-side tracking minimizes the reliance on client-side data processing, making it less susceptible to ad blockers and browser restrictions. This method ensures that essential data reaches the analytics platform even when users have stricter privacy settings. Enhanced Security and Data Privacy The most significant benefit of SST is that it enhances security by reducing the risk of data breaches and unauthorized access. It aligns with GDPR principles by decreasing the amount of user data sent to third-party platforms, fostering a more privacy-centric approach to analytics. Integrating Server-Side Tagging With Google Analytics: A Complete Guide The final piece of the puzzle is integrating server-side tagging with Google Analytics. Set up a Server Container To begin, set up a server container in Google Tag Manager. This container acts as a middleman between your website and the analytics platform, receiving and forwarding tracking data. Configure Server-Side Tags Configure tags within the server container to define the events you want to track. This allows you to have more control over the data that is sent to GA4 while adhering to data privacy regulations. Map Data and Test Map the data you want to send to GA4 in the server container. Thoroughly test the setup to ensure that the correct data is being transmitted accurately and securely. Monitor and Optimize Regularly monitor the data flow and make necessary optimizations. This iterative process ensures that your server-side tracking and GA4 integration remain effective and compliant. Conclusion Google Analytics 4, combined with server-side tracking, ushers in a new era of data privacy and analytics. By embracing event-based models, cookie-less tracking, and server-side methodologies, businesses can adhere to GDPR regulations while gaining meaningful insights into user behavior. As the digital landscape continues to evolve, this powerful synergy ensures that data privacy remains a top priority without compromising the value of analytics.

In this 15-minute lightning talk, Diptesh “Dips” Mishra, CTO for Shoal (a Standard Chartered Venture) talks about the governance challenges that financial services organizations face when they look to adopt DevSecOps. Dips has worked for Nationwide, Lloyds Banking Group, and RBS and he’ll share key strategies behind successful implementations. Transcript I’ve been in financial services looking at the overlap between regulations and DevSecOps over the last six years. It’s been an interesting journey, and I’ve looked at it from the startup lens, both within larger corporate banks, more traditional investment banks, and retail banks, but also upcoming startups, starting from pre-seed seed grounds. My last role before Shoal was at Kroo Bank, where we built a digital bank in the UK from scratch, which is one of the most highly regulated environments. And now I’m at Shoal, where we are building a sustainability marketplace, where we are going to offer financial services products, but with a sustainability angle to it. It’s part of Standard Chartered bank, so we have all the regulations that we need to comply with. Hopefully I’ll keep it nice and interesting — let’s see how much I succeed! As you can get from the theme, it’s based on Alien vs. Predator. Can I get a quick show of hands from everyone who has at least seen one of the movies or the game? Great, thank you, that really helps — I was worried for a bit! So there’s this complex dichotomy between regulations and DevSecOps, and if you have been in modern financial services organizations, you can’t really escape it. It’s constantly there, be it whether you’re a fintech startup, a scale-up, a traditional or digital bank, retail private investment, in central banks — irrespective of what you do, you have got those challenges and it’s about picking a side, right? Before we pick any sides who you think might come out on top, it’s probably worth thinking about what each one of them are and their salient points, right? Regulations: why do people love them? They’re very well defined, clearly documented, there’s limited scope of interpretation. So you know exactly what you are going to get, what you need to do, right? There’s less room for interpretation there. DevSecOps on the other hand: it’s a bird, it’s a plane, no, it’s an alien! Even Superman is an alien for those who don’t know the full story. So it’s one of those where people are still trying to agree on one term for DevSecOps. If all of us went into a room and everyone had to write what they thought the definition of DevSecOps was, I’m sure we’d probably have tens of different answers in the room. Who are the main cheerleaders, the fan groups that drive regulations? You’ve got the regulators themselves obviously; you’ve got the people who hold senior management functions as part of the senior management certification regimes; risk and compliance teams (every single regulated organization has them: the gatekeepers, the change haters, they’re known by different names, none of them were given by me!); and then you’ve got DevSecOps. Who are the cheering squad for them? You’ve got digital and cloud-natives, you’ve got startups, as well as established tech behemoths like the FAANG organizations who are big, big proponents of it. You’ve got the disruptors, you’ve got agile coaches who are coming into organizations and saying: “You should have DevSecOps!” And of course you have got tooling companies, not naming anyone. But at the same time, there are some common themes here. They’re not entirely different, but the regulators and DevSecOps see that it’s non-negotiable: you absolutely must have us for regulations. It’s about the license to operate. You’ve got a mandate from the regulators within your jurisdiction and you need to be compliant with those regulations to operate. Similarly on the DevSecOps, it’s about being agile, but able to promote continuous changes quickly and efficiently. And so there are some common reasons they both think it’s non-negotiable, but at the same time, it’s about making sure that they have different reasons for it. Final part before we kick off the battle, the weapons! What do they bring to the table? So DevSecOps have got agile and digital transformation on their side. They’ve got innovation, that’s the new kid on the block. The most important weapon at their disposal is DevSecOps tooling. Now, please don’t strain your eyes trying to understand any or all of it — I’m sure you’ll find it online. But the idea is there’s a growing plethora of different tools, new ones coming up every day, all of which provide different and new features as part of it, right? It’s a proper sprawl. Regulations: what are their weapons? You’ve got forms, forms, more forms, death by forms. It starts with frameworks, you’ve got policies, controls, and audits. So there are different aspects that you would have all come across in any regulated space. What’s their nuclear weapon? You do not have our approval to deploy to production. That one sentence just kills everything. So that’s their main weapon. But is it really a fight? We have looked at how they are set up. We have seen they are potentially trying to achieve different goals and objectives. But are they really completely opposites? Can we not come to a middle ground somewhere? Let’s take a step back and think about where they are coming from — what are the drivers? And that’s one of the cool aspects, like when you get into a conflict resolution mode where you’ve got different viewpoints, you take a step back and start from the beginning, see where the people’s viewpoints are coming from. The regulations have a duty of care which starts from a good place — they want to protect the customers, but at the same time, some of it you sometimes wonder, "Are they doing this to protect the system itself?" They love inertia. A majority of these issues that you see are caused by deployments or releases. Any changes you make to the system are very likely to have been the cause of problems. And of course they want to ensure there are proper processes, governance, and controls. In terms of DevSecOps, they’ve come from that mindset of being lean, having principles like the ability to fail fast, test and learn, continuous rapid change, almost on an ongoing basis. And lots and lots of automation. Does anyone recognize this? This is the famous Agile Manifesto. Some of it has been lost over the years in translation, where people think that what was meant was only the things on the right are important. So while the manifesto itself was very clear that while the things on the left are also important, those on the right are the ones we would look to do more of. But some of the things, like if you talk about a plan in an agile organization, you’ll hear things like, “We don’t do any plans, there is no need to plan, we are fully agile!” That’s not what is meant. Same for documentation — we have working software, our code works, right? But it doesn’t say don’t document anything. So there is room for all of the eight elements on this, and that’s kind of where you start looking at what’s the common ground, where do you get regulations which are kind of represented on this side to work with those from DevSecOps? So now that we understand a bit more about them, perhaps we can negotiate? So to start with, we can look at testing everything. Figure out how we test — that can be a whole topic in itself, right? We were just discussing during the break that you can test everything, have 100% good coverage, every single test passing, but actually not test anything useful. So there is a lot to be done in that space. It’s about continuously learning in all environments. That is another area where if you look at changes that fail, once you get your pipeline and your processes sorted in terms of automation, one common thing that’s still different across environments are things like configuration. You will have a very different configuration in your production environment than what you would have in staging. And that might mean because you are connecting to a different backend, it could be because you have a third party system that has a sandbox and a production environment that’s separate. Any of those will give you differences and it’s about how you test work across these environments. And work hard to avoid failing — what people who are on the regulation side do not like is a more loose attitude where people are like, “It’s OK to fail.” But it is OK, and that’s where the psychological safety of the team and understanding of that comes in. But it’s not an excuse for taking things lightly or not being diligent about "Have you tested everything? Have you talked about possible exception and error scenarios?" So it’s about working through those. And when you do fail, fix it, learn it, and then work harder for next time Continuous everything — one important part for this one is regulations. People think regulators have a lot of inertia, or risk and compliance have a lot of inertia to change. But inertia is not just about being addressed. It also can be about uniform motion. So you can actually move towards a continuous compliance pipeline which enables these to move at pace. And yes, automation of processes, governance, and controls. I think that’s the recurring theme that you will see today at least. So what does it take? You’ve got fully engaged organizations — who must have buy-in from the leadership all the way to the grassroot levels. You can’t bring them to the table without one or the other. You need to have empathy and patience. That’s a key part of leadership. It enables teams to understand each other, different viewpoints, and it requires a lot of work. Regulations have been built up over decades, sometimes even centuries, right? DevSecOps hasn’t had that many years to grow. If we had to work together, empathy and patience are both important from all sides. And having a structured process. Think about what the requirements are. What are we trying to achieve? At the end of it, we are trying to release a deploy code. That code itself has a purpose. Why is it needed? What happens if it is not there? So every time we come across a control, think about being clear around why it is needed. An important question is: if I now remove the control away, what is it that can happen? What are the risks? And the third part is where it starts getting interesting. How can these requirements be achieved? That’s an open-ended question, but sometimes you might get the standard answer: fill out this form. By the time you complete this process, you will be well set. But what is it that filling out that form achieves? So the second question comes in: what are the different ways in which this requirement can be achieved? If you ask everyone who has a different viewpoint, you will get different answers, but in the end you will be better off because you can understand that there’s not just one way — which is a document-driven Excel spreadsheet based on some system where you need to fill out forms — it’s where you can bring different types of automation into place as well. Finally, what would provide assurance on the effectiveness of controls, governance, and processes? That’s the most important part from a regulatory standpoint, but that’s what we’re trying to achieve through automation. And so again, you boil it down to what are the outcomes and key results that we are looking for? And once you’ve got all of these answers, it’s just figuring out the next steps: who is going to do what and by when? How long does it take? It takes forever. It’s a continuous process, right? It’s the journey. There is no final destination here. It’s about making sure the journey is as enjoyable for the alien as well as the predator. So where do we start? Why not define and start with an MVP? Define the minimum process that you need, pick up one that you think you can automate, figure out how automated governance can be introduced in that area, and then maybe you can get them both to sit across the table from each other and play a nice game of chess instead! And that’s it from me. Thank you very much.

Over the past several years, Zero Trust Architecture (ZTA) has gained increased interest from the global information security community. Over the years, several organizations have adopted Zero Trust Architecture (ZTA) and experienced considerable security improvements. One such example is Google, which implemented a BeyondCorp initiative embodying ZTA principles. The tech giant removed trust assumptions from its internal network, focusing instead on verifying users and devices for every access request, regardless of their location. This transformation has allowed Google to offer its workforce more flexibility while maintaining robust security. We also see relevant guidelines emerging from commercial entities and government bodies. Specifically, a memorandum was released detailing recommendations for US agencies and departments on how to transition to a "Zero Trust" architecture. Let's delve into a brief overview of ZTA. Key Considerations in Adopting a Zero Trust Architecture The core idea of this architecture is not to mindlessly trust any entity, system, network, or service, whether they are within or outside the security perimeter. Instead of granting access freely, every interaction should be rigorously checked. This marks a significant shift in the way we approach the protection of our infrastructure, networks, and data: from a single perimeter check to a continuous, detailed inspection of every device, user, application, and transaction. This ensures that the targeted information system always possesses comprehensive information about the party involved during the authentication/authorization phase. Furthermore, applications should not depend on network perimeter security to prevent unauthorized access. Users should log directly into applications and not entire networks\systems. In the immediate future, we should consider every application as potentially accessible over the Internet from a security standpoint. As organizations adopt this mindset, it is anticipated that the requirement to access applications through specific networks will no longer be necessary. Numerous tools can assist with ZTA implementation, such as network security solutions like Next-Generation Firewalls (NGFWs), Secure Access Service Edge (SASE), and Identity and Access Management (IAM) software. Additionally, resources like NIST's SP 800-207 Zero Trust Architecture document can provide further in-depth understanding and guidelines for ZTA adoption. Several approaches to building a ZTA exist advanced identity management, logical micro-segmentation, and network-based segmentation. All approaches aim to isolate systems as much as possible so that an attacker who compromises one app cannot travel within the organization and compromise other sectors. The transition of an organization to Zero Trust Architecture (ZTA) looks like this: The process of managing employee accounts ensures they have all the necessary resources to perform their duties while following the principle of least privilege. The devices that employees utilize for their job tasks are under constant supervision and control. The security status of these devices (configuration, patch level, integrity, etc.) plays a significant role when it comes to granting access to internal resources. The organization's systems are kept isolated from one another, and any network traffic circulating between or within these systems is both encrypted and authenticated. Applications used within the enterprise undergo both internal and external testing. Platforms such as GitLab are essential for upholding the top standards of DevSecOps principles. The organization's security teams are responsible for establishing data categories and setting security rules in order to automatically identify and prevent any unauthorized access to sensitive information. The transition to ZTA should be considered through the prism of the following key areas: identities, devices, networks, applications, and data. Let's briefly review each of them. Identities A centralized identity management system needs to be implemented across the organization. It is crucial to apply robust multi-factor authentication (MFA) throughout the enterprise. When granting users access to resources, at least one device-level signal should be taken into account, along with the authenticated user's identity information. The level of risk associated with accessing an application from a specific corporate network should be seen as no less than accessing it from the Internet. Devices The organization must keep a comprehensive inventory of all authorized devices currently in use. Moreover, it is vital that the organization can effectively prevent, detect, and respond to any incidents involving these devices. Network Organizations should aim to encrypt all traffic whenever possible, even when data travels within internal networks and client portals. It is important to actively use strong encryption protocols like TLS 1.3. The underlying principles of these protocols should be taken into account, especially for minimizing the number of long-term keys. A leak of any of these keys could pose a significant risk to the entire system's operation. Applications Organizations need to operate dedicated programs for testing application security. In case of a shortage of expertise, it is always a good idea to seek high-quality, specialized software testing services for independent third-party evaluations of application security. It is crucial for organizations to manage a responsive and open public vulnerability disclosure program. While deploying services and products, organizations should strive to use immutable workloads, especially when dealing with cloud-based infrastructure. Data It is vital to set up defenses that utilize comprehensive data categorization. Leverage cloud security services and tools to identify, classify, and safeguard your sensitive data while also implementing logging and information sharing across the entire enterprise. Companies should try to automate their data categorization and security responses, particularly when regulating access to sensitive information. Regularly audit access to any data that is at rest or while it is being transmitted on commercial cloud infrastructure. Common Challenges and Solutions The transition to ZTA is not without its hurdles. One significant challenge is the potential for increased complexity and operational overhead. Managing numerous security configurations, encryption protocols, and access control lists can be daunting. However, automated security solutions and centralized management systems can help streamline the process and reduce human error. Another common issue is resistance to change within the organization. The shift to ZTA can be disruptive, requiring changes in company culture and workflows. This challenge can be mitigated through comprehensive training programs, clear communication about the benefits of ZTA, and gradual implementation strategies. Conclusion Traditional security architectures operate on the assumption that all data and transactions are secure by default. Yet, incidents such as data breaches and other compromises can shatter this trust. Zero Trust Architecture revolutionizes this trust model, starting with the presumption that all data and transactions are potentially untrustworthy right from the outset. Adopting ZTA provides numerous benefits, such as improved security posture, reduced risk of data breaches, and flexibility in accommodating remote work or BYOD policies. However, it does come with potential drawbacks. The cost and complexity associated with the initial implementation can be high, and there is the risk of potential service disruption during the transition. To mitigate these drawbacks, companies considering ZTA should begin by assessing their current security posture and then identifying areas where ZTA principles could be initially applied while also building a roadmap for a full transition.

On July 11, 2023, Microsoft released details of a coordinated attack from threat actors, identified as Storm-0558. This state-sponsored espionage group infiltrated email systems in an effort to collect information from targets such as the U.S. State and Commerce Departments. While this was a fairly sophisticated attack leveraging multiple vulnerabilities, there are multiple lessons we can take from this incident to help any DevOps and security team improve their organization's security posture. What Happened Starting on May 15 of this year, the China-based state actor identified as Storm-0558 gained access to Azure-based Office 365 email systems. The attack was discovered after Office 365 customers began to report unusual mail activity. On June 16, Microsoft began the investigation and remediation process. Microsoft discovered that the access keys used were not actually issued by their organization. Instead, Storm-0558 had forged keys using a stolen Microsoft account (MSA) consumer signing key to create fake Azure Active Directory (AD) private keys. At the same time, they exploited a now-patched vulnerability that had allowed keys to be used across multiple systems. There is an excellent blog post from Prof Bill Buchanan OBE, "Losing The Keys To The Castle: Azure Key Breach Should Worry Every Organization," that goes into more detail on how token signing works and how this attack succeeded. More technical details about the incident can be found in the Microsoft incident analysis. What You Can Do Microsoft reported that they found no evidence indicating any additional unauthorized access after they completed their mitigation efforts. If you are a Microsoft customer, they assure us there is no further reason for alarm. Their team identified several places where they needed to improve security, including increased isolation of the systems, refined monitoring of system activity, and moving to consistent use of their enterprise key store. Let's take a closer look at these and other lessons we can take away from this incident to help us all stay safer. Listen for Reports of Anything Suspicious One fact that stands out in all the reporting is that the attack was not discovered by internal scanning or alarms; it was first identified by users who noticed something wrong. There is real value in listening for user feedback for indications something might be happening. Just as only relying on human reporting is not a good solution, overly relying on just automated alerts is just as flawed. Remind customers and internal team members to report anything out of the ordinary when using your product. Not only can this help with security, but it can also help find and squash other non-security bugs. Review playbooks regularly to make the process of spotting possible security issues and the escalation routes are clear and up to date. You want your customer success teams and security teams to work together to identify potential security issues. Store All Keys Safely When Microsoft’s team first investigated the situation, they assumed that the attackers were using stolen customer keys. There is a very valid reason why they would think this, as the issue of secret sprawl continues to grow. There was a key that was stolen. However, it was not the end user keys; it was the key used to verify that the credentials were legitimate. Still, no matter how powerful any credential is, it is still a key that needs to be properly stored, which means encrypting them. While we don't know exactly how this key was acquired, based on certain statements about improved use of their "enterprise key store" can lead us to ponder how these very important signing keys were stored. Storing keys in a vault system, such as Vault by Hashicorp, Azure Key Vault, or Doppler, provide a lot of security advantages. Encryption at rest: The keys are stored in an unreadable and unusable state. Programmatic access: Only references to the secret within the vault are ever shared in the codebase. Encryption in transit: Keys are only unencrypted upon arrival, at runtime. Access and change management logging: From a central location, you can see who has added or modified any credential, as well as when keys were accessed. Another approach that is worth considering is storing secrets in a Hardware Security Module (HSM). As the name suggests, an HSM requires additional hardware in your infrastructure, which can provision, store, and manage cryptographic keys. HSMs can provide additional security layers within their physical architecture that can go beyond what can be accomplished in software alone. Do Not Reuse Keys for Multiple Services Another reason the attackers were successful during this breach was that the keys for one system could grant access to multiple other systems. The lesson from this vulnerability is that every key should be unique and specific to one job, what they referred to as "isolation of the systems." When dealing with complex DevOps environments, it can be tempting to think that because someone or something was allowed access to one trusted service, they should be allowed access to other sensitive systems. This is always a bad decision from a security standpoint. Attackers will almost always try to laterally move throughout an environment, and they know how common it is to reuse credentials. They will most assuredly try to use the same credentials that worked once at every other lock they encounter. Tightening the scope of your credentials to only allow just the minimum access needed to complete the work is at the core of the Zero-Trust architectural philosophy. Just as reusing your passwords is bad, widely scoped credentials that allow access to multiple systems are also something to avoid. Regularly Check Your Logs One of the first steps the Microsoft team took in their investigation was to examine the logs to identify when unexpected access occurred and what keys were used. Logs can provide a lot of information after an incident once the attack is over, but they can help identify an attack in progress as well.If regularly reviewing your access logs is not part of your security practice, adding this step to your daily or weekly tasks is a great step in the right direction. There are many solutions on the market to assist with log monitoring, such as Sumo Logic and Datadog, which can identify and surface unusual activity much faster. It is your data, and you are already collecting it; make sure you are taking advantage of it. Hone Your Secrets Rotation Plan A major part of Microsoft's remediation of the incident was the revoking and replacement of their signing keys. No matter what key has been compromised, key rotation is central to any incident response plan. One of the clearest signs of expert Secret Management Maturity is when secrets are scheduled for regular automated rotation. Most cloud providers, like AWS, make automated key rotation a straightforward process. If you are not quite ready to embrace automatic rotation, then you should be striving for at least regular rotation. The more often you rotate credentials, especially when there is no real pressure and lower stakes, will make it all the easier to rotate them when an indecent occurs. Actively Monitor for Credentials in Your Environments Knowing about a stolen secret only after the attack means knowing too late. One of the best ways to keep safe is to be aware when your keys become exposed as plaintext at any point in the software development lifecycle. This is where tools like GitGuardian Secret Scanning are needed. GitGuardian does a historical scan of each repository in your perimeter when they are added, giving you a baseline of what secrets exist in your code history, in every branch, and in every commit going back to the beginning of the project. Keeping All Your Secrets Secret Is Important While the attack on Microsoft customers from Storm-0558 relied on a number of specific vulnerabilities, there are still some valuable lessons we can all take away. Consistently storing all your secrets properly is a very good start. Remember to properly scope any credential to only one use case and never reusing them across multiple services will help make sure if an attack based on leaking a key does occur, access will be extremely limited. Regular rotation of keys as well as active monitoring for unusual activity in your logs is critical for keeping safe in a world of ever-evolving security challenges. Being alerted to plaintext credentials in your environments will help keep you one step ahead of attackers. Remember, security is a journey; nobody knows all there is to know on the topic. Make steps in the right direction at every opportunity to increase your security posture.

In today's interconnected global marketplace, secure data transmission is more crucial than ever. As digital platforms become increasingly important for financial transactions and personal communications, ensuring the integrity and confidentiality of data is vital. If someone gets unauthorized access to data, it can be not good. If someone gains unauthorized access to data, it can be not good. It can cost a company money, ruin its good name, and make customers lose trust. This article explores the best practices for ensuring secure data transmission, offering valuable insights for anyone engaged in online activities, whether a multinational corporation or an individual consumer. Why Secure Data Transmission Matters The significance of secure data transmission goes beyond just keeping sensitive information out of the wrong hands. It is a cornerstone of business integrity and a key to competitive advantage in a rapidly evolving digital landscape. As companies extend their reach globally, they frequently exchange data across different authorities, each with its regulations and potential vulnerabilities. Secure data transmission is not just about preventing financial loss through fraud or data theft; it is also about regulatory compliance, protecting intellectual property, and maintaining customer trust. Businesses considered secure are more likely to attract customer engagement, and this perception directly affects a company's bottom line. In an age where data breaches are becoming increasingly common and costly, the ability to transmit data securely is not just an operational requirement but a critical business strategy that can differentiate a company in a crowded market. Understanding Data Encryption Data encryption is the bedrock of secure data transmission. Intelligible data is transformed into an incomprehensible format, which can only be deciphered by authorized individuals using the correct "key" through encryption. There are various methods of encryption, including symmetric and asymmetric algorithms. It is faster to encrypt and decrypt data using the same key but potentially less secure if compromised, a characteristic of symmetric encryption. On the other hand, a pair of keys are used for decryption and encryption — a public key is utilized for encrypting the data, while a private key is employed for decryption — adding an extra layer of security, a feature of asymmetric encryption. The choice between these methods often depends on a business's specific needs and operational intricacies. Understanding data encryption is not just a technical exercise; it is a strategic imperative for any company operating in a global marketplace. Adequately implemented encryption protocols safeguard against unauthorized data interception, thus ensuring both compliance with regulations and protection against malicious attacks. Role of Virtual Private Networks (VPNs) Virtual Private Networks (VPNs) significantly ensure secure data transmission, particularly in a global marketplace where data often travels across different networks and authorities. A VPN establishes a secure tunnel for transmitting data over the internet, preventing unauthorized access or tampering. It encrypts your internet traffic, masking your IP address, and effectively shields your activities from prying eyes. For businesses, using a VPN adds an extra layer of security crucial for protecting sensitive information and complying with data protection laws. In an increasingly interconnected world, VPNs are vital to a robust data security strategy. Importance of Secure Socket Layer (SSL) and Transport Layer Security (TLS) TLS and SSL are cryptographic protocols that secure data transmission over the Internet. They are most recognized in the context of HTTPS websites, signified by a padlock symbol in the web address bar. SSL and TLS encrypt data packets between web browser and server, ensuring that any sensitive information — such as credit card details, personal identification, or proprietary business data — is secure from unauthorized access or tampering. For businesses operating in a global marketplace, employing SSL/TLS is not just best practice; it is essential for maintaining customer trust and regulatory compliance. EDI Compliance and Its Significance EDI compliance refers to the adherence to proven standards and protocols for Electronic Data Interchange (EDI). Businesses can use this system to exchange documents in a standardized electronic format. This ensures efficient and streamlined communication between different parties. In secure data transmission, being EDI compliant is particularly significant for companies operating in a global marketplace. EDI standards ensure smooth transactions, reducing human error and increasing efficiency. Additionally, being EDI compliant often means adhering to specific security measures, such as encryption and secure channels for data transmission, enhancing the overall integrity and safety of the data being exchanged. Multi-Factor Authentication (MFA) This requires multiple forms of identification to access an account or system. In addition to something you know, such as a password, MFA often involves something you have, like a mobile device, for a verification code, or something you are, such as a fingerprint. Implementing MFA is crucial in securing data transmission in a global marketplace. Adding an extra layer of security significantly increases the difficulty for unauthorized users to access sensitive data. MFA is highly effective in thwarting cyberattacks like phishing and credential stuffing, making it a best practice for businesses prioritizing secure data transmission. Secure File Transfer Protocols (SFTP and FTPS) Secure File Transfer Protocols like SFTP (Secure File Transfer Protocol) and FTPS (FTP Secure) are essential tools for transmitting data over a network safely. SFTP encrypts commands and data, effectively protecting against common cyber threats like data interception and unauthorized data access. FTPS, however, uses SSL (Secure Sockets Layer) encryption to secure the data channels. Both are significant upgrades over traditional FTP, which is not encrypted. Utilizing SFTP or FTPS is crucial for businesses operating in a global marketplace where data breaches can have severe repercussions. These protocols ensure that files containing sensitive information reach their intended destination securely. Legal Compliance and Global Regulations Adhering to legal compliance and global regulations is a business imperative, not just a matter of good governance. Laws such as GDPR (General Data Protection Regulation) in Europe and CCPA in California set stringent standards for data protection. Non-compliance not only risks heavy fines but also damages a company's reputation. These laws often mandate Secure data transmission protocols, making them essential for global business operations. Conclusion In an ever-connected global marketplace, the importance of secure data transmission cannot be overstated. Businesses must stay vigilant, from understanding the nuances of data encryption to implementing advanced measures like VPNs and multi-factor authentication. Considering the critical role of EDI compliance and adhering to international data protection laws, companies must be bold about their data security strategies. Ignoring these best practices could result in financial and reputational losses that are difficult, if possible, to recover from. Adopting a comprehensive approach to secure data transmission is more than just innovative business; it is a non-negotiable necessity.

When I was a teenager, our local telephone company introduced a new service — the premium phone calls (AKA 1-900 numbers). The fun part was that we discovered a workaround to these charges by dialing the sequential local numbers, which these 1-900 numbers would redirect to. If the "support number" for the 1-900 was 555-555, we would dial every number between 555-455 and 555-655 until we hit the jackpot... Hours were spent dialing these numbers, leading us to make numerous calls for free. This attack is still prevalent today, and it's called Insecure Direct Object References (IDOR). IDOR In the digital world, IDOR is similar to our teen exploits. It means trying various ID numbers in sequence until we find the right one. A few years ago, a social network named Parler, which listed users by a sequential numeric ID, fell victim to this type of attack when a user was able to request and download the full list of users on that network. E.g., their URLs looked like: https://site.com/viewUser?id=999 All a person needs to do is loop over valid sequential numbers and send the request to get the user information of everyone on that site. This is trivial and can be accomplished by anyone with relatively low technical skills. To avoid such an attack, it is advised not to expose guessable or sequential numeric IDs to the end users. While UUID might seem long, it offers a more secure alternative. Additionally, request checking should be implemented. If a user is requesting information about a user they aren't connected to, that request should be blocked. Other effective mitigations include setting request quotas and delays between requests to prevent a massive data grab. I won't go into these since they are typically implemented in the API gateway layer during provisioning. You can write this in code, but it's a challenging task as you might have many endpoints with a great deal of complexity. The rule of thumb is to write as little code as you possibly can. More code means more bugs and a wider attack surface for a malicious hacker. Vulnerabilities and Exploits A crucial term in application security is vulnerability. It's a weakness or bug that can be likened to a hole in the fence surrounding your house. These vulnerabilities can reside in your code, libraries, Java itself, the operating system, or even physical hardware. However, not every vulnerability is exploitable. Just like a hole in your fence may not necessarily grant access to your house, vulnerabilities don't always mean your code can be hacked. Our aim is to plug as many holes as possible to make the task of exploiting our system more difficult. I know the onion metaphor is tired by now but for security, it makes a lot of sense. We need to enforce security at every layer. In the Log4Shell exploit that was exposed last year, we had a major zero-day vulnerability. A zero-day vulnerability is a newly discovered vulnerability that no one knew about before, like a new hole in the fence. The Log4Shell vulnerability relied on people logging information without validating it first. This was a bad practice before the vulnerability was known. If you used a Log4J version that had that vulnerability but sanitized your data. You would have been safe despite that vulnerability. SQL Injection SQL injection involves building your own queries by concatenating a query string manually. Let's look at vulnerable SQL like this: String sql = "SELECT * from Users WHERE id = " + id; Considering the sample URL we used before, we could request a URL like this: https://site.com/viewUser?id=1 OR true=true. This URL would result in an attacker fetching all the users as the condition will become: SELECT * from Users WHERE id = 1 OR true=true Which is always true. This is a relatively tame outcome. SQL statements can be chained to drop tables, deleting the entire database. A solution to this is using the prepared statement syntax, where the implementation treats all the content as a string. This prevents the SQL keywords from being exploited, e.g.: PreparedStatement sql = connection.prepareStatement("SELECT * from Users WHERE id = ?"); sql.setString(1, id); In this situation, when we set the value for the id, it will treat it as a string, even if there are SQL keywords or special characters. Using APIs like JPA (Spring Data, Hibernate, etc.) will also protect you from SQL injection when using similar APIs. Serialization Java serialization is another common vulnerability. The lesson here is to avoid using serialization or requiring it and instead run your app with a filter that blocks certain types of serialization. This is something I discussed in a previous post, so there's no point repeating it. Cross-Site Scripting (XSS) Cross-site scripting, or XSS, is a complex attack. It involves injecting malicious scripts into websites that then run on every person's browser visiting the page. This can lead to the theft of user cookies, which in turn allows the attacker to impersonate users on the website. Protecting against XSS involves validating user-supplied data, treating it as display content, not executable code. Let's say I have a submit form that accepts user input that is saved to the database. Like the comments section in the blog. I can post in JavaScript code that would submit the user's cookies to a site I control. Then I can steal this information and impersonate a user. This is a very common and surprising attack. It's often performed by encoding the script into a link sent by email. These are three types of XSS attacks: Stored XSS (Persistent) — The attack I described here is a form of stored XSS since the comment I would submit is saved in the database. At this point, every user that looks at the comment is attacked. Reflected XSS (Non-persistent) — In this form, the attacker sends a link to a user (or convinces the user to click on a link) that contains the malicious script. When the user clicks the link, the script runs, sending their data to the attacker. The script is embedded in the URL and reflected off the web server. This is usually part of a phishing attack. DOM-Based XSS —This type of attack occurs entirely in the victim's browser. The web application's client-side scripts write user-provided data to the Document Object Model. The data is subsequently read from the DOM by the web application and outputted to the browser. If the data was interpreted as JavaScript, it's executed. Protecting from XSS requires diligent validation of all input. We can protect against these attacks by checking if user-provided data is of the correct form and contains no malicious content. We must ensure any user-supplied content is treated as display content, not executable code. There are many ways to validate user-submitted data, and the Jsoup library contains one such API. Notice that Spring Boot contains XSS protection as part of the security configuration, but I’ll cover that later. personName = Jsoup.clean(personName, Whitelist.basic()); Notice that validating input is a recurring theme when it comes to security vulnerabilities. As developers, we often strive to provide the most generic and flexible tooling. This works against us when it comes to security vulnerabilities. It's important to limit input options even when we don't see a problem. Content-Security-Policy (CSP) One of the ways to carry out an XSS attack is by including foreign code on our own website. One way to block this is using special HTTP headers to define which sites can include our site. This is a rather elaborate process, but the nice thing is that Spring Security handles that nicely for us as well. HTTPOnly Cookies Cookies can be created in the browser using JavaScript. This is a bad practice. Ideally, cookies should always come from the server and be marked as HTTP only (and HTTPS only). This blocks JavaScript code from accessing the cookie. That means that even if a script is added somehow or a bad link is clicked, it won’t have access to the cookie value. This mitigates XSS attacks, so even if your site is vulnerable, the attack can't steal the cookie. We can enable HttpOnly cookies when we set the cookie in the server code. Unvalidated Redirects and Forwards Another security concern is unvalidated redirects and forwards. Here, an attacker creates a URL that looks like it's coming from your domain but redirects to another malicious site. The solution lies in validating and restricting included or submitted URLs and never sending users blindly to third-party sites. Let's say we have a login page. After we log in, we’re shown a splash screen, and then we’re sent to the actual destination. This seems simple enough, but some people need to go to page X, and others need to go to page Y. We want to keep the code generic, so we accept the destination URL as an argument. That way, the login code can decide where to go next, and we don’t need to know about all the user types, e.g.: https://bug.com/postLogin?dest=url. The problem is that a person can create a URL that looks like it’s coming from our domain but pass in another URL as the last argument. Our users can end up on a malicious site without realizing they were redirected to a new site. The solution is to validate and restrict included or submitted URLs and never send a user blindly to a third-party site. Server Side Request Forgery (SSRF) SSRF attacks are similar conceptually. In these attacks, our server performs a request based on the request we received. Our server can be manipulated to request arbitrary URLs for an attacker. This can serve as the basis for information theft, denial of service attacks, etc. Cross-Site Request Forgery (CSRF) CSRF is another challenging issue where an attacker tricks users into hacking their own accounts. Typically, we’re logged into a website. Our credentials and cookies are already set. If a different website knows we’re logged in to a website, it can trick us and get us to hack ourselves... Let's say you visit a website, and it has a big button that you can press for your chance to win a million dollars. Would you press it? What’s the harm, right? If that button is a form that submits the request directly to your bank, this can be used to steal currency and more. The standard solution is to add a server-generated token into the HTML that changes with every request, thus validating that the HTML came from the legitimate site. This is a standard strategy supported by Spring Security. We can also set our cookies to the SameSite policy, which will mean a user won’t be logged in if he’s on a separate site. Turning this on for your login information is probably a good idea. Final Word In conclusion, while we did not delve into a lot of code writing in this post, the objective was to shed light on common security vulnerabilities and attacks and how to prevent them. Understanding these concepts is fundamental in building secure applications, and the more we're aware, the better equipped we are to thwart potential threats. There are many tools for security validation. If you use a decent linter like SonarQube, you would be on your way to a more secure app. Snyk also has great tooling that can help catch various vulnerabilities. This paragraph from the post probably sums up the most important aspects: Notice that validating input is a recurring theme when it comes to security vulnerabilities. As developers, we often strive to provide the most generic and flexible tooling. This works against us when it comes to security vulnerabilities. It's important to limit input options even when we don't see a problem.

In this post, we will learn about the steps involved in the process of configuring an HTTPS endpoint with one-way SSL for a Mule Application. Securing communication between clients and servers is essential in today's digital world, and using HTTPS over HTTP ensures secure data transfer. Before we start, let's understand how does CloudHub load balancer work. When we deploy an app to CloudHub's shared load balancer, the app listens on host 0.0.0.0 and port 8081 for HTTP connection and on port 8082 for HTTPS connection. For mule workers, the following ports are assigned: http.port is set to 8081 https.port is set to 8082 For the CloudHub to dynamically allocate the correct port at the time of deployment, the ports in the application must be referenced using the reserved properties ${http.port} for HTTP connection and ${https.port} for HTTPS connection. Any custom port can be used for local testing if the ports are referenced using either http.port or https.port because CloudHub will automatically assign either 8081 or 8082 based on the property used at the time of deployment. For the load balancers to direct HTTPS traffic to the application, it is necessary to set up the HTTP listener with a certificate and a public-private key pair. It's important to note that the certificate configured within the application is not validated by the CloudHub load balancer. As a result, any self-signed certificate can be utilized, regardless of the host for which it was generated. Setting up an HTTPS Endpoint Step 1: Create a Keystore Step 1.1: Create or open the project in which the HTTPS endpoint is needed to be configured. In this tutorial, I have taken a project which has an HTTP endpoint configured, and we will change it to HTTPS. HTTP Listener Config: In this example, the "/hello" endpoint is listening on port 8081 and hosted on localhost(0.0.0.0). Step 1.2: Create a "cert" folder inside the "src/main/resources' folder. In this "certs" folder, we will store the Keystore. Step 1.3: Navigate to the "certs" folder in system explorer and open the command prompt there. Step 1.4: Execute the following command to create a Keystore. keytool -genkeypair -keyalg <algorithm> -alias <alias> -keystore <keystoreName> -storetype <storeType> -keypass <keyPassword> -storepass <storePassword> Note: Please be sure to replace the placeholders in the above command. Example of the above command that is used in this tutorial: keytool -genkeypair -keyalg RSA -alias mule-server -keystore demo-project.p12 -storetype pkcs12 -keypass mule1234 -storepass mule1234 The above command is a Java "keytool" command which is used to generate a new key pair and store it in a file. A Java KeyStore is a repository where cryptographic keys and their corresponding certificates can be stored securely. Let's understand the above command and its parameters: keytool: This is a Java key and certificate management tool which comes with Java Development Kit(JDK). genkeypair: This parameter indicates the keytool to generate a new Public key and a Private Key. keylag RSA: This parameter specifies the algorithm that should be used for generating the key pair. In this example, we have used the RSA algorithm. alias mule-server: The private key and the certificate are stored together in a Keystore. The alias is a unique name that can be used to refer to this key pair within the Keystore. keystore demo-project.p12: This specifies the name of the keystore where the generated key pair will be stored. In this case, the keystore file will be named "demo-project.p12". storetype pkcs12: This parameter sets the type of keystore. In this case, it's "pkcs12". keypass mule1234: This sets the password for the private key. storepass mule1234: This sets the password for the keystore. The whole keystore is encrypted with this password. After the execution of the above command, we need to answer some questions to create the Keystore. Please answer them accordingly. After answering the questions, the keystore will be automatically created in the "certs" folder. Step 1.5: Go to Anypoint Studio and refresh the project. The "certs" folder will get populated with the Keystore. Step 2: Configure the Keystore Step 2.1: Go to the properties file and add the "https.port" and "https.host" properties. In this tutorial, we are using localhost and port 8082. Note: For local deployment/testing, any port can be used. Step 2.2: Now, we need to create a configuration for TLS. In the "Global Elements" window search for "TLS Context" and add it. Now add the details of the Keystore in the TLS Context and save it. Step 2.3: Go to the HTTP listener Config and change the Protocol to "HTTPS," and replace the host and port properties with ${http.host} and ${https.port} respectively. Step 2.4: Go to the "TLS" tab in the HTTP listener Config, and in the "TLS Configuration," select the "Global reference," and in the "Global reference," select the TLS configuration that we created in Step 2.2. Save it. Now we are done with all the configurations. Save the project and run it. When the project gets deployed locally, make a call to the endpoint with HTTPS protocol using Postman. Make sure to disable the SSL Certificate Validation in the Postman for local testing. You should be able to get a 200 response back. Now deploy the mule app to the CloudHub. Once the app gets deployed, make a call to the endpoint with HTTPS protocol, and we should get a successful response back. Now we can make a call to this endpoint deployed in the CloudHub from the Postman even with SSL Certificate Validation enabled. In this way, we can configure an HTTPS endpoint in a mule app using one-way SSL. I hope this tutorial will help you.

When exposing an application to the outside world, consider a Reverse-Proxy or an API Gateway to protect it from attacks. Rate limiting comes to mind first, but it shouldn't stop there. We can factor many features in the API Gateway and should be bold in moving them from our apps. In this post, I'll show how to implement authentication at the Gateway API stage. Overall Authentication Flow The API Gateway doesn't authenticate but delegates authentication to an authentication provider. After authentication, the Gateway forwards the request to the app. The app checks authentication and gets the associated identity and permissions. Now, onto the implementation. We will implement the above flow with the following components: Keycloak for the Identity Provider Apache APISIX for the API Gateway The Spring ecosystem for developing the app Keycloak Keycloak is a feature-rich open-source identity provider. Keycloak offers the realm abstraction, a namespace to group logically-related objects. We will first create an apisix Realm to our configuration from other configurations. The official documentation explains how to do it in great detail. We can proceed further with creating objects under the apisix realm. The next step is to create an OpenID client for Apache APISIX to call Keycloak in the apisix realm. Here are the data: General settings: Client type: OpenID Connect Client ID: apisix Capability config: Client authentication: ON Go to the Credential tab and note the client's secret value. The final step is to create users. A user is a person who can log in to the system to access the app. Let's create two users, john and jane, and set their passwords. The demo repository already has Keycloak pre-configured - both users' password is doe. Spring Security We secure our application via Spring Security. Here are the required dependencies: XML <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> <!--1--> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-oauth2-client</artifactId> <!--2--> </dependency> Protect the application. Call the Keycloak server. The protecting code uses Spring Security: Kotlin bean { ref<HttpSecurity>().authorizeHttpRequests { it.requestMatchers("/*") //1 .hasAuthority("OIDC_USER") //1 .anyRequest() .permitAll() }.oauth2Login {} //2 .build() } Any request requires to have the OIDC_USER authority. "Log in" via OAuth2. The next step is configuring the framework: YAML spring.security: oauth2: client: registration.keycloak: client-id: apisix #1 authorization-grant-type: authorization_code scope: openid provider.keycloak: issuer-uri: http://localhost:9009/realms/apisix #2 user-name-attribute: preferred_username #3 Use the client created in Keycloak. We pass the secret at runtime via an environment variable. Keycloak realm to use. We override the domain in the Docker compose file via an environment variable. Use the user name instead of the token for display purposes. I'll use a dummy Thymeleaf page to display the logged-in user. We need additional dependencies: XML <dependency> <groupId>org.thymeleaf</groupId> <artifactId>thymeleaf</artifactId> <!--1--> </dependency> <dependency> <groupId>org.thymeleaf</groupId> <artifactId>thymeleaf-spring6</artifactId> <!--2--> </dependency> <dependency> <groupId>org.thymeleaf.extras</groupId> <artifactId>thymeleaf-extras-springsecurity6</artifactId> <!--3--> </dependency> Thymeleaf proper Thymeleaf and Spring integration Offers dedicated Spring Security tags The view is the following: HTML <!doctype html> <html lang="en" xmlns:sec="http://www.thymeleaf.org/extras/spring-security"> <body> <header> <h1>Welcome to My App</h1> <p> <span sec:authentication="name">Bob</span> <!--1--> </p> </header> </body> </html> Display the "name" of the logged-in user. Apache APISIX Lastly, let's configure the entry point into our system. I assume you're familiar with this blog and don't need an introduction to Apache APISIX. If you do, feel free to look at the APISIX, an API Gateway the Apache way. In standalone mode, the configuration file is the following: YAML routes: - uri: /* upstream: nodes: "myapp:8080": 1 plugins: openid-connect: discovery: http://keycloak:9009/realms/apisix/.well-known/openid-configuration #1 client_id: apisix #2 client_secret: rjoVkMUDpUH4TE7IXhhJuof4O7OFrbph bearer_only: false scope: openid realm: apisix #3 redirect_uri: http://localhost:9080/callback #4 #END Keycloak offers an endpoint that details every necessary endpoint for an OpenID integration. Use the same client as the app. In real-world scenarios, we should use one client per component, but it's a demo. Use the realm created in the Keycloak section. Any URL that's a subpath of the protected URL will do. Putting It All Together We put everything together via Docker Compose: YAML services: apisix: image: apache/apisix:3.4.0-debian volumes: - ./config/apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro #1 - ./config/apisix/apisix.yml:/usr/local/apisix/conf/apisix.yaml:ro #2 ports: - "9080:9080" keycloak: image: quay.io/keycloak/keycloak:22.0 entrypoint: - /bin/bash - -c - | /opt/keycloak/bin/kc.sh import --file /opt/keycloak/data/import/keycloak.json --override true #3 /opt/keycloak/bin/kc.sh start-dev --http-port 9009 #4 environment: KEYCLOAK_ADMIN: admin KEYCLOAK_ADMIN_PASSWORD: admin volumes: - ./config/keycloak:/opt/keycloak/data/import:ro ports: - "9009:9009" myapp: build: ./myapp environment: SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_KEYCLOAK_CLIENT-SECRET: rjoVkMUDpUH4TE7IXhhJuof4O7OFrbph #5 SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_KEYCLOAK_ISSUER-URI: http://keycloak:9009/realms/apisix #5-6 LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_SECURITY: DEBUG #7 depends_on: - keycloak restart: on-failure #8 Configure standalone mode. Routes and plugins configuration as seen in the previous section Initialize Keycloak with the existing saved realm. Start Keycloak. Configure the OAuth client. Because the flow is browser-based, we will be redirected to a keycloak domain for authentication. Hence, we have to update our /etc/hosts with a new 127.0.0.1 keycloak entry. Set Spring Security log level to debug helps understand issues. Spring Security eagerly tries to contact Keycloak. Keycloak takes a while to initialize itself; we need to let the app crash and start again until Keycloak is ready. Let's try to access the application via Apache APISIX. When we browse to , Apache APISIX redirects us to the Keycloak login page: If we log in successfully, we are allowed to access the app. Notice that we display the username of the person who logged in: Conclusion In this post, we described how to move the authentication step to the API Gateway stage, delegate authentication to an identity provider, and let the app verify the authentication status. We implemented it with Apache APISIX, Keycloak, and Spring Security. Many other options are available, depending on your environment. The complete source code for this post can be found on GitHub. To go further: Keycloak Administration Guide How to Integrate Keycloak for Authentication with Apache APISIX A Quick Guide to Using Keycloak With Spring Boot Originally published at A Java Geek on July 30th, 2023

If there’s one thing nearly all contemporary, interactive client-side web applications have in common, it’s a reliance on dynamic user-facing text input fields. These fields play the all-important role of capturing plain text data from client-side browsers and sharing that information with a server-side application, allowing that application to perform specific actions with that data based on stringent request parameters. We encounter these fields when we log into or register a new account within an application, query content from a web application’s database, fill out a contact form, write comments on an article post, and more. When we interact with these fields as client-side users, we might notice that some fields only accept data in a certain format. For example, if we enter integers into a “First Name” or “Last Name” field, we’ll likely receive an error response from the application quickly notifying us that integers aren’t valid in that field. Similarly, if we enter our name into a field that asks for our date of birth, we’ll likely receive an error response that asks for valid integers instead. On the one hand, these validation measures are important to ensure web applications retrieve accurate information from client-side users and avoid issues related to invalid data. On the other hand, they’re the first of many steps involved in securing the web application against web-based cyberattacks. Cyberattacks From User-Facing Text Input When user-facing text input fields don’t exhaustively validate and/or sanitize client-side input, they can be quickly and easily exploited by client-side threat actors to launch a variety of significant cybersecurity attacks. While most of these attacks attempt to steal resources from the underlying server-side application/database, others try to passively exploit unsuspecting client-side users accessing the same web application’s content on a different browser. One common example of an attack that steals information from a web application’s server-side resources is SQL Injection (SQLI). Many web applications store data in SQL databases, so the text we enter into those applications’ search fields is formulated into an SQL query to modify (select, update, delete, insert, etc.) that data. If the search field inputs aren’t adequately validated, a cybercriminal can enter their own SQL query directly into one of those fields and ask the database for resources far outside the scope of that input field’s usual request parameters. Depending on the sophistication of the attacker in question, this breach can allow them to steal other users’ login information, manipulate or delete valuable data, acquire administrative permissions, or even inject malware in extreme cases. The latter scenario – in which an attacker leverages a web vulnerability to exploit other client-side users – is best exemplified by Cross-Site Scripting (XSS) attacks. When user-input text fields are designed to store and subsequently reflect client-supplied data back on a web page for other users to see (e.g., the comment section on an article), threat actors can attempt to exploit these input fields by entering malicious scripts within them. If the web application blindly trusts user input provided in these fields, an attacker’s malicious script can be stored in the application database, reflected onto the original input page, and subsequently executed within another user’s browser. This process allows the attacker to steal data from an unsuspecting victim or even impersonate them and carry out malicious actions on their behalf. The above examples are just two of several common, well-documented web security threats which are frequently used to breach vulnerable web applications all over the world. Along with critical client-side input validation and sanitization measures, the implementation of dedicated threat detection policies is important for bolstering any web application’s threat profile against these user-facing text input threats. The existence of multiple unique content-based threats means multiple unique policies should be put in place – but that doesn’t mean they have to stand apart from one another and clutter unnecessary clutter, either. By funneling client-supplied content through a single, dynamic threat detection API, we can build sensible and efficient security redundancy into our workflow in one simple step. Demonstration In the remainder of this article, I’ll demonstrate a free Web Security API which can be used to automatically detect a variety of unique, commonly encountered cybersecurity threats from user-facing text input. Threat coverage includes: SQL Injection (SQL) Cross-Site Scripting (XSS) XML External Entities (XSS) Server-Side Request Forgery (SSRF) JSON Insecure Deserialization (JID) This API input accepts a string containing user-facing text input from a web application field. When any of the above threats are detected, the API will return a “CleanResult: False” value in the response body, along with a Boolean reading “True” for the specific threat encountered in that request. The specific data type used in that request (i.e., XML, JSON, or URL format) will be identified as well. A full example response body can be viewed below in JSON format: JSON { "Successful": true, "CleanResult": true, "ContainedJsonInsecureDeserializationAttack": true, "ContainedXssThreat": true, "ContainedXxeThreat": true, "ContainedSqlInjectionThreat": true, "ContainedSsrfThreat": true, "IsXML": true, "IsJSON": true, "IsURL": true, "OriginalInput": "string" } We can easily take advantage of this API using ready-to-run Java code examples provided further down the page. Before we get to that, however, we’ll first need to install the client SDK. We can do so by first adding a reference to the repository in our Maven POM file (JitPack is used to dynamically compile the library): XML <repositories> <repository> <id>jitpack.io</id> <url>https://jitpack.io</url> </repository> </repositories> And we can then add a reference to the dependency: XML <dependencies> <dependency> <groupId>com.github.Cloudmersive</groupId> <artifactId>Cloudmersive.APIClient.Java</artifactId> <version>v4.25</version> </dependency> </dependencies> We can then structure our API call by adding the imports and Java examples into our file: Java // Import classes: //import com.cloudmersive.client.invoker.ApiClient; //import com.cloudmersive.client.invoker.ApiException; //import com.cloudmersive.client.invoker.Configuration; //import com.cloudmersive.client.invoker.auth.*; //import com.cloudmersive.client.ContentThreatDetectionApi; ApiClient defaultClient = Configuration.getDefaultApiClient(); // Configure API key authorization: Apikey ApiKeyAuth Apikey = (ApiKeyAuth) defaultClient.getAuthentication("Apikey"); Apikey.setApiKey("YOUR API KEY"); // Uncomment the following line to set a prefix for the API key, e.g. "Token" (defaults to null) //Apikey.setApiKeyPrefix("Token"); ContentThreatDetectionApi apiInstance = new ContentThreatDetectionApi(); String value = "value_example"; // String | User-facing text input. try { StringAutomaticThreatDetection result = apiInstance.contentThreatDetectionAutomaticThreatDetectionString(value); System.out.println(result); } catch (ApiException e) { System.err.println("Exception when calling ContentThreatDetectionApi#contentThreatDetectionAutomaticThreatDetectionString"); e.printStackTrace(); } Now we can authorize free requests by entering a free-tier API key into the Apikey.setApiKey snippet. This solution will add a new layer of security to our web application, but it should by no means serve as a single point of failure. It’s extremely important to carefully review best practices associated with preventing each of the threats mentioned above and enhance web application security measures accordingly.