Security in one’s information system has always been among the most critical Non-Functional Requirements. Transport Secure Layer, aka TLS, formerly SSL, is among its many pillars. In this post, I’ll show how to configure TLS for the Apache APISIX API Gateway. TLS in a few words TLS offers several capabilities: Server authentication: the client is confident that the server it exchanges data with is the right one. It avoids sending data, which might be confidential, to the wrong ac
API Gateways are critical components in one’s infrastructure. If an attacker could change the configuration of routes, they could direct traffic to their infrastructure. Consequences could range from data theft to financial losses. Worse, data theft could only be noticed after a long time by mirroring the load. Hence, protecting your API Gateway is of utmost importance. In this short blog post, I’ll list a couple of ways to secure your Apache APISIX admin access. Change admin toke
API management solutions, also known as API gateways, are a must in the day and age of APIs. However, once you’ve set up such a gateway, you can use it for different purposes unrelated to APIs. Today, I want to show you how to improve the security of web apps. Prevent sniffing Browsers are fantastic pieces of technology that try to make the life of users as comfortable as possible. However, the balance between ease of use and security may sometimes tip on the former to the latter’
Last year, I spoke at the National DevOps Conference that took place at the British Museum. I had already visited the museum before, but speaking there was a fantastic experience. Besides, we had the museum all for ourselves for a couple of hours. If you’ve ever visited the place, you know what I mean. Anyway, I also attended a talk about Checkov: Checkov scans cloud infrastructure configurations to find misconfigurations before they’re deployed. Checkov uses a common command
Security is the poster child of a Non-Functional Requirement: most people don’t care until the proverbial fecal matter hits the rotary propeller. Consequences can range from losing reputation to legal liability to putting the business out. In my post on running unsecured code, I concluded that you should treat security as a risk - and left it at that. I think it warrants a dedicated post. Risk management is pretty much documented. You can find it in many engineering disciplines, if not ev
Last December, Log4Shell shortened the nights of many people in the JVM world. Worse, using the earthquake analogy caused many aftershocks after the initial quake. I immediately made the connection between Log4Shell and the Security Manager. At first, I didn’t want to write about it, but I’ve received requests to do so, and I couldn’t walk away. +<div class='jekyll-twitter-plugin'><blockquote class='twitter-tweet'><p lang='en' dir='ltr'>Hey <a href='https:
A couple of years ago, I attended a talk of my former colleague (but still friend) Volker Simonis. It gave me the idea to dig a bit into the subject of how to secure the JVM. From the material, I created a series of blog posts as well as a talk. From that point on, I submitted the talk at meetups and conferences, where it was well-received. Because I like to explore different areas, I stopped to submit other proposals. Still, the talk is in my portfolio, and it was requested again in 2021. I ha
This is the 5th post in the JVM Security focus series. A post brought to light an interesting feature of the JDK I didn’t know about: the ability to update a code running in a JVM. The referenced post shows how to apply a bugfix using that feature. The devious white hat JVM hacker in me started to think how one could apply that trick for other less beneficial purposes. And of course, how to prevent that.
This is the 4th post in the JVM Security focus series. In one of my previous posts, I described how to create a custom policy file for one’s application. The process was manual and incremental. Because of that, it was painstakingly long, and hence not really useful. Since I wrote the post, I found a way to write the policy file under in a couple of hours, instead of days.
If you already had to manage some degree of randomness on Java, chances are you got acquainted with the Math.random() methods. However, the previous method returns a double. Beyond very basic use-cases, another option has to be considered, in the form of the java.util.Random class. Random An instance of this class is used to generate a stream of pseudorandom numbers. — JavaDoc https://docs.oracle.com/javase/8/docs/api/java/util/Random.html This root class provides basic random num
This is the 2nd post in the JVM Security focus series. I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a reminder, the JVM can run in two different modes, standard and sandboxed. In the former, all API are available with no restriction; i
Java makes it possible to compile Java code at runtime… any Java code. The entry-point to the compilation is the ToolProvider class. From its Javadoc: Provides methods for locating tool providers, for example, providers of compilers. This class complements the functionality of ServiceLoader. This class is available in Java since version 1.6 - released 10 years ago, but seems to have been largely ignored. The code Here’s a snippet that allows that: public class Ev
This week, I wanted to make a simple experiment. For sure, all applications we develop make use of HTTPS to encrypt the login/password but what happens before? Let’s say I typed my login/password but before sending them, I’m called by my colleague and I leave my computer open. My password is protected by the HTML password input, right? It shows stars instead of the real characters. Well, it’s stupidly easy to circumvent this. If you use a developer workstation and have develop
For sure, software security should be part of every developer’s requirements: they should be explained and detailed before development. Unfortunately, it happens in real life that this is not always the case. Alternatively, even when it is, developers make mistakes and/or have to make with tight (read impossible) plannings. In the absence of security checks automated tools, sooner or later, an issue will appear. I’ve been thinking about a way to sanitize the output of a large-scale
I’ve been thinking about having a more secure password management since ages. At first, my only concern was to share my bookmarks and history between my different computers (at that time, phones were conveniently left out of my scope). Since Firefox was my browser of choice, I decided to go for Foxmarks (now called XMarks and available for more browsers). However, it soon became apparent that my natural lazyness came back and I synchronized my passwords too… in the cloud. Aft
My debugging contest of the week happened to take place on a IBM AIX system. The bug happened when we upgraded from Java version 1.4 to version 6 (which I admit is a pretty big step). Suddenly, an old application stopped working and its log displayed NoSuchAlgorithmException. A bit of context: when Java applications have to connect to hosts with SSL over HTTP, they must trust the host - it’s the same as when you browse a site with HTTPS. If the site can provide a SSL certificate that can
One thing I’m doing very often and always searching on the Internet is how to obtain a self-signed SSL certificate and install it in both my client browsers and my local Tomcat. Sure enough there are enough resources available online, but since it’s a bore to go looking for the right one (yes, some do not work), I figured let’s do it right once and document it so that it will always be there.
Servlet 3.0 is not only about the replacement of the web.xml deployment descriptor by annotations. In this article, we’ll see what improvement it makes in the realm of security. In Servlet 2.5 (and before that), declarative security was about the following features: authentication method (BASIC, FORM, etc)authorization to differents parts of the application (web application resources)data confidentiality and integritysession time-out Servlet 3.0 adds standardized ways regarding two conf
My work is IT architecture, meaning I focus on the early steps of a project. Once the application is in production, I usually leave it to systems and production engineers. For example, for JVM fine tuning, most of the clients I worked for have people that have the right skills to do that. Nevertheless, I need sometimes to sully my nails. This happens in two cases: when the client is too small to have such dedicated teams or when its production team are not experienced enough to handle the probl
Tomcat manages application security through the concept of realm. A realm is a coherent package of name password pairs that identify valid users for a web application. Tomcat’s default realm is MemoryRealm. This realm reads the famous conf/tomcat-users.xml file and uses it check for name password pair validity. Tomcat also provides realms to check against pairs stored in a database, either through a direct connection, or through a configured datasource. The main disadvantage of these all