Security

CVSS 101: First Steps with Common Vulnerability Scoring System

What is the Common Vulnerability Scoring System (CVSS), who is behind it, what are we doing with it, and what does a CVSS Value mean for you?

With CVSS, we have a value system for evaluating security gaps in software. Since there are no alternatives, the system has been in use worldwide for over ten years and is constantly being developed, it is a defacto standard.

The evaluation consists of three components.

The Lifecycle of a Security Vulnerability

Again and again, we read in the IT news about new security gaps that have been identified.

Most of the time, you don’t even hear or read anything about all the security holes found that are not as well known as the SolarWinds Hack, for example.

But what is the typical lifecycle of such a security gap?

Java Encryption and Hashing

If you need to store sensitive data in your system, you have to be sure that you have proper encryption in place.

First of all, you need to decide what kind of encryption you need —for instance, symmetric or asymmetric.

Also, you need to choose how secure it needs to be. Stronger encryption takes more time and consumes more CPU.

The most important part is that you don’t need to implement the encryption algorithms yourself. Encryption is hard and a trusted library solves encryption for you.

JEP 411: What it Means for Java’s Security Model and Why You Should Apply the Principle of Least Privilege

Java, like most platforms or languages has layers of security. This article intends to look at Java’s Authorization layer, which is unlike in other languages.

We will also distinguish between two different ways this layer is typically utilized and why one is effective while the other isn’t.

Furthermore, we investigate why JEP 411 only considers the least effective method and hopefully we will increase awareness of the Principle of Least Privilege as it is applied to Java Authorization, improve adoption and encourage people to take advantage of the improved security it provides.

We hope to prolong its support and possibly even improve it in future.

Java: Where the Wild Code Isn’t

In the last several years, the OpenJDK community has made Java significantly safer for users and developers while at the same time making it easier to design, build, and run applications quickly.

Java users should incorporate several practices to take full benefit from the defenses of the modern JRE.

Hacking Third-Party APIs on the JVM

The JVM ecosystem is mature and offers plenty of libraries, so you don’t need to reinvent the wheel. Basic – and not so basic – functionalities are just a dependency away. Sometimes, however, the dependency and your use-case are slightly misaligned.

The correct way to fix this would be to create a Pull Request. But your deadline is tomorrow: you need to make it work now! It’s time to hack the provided API.

In this article, we are going through some alternatives that allow you to make third-party APIs behave in a way that their designers didn’t intend to.

The Principle of Least Privilege and How JEP 411 Will Have a Negative Impact on Java Security

The SecurityManager and associated infrastructure are the foundations upon which to build secure software, but by themselves are insufficient for limiting users and Java software to the principles of least privilege.

JEP 411 removes the SecurityManager and AccessController.

In doing so, your library code will be able to run with the full permissions of its Java process, which is the same as running with none of the permission checks that were used to harden Java’s API.

If an attacker breaks into your Java process via some other vulnerability, they will be able to load their own byte codes, and pretty much do whatever the process permissions permits them and possibly more if your system has other vulnerabilities.

Sanitize All Input!

Cross-site scripting (XSS) is a well-known issue and mostly utilized in JavaScript applications.

However, Java is not immune to this. XSS is nothing more than an injection of JavaScript code that’s executed remotely.

Rule #0 for preventing XSS, according to OWASP, is “Never insert untrusted data except in allowed locations.”

The basic solution to this Java security risk is to prevent untrusted data, as much as possible, and sanitize everything else before using the data.

Preventing YAML Parsing Vulnerabilities in Java

YAML is a human-readable language to serialize data that’s commonly used for config files. The word YAML is an acronym for “YAML ain’t a markup language” and was first released in 2001. You can compare YAML to JSON or XML as all of them are text-based structured formats.

YAML files are often used to configure applications, application servers, or clusters. It is a very common format in Spring Boot applications and, of course, to configure Kubernetes. However, similarly to JSON and XML, you can use YAML to serialize and deserialize data.

Fix Java Security Issues While Coding in IntelliJ IDEA

Nowadays, developers are responsible for more than just creating the application. Besides working on features, developers have to focus on their applications’ maintainability, scalability, reliability, and security. Many developers are unsure of where to start with security. In addition, most companies still work with a dedicated security team instead of having security expertise inside the team.

A lot of developers practically live in their integrated development environment (IDE). A good IDE is like a swiss army knife: it is your go-to tool to do almost everything. Having everything I need to build, run, test, debug, and secure my application, makes a good IDE invaluable for many developers.

Namespace Shadowing (a.k.a. “Dependency Confusion”) Attack

The npm Registry is vulnerable to supply chain namespace shadowing, also known as “Dependency Confusion” attacks.

Make sure you create npm scoped packages and force exclude patterns.