A little bit on Content Discovery

A couple of thoughts on a phenomenon such as content discovery. Once again I came across such a problem in one of the projects and decided to write about it. The post will be useless to those who are aware of how a security audit is conducted. However, for me, as a software developer, this once became a revelation. In information security, content discovery refers to the technique of searching for hidden resources, mainly in web applications.

I first encountered this phenomenon several years ago, when friends contacted me and said that their clients began to disappear. It was a small company. They had a sales department and a small one-page website where potential customers would leave their phone numbers. Then the sales managers called back to the customer and made deals. So, from a certain point on, customers who came to the site were processed by competitors before the manager had even a chance to call them.

At first, employees were the main suspects. Then I decided to take a look at the source code of the site. It turned out that the URL /clients (I don’t remember exactly) without any authentication was available to anyone for a few hours, showing the list of customers, who submitted the request. This URL was being twitched by the CRM and the new customers were being added to its database.

At that time, it wasn’t clear to me how to locate this path on the site, because it did not appear anywhere – neither in sitemap.xml nor in robots.txt or anywhere else. I did not know anything about content discovery, so I gave it a thought and eventually dismissed it (the problem was already solved anyway). As it turned out, there are ways to search for such hidden resources. Let’s see what you can hide and how to find it.

Read More →

8 reasons to have microservices

Splitting a codebase. Small, and Focused on Doing One Thing Well.

At 1st Chapter of Building Microservices by Sam Newman, the author described the motivation.

Codebases grow as we write code to add new features, Over time, it can be difficult to know where a change needs to be made because of the codebase is too large. Despite a drive for clear, modular monolithic codebases, all too often these arbitrary in-progress boundaries break down. Code related to similar functions starts to become spread all over making fixing bugs or implementations more difficult.

With a monolithic system, we fight against these forces by tying to ensure our code is more cohesive, often by creating abstractions or modules. Cohesion – the drive to have related code grouped together – is an important concept when we think about microservices. This is reinforced by Robert C. Martin’s definition of the Single Responsibility Principle, which states “Gather together those things that change for the same reason, and separate those things that change for different reasons.”

Read More →

Scripting and sandboxing in JVM

It’s a very common situation when an application needs some runtime customization, but it’s impossible via settings and you are too lazy to change source code, or you just cannot update your application too often. In that case you may use different script engines in order to change application behavior in runtime. Moreover, the developer doesn’t have to do changes themself. It may be the duty of administrators, analysts, etc

 

So, I want to describe the way of one java application, from the simplest script engine up to engines with secured sandboxes.

 

Read More →

Integration with 3rd party APIs

There are many articles and books about good API design. But more often we connect to external systems via API, not developing.

I divide programming interfaces into two big sets – public and not so public. The first category – APIs of big companies like Facebook, Twitter, Paypal, etc. Generally, this kind of API is stable, developer-friendly and well-designed. The second category is APIs of small or middle-sized companies, state services and internal applications in big companies. This article will focus on the second set.

 

Read More →