On a wonderful weekend in summer time, instead of going out to a beach or somewhere else, I was staying at home and wondering if it’s possible to send data from an ESP board to a Google sheet using my favorite MicroPython. Let’s say it can send temperature and humidity measured by a DHT22 sensor. That’s how the project started.
(this post contains a brief description of the project, more technical details can be found in the next post)
The transistor delay circuit may be helpful to learn some electronics basics. The circuit is pretty simple. It only contains a transistor, a capacitor, several resistors, a switch and an LED. The circuit uses an RC filter to turn an LED on with a little delay. Let’s see how we can choose elements for the circuit, and how the delay depends on parameters of the elements.
Increasing living space unavoidably results in filling up the new available space. In the end of last year I moved to a bigger apartment. Since I still have the same furniture, the unused space and volume keep bothering me. In the winter I built a shelving and now I store some useful stuff on it. In spring I got an idea to make a small garden at home. On weekend I built several wooden boxes, and put cherry tomatoes, onions and dill into it. But then I thought it’s not enough. I bought a couple of plastic containers and put more tomatoes. But I thought even that was not enough, and I got an idea to make a hydroponic system.
Let’s take a look what is inside Java 12. The new Java release contains less major enhancements than the previous version: 8 JEPs in Java 12 vs 17 JEPs in Java 11. As you of course remember, JEP stands for JDK Enhancement Proposal. Java 11 also had more closed entries in Jira: ~2700 in Java 11 vs ~2400 in Java 12. But it’s only mid of Feb 2019, maybe they can deliver 300 Jira entries by Mar 19th 2019 when Java 12 is planned to be released. Now let’s take a closed look what is in Java 12.
Nowadays more and more companies provide web APIs to access their services. They usually follow REST style. Such a RESTful web service looks like a regular web application. It accepts an HTTP request, does some magic, and then replies with an HTTP response. One of the main differences is that the reply doesn’t normally contain HTML to be rendered in a web browser. Instead, the reply usually contains data in a format (for example, JSON or XML) which is easier to process by another application.
Unfortunately, since a RESTful web service is still a web application, it may contain typical security vulnerabilities for web applications such as SQL injections, XXE, etc. One of the ways to identify security issues in web applications is to use web security scanners. Fortunately, since a RESTful web service is still a web application, we can use web security scanners to look for security issues in web APIs.
There are several well-known web security scanners. One of them is w3af created by Andres Riancho. I’ll focus on this scanner in the post.
In most cases, REST APIs should be accessed only by authorized parties. Spring framework provides many ways to configure authentication and authorization for an application. Another good thing is that the framework usually provides relatively good default settings. But nevertheless, it may be better to understand what’s going on rather then rely on the defaults.
This post contains a list of things which may be good to pay attention to when you configure or review authentication and authorization settings for a RESTful application based on Spring (boot) framework. However this is not a comprehensive guideline (if such a guideline even exist) which tells how to configure authentication and authorization for an application based on Spring framework. It’s more like a collection of tips and suggestions. Furthermore, any other suggestions and comments are more than welcome.
Java 11 was released on Sep 25th, 2018. This is the first long-term support release produced under the six-month cadence release model. Besides a huge number of small improvements and bug fixes, the new release contains 17 major enhancements including:
several updates in the Hotspot and garbage collectors
new HTTP client
removing the Java EE and CORBA Modules
local-variable syntax for Lambda parameters
launch single-file source-code programs
and finally several security features
Although all these features are pretty cool, let’s focus on security in this post.
Java 11 supports TLS 1.3 protocol which was published in August 2018. During implementing the new TLS protocol, Java security-libs team significantly re-worked Java Secure Sockets Extension (JSSE). I used to work on security-libs in Java for 6 years, so I can tell that was not an easy task for sure. But nevertheless, Java security-libs team delivered TLS 1.3 implementation in Java 11. Great job!
TLS 1.3 standard was finally published in August 2018. The authors tried to address the problems which unfortunately exist in older versions of the TLS protocol. One of the problems is a lack of protection against downgrade attacks.
Code coverage analysis is used in software testing to discover untested pieces of an application. Gathering code coverage data may also be useful for fuzzing. Basically it may help to figure out which parts of a program were not reached during fuzzing. This info can then be used to improve the fuzzer.
Let’s try to gather some code coverage data during fuzzing. As an example, we’re going to test picotls with tlsbunny. Picotls is an implementation of TLS 1.3 protocol written in C, and tlsbunny is a framework for building negative tests and fuzzers for TLS 1.3 implementations. We’re going to use gcov for gathering code coverage data, and lcov for creating a report.