Password security is an often underestimated but critical topic in software development. Databases containing millions of user logins are repeatedly compromised - and shockingly, often, it turns out that passwords have been stored in plain text. This gives attackers direct access to sensitive account data and opens the door to identity theft, account takeovers and other attacks.
A URL shortener seems harmless – but if implemented incorrectly, it opens the door to phishing, enumeration, and data leakage. In this first part, I’ll explore the theoretical and security-relevant fundamentals of a URL shortener in Java – without any frameworks, but with a focus on entropy, collision tolerance, rate limiting, validity logic, and digital responsibility. The second part covers the complete implementation: modular, transparent, and as secure as possible.
1. Getting started – trust in everyday internet life # Anyone who enters a web address like “www.example.de” into the browser expects a familiar website to appear within seconds. Whether in the home office, at the university, or in the data center, access to online services is now a given. The underlying technical processes are invisible to most users; even in IT practice, they are often taken for granted. One of these invisible processes is name resolution by the Domain Name System (DNS).
The Java Cryptography Architecture (JCA) is an essential framework within the Java platform that provides developers with a flexible and extensible interface for cryptographic operations. It is a central component of the Java Security API and enables platform-independent implementation of security-critical functions.
Cache poisoning on Maven Caches is a specific attack that targets how Maven Caches manages packages and dependencies in a software development process. It’s essential to understand how Maven works before we look at the details of cache poisoning.
Learn how inadequate control over error reporting leads to security vulnerabilities and how to prevent them in Java applications. # Safely handling error reports is a central aspect of software development, especially in safety-critical applications. CWE-778 describes a vulnerability caused by inadequate control over error reports. This post will analyse the risks associated with CWE-778 and show how developers can implement safe error-handling practices to avoid such vulnerabilities in Java programs.
Building on the discussion of “CWE-377: Insecure Temporary File”, it’s essential to delve deeper into one of the most insidious vulnerabilities that can arise in this context—TOCTOU (Time-of-Check to Time-of-Use) race conditions. TOCTOU vulnerabilities occur when there is a time gap between verifying a resource (such as a file) and its subsequent use. Malicious actors can exploit this gap, especially in temporary file scenarios, leading to serious security breaches. This follow-up article will explore how TOCTOU conditions manifest in software, particularly in managing temporary files, and discuss strategies to mitigate these risks to ensure robust and secure application development.
Self-modifying code refers to a type of code that alters its own instructions while it is executing. While this practice can offer certain advantages, such as optimisation and adaptability, it is generally discouraged due to the significant risks and challenges it introduces. For Java developers, using self-modifying code is particularly problematic because it undermines the codebase’s predictability, readability, and maintainability, and Java as a language does not natively support self-modification of its code.
In software development, temporary files are often used to store data temporarily during an application’s execution. These files may contain sensitive information or be used to hold data that must be processed or passed between different parts of a program. However, if these temporary files are not managed securely, they can introduce vulnerabilities that may compromise the application’s confidentiality, integrity, or availability. The Common Weakness Enumeration (CWE) identified CWE-377 as a weakness associated with the insecure creation and management of temporary files.
What is a Package Manager - Bird-Eye View # A package manager is a tool or system in software development designed to simplify the process of installing, updating, configuring, and removing software packages on a computer system. It automates managing dependencies and resolving conflicts between different software components, making it easier for developers to work with various libraries, frameworks, and tools within their projects.
CWE-416: Use After Free # Use After Free (UAF) is a vulnerability that occurs when a program continues to use a pointer after it has been freed. This can lead to undefined behaviour, including crashes, data corruption, and security vulnerabilities. The problem arises because the memory referenced by the pointer may be reallocated for other purposes, potentially allowing attackers to exploit the situation.
The term “CWE-787: Out-of-bounds Write " likely refers to a specific security vulnerability or error in software systems. Let’s break down what it means:
Out-of-bounds Write : This is a type of vulnerability where a program writes data outside the boundaries of pre-allocated fixed-length buffers. This can corrupt data, crash the program, or lead to the execution of malicious code.
