In my previous blog post I questioned the safety of the default configuration of Ebase Xi. I knew then that something was wrong as I had already found and reported two vulnerabilities to Ebase. But nothing happened. On the 6th of march, much to my surprise, I got an official Ebase security alert informing me that ‘All Ebase Servers are vulnerable to XXE attacks’. Which was one of the two issues I originally reported. Now that its public knowledge you can read this post for full details.
A few weeks ago I found myself having to fix a bug in a production system which uses MongoDB as its primary means of storage. As I was unfamiliar with the codebase, we had just taken over the project, the first thing you do is trying to find the test covering this functionality.
Jaw drop; no test in sight. What was the case, none of the interactions with the backing storage was under any form of testing. So it could happen that a simple aggregation query wasn’t returning the expected results
This was my first project in which I used MongoDB, coming from projects using HSQLDB to test the validity and outcome of queries, the first thing that flashed through my mind was in-memory MongoDB. The first hit on Google wasn’t promising http://stackoverflow.com/questions/10005697/does-mongo-db-have-an-in-memory-mode, but luckily some following results hit the jackpot.
The last few years there is an almost constant stream of news articles about some company leaking customer information one way or the other.
While not all of these leaks are caused by badly protected websites themselves, a lot are caused by misconfigurations in the web/data servers, programmers still have a hard time integrating some basic protection against attacks.
Ebase Xi (from ebasetech.com) 4.5.2 is a rapid application development platform I recently encountered at a client. The previous developers had left and a security audit revealed that the (many) forms they built with Ebase Xi were susceptible to SQL Injection. In this blog post I will tell how I fixed the SQL Injections and discovered some interesting things along the way.
There are two camps within our ranks: the first camp believes the front- and back-end should be completely separated, where both applications have separate version control, build processes, and deployments.
Disclaimer: I’m in the camp that believes strongly in separating the two. So I want to argue the case for separating front- and back-end completely in the post.
Aggregations in MongoDB
The MongoDB aggregation operations allow us to process data records and return computed results. Aggregation operations group values from multiple documents together, we can perform a variety of operations on the grouped data to return a single result. Spring Data Mongo makes the usage of this feature from your Java application very easy.
A web-application is never finished. Even when no new features are being developed new vulnerabilities may be found in the frameworks used in the application requiring a patch or an upgrade. Are you actively monitoring the frameworks that are in use in your applications? My guess is no, or at least not all of them. Well, luckily enough OWASP has a very nice utility that easily integrates into a build environment and can do most of the hard work for you. Let me tell you about it.
Can you handle JSON natively in Java? The very short answer: no. It is possible to get a near-native JSON handling experience, for example with EasyGson. There is a price to pay, though. You will have to forgo standard Java best practices and accept that the JSON itself can be the master data source in your domain.
The discussion on start (-Xms) and maximum (-Xmx) heap memory in Java is and old one. The consensus among admins is that both settings are best set to equal values in order to prevent internal Java reorganizations when heap changes are required. Before you follow this advice, you best understand that the starting heap is not fully claimed at the OS level and also that some garbage collection runs may not be triggered at all in your application.