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; in the later,
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