Crashing with Clues: How Improper Error Handling Leaks Secrets

CTF + Real-World Vulnerability = Hands-On Learning

In one of my early Capture The Flag (CTF) challenges, I encountered a vulnerability that many developers unknowingly leave behind — improper error handling.

In this blog, I'll walk you through:

• 🔍 What improper error handling is
• 🧨 How I triggered it in a Java web application
• 💣 How it exposed internal logic
• 🛠️ And how I patched it securely like a professional

---

🚨 What Is Improper Error Handling?

Improper error handling occurs when backend exceptions are shown directly to the user. These errors can reveal:

• Class names and file paths
• Programming languages and frameworks
• Sensitive logic and stack flow
• Even system vulnerabilities

This information might seem harmless — but it’s a goldmine for attackers.

---

🧪 The CTF Challenge Setup

I was given a Java web application built with:

• Spring MVC
• Apache Tomcat
• A simple math evaluator backend

The goal was to test how the app responds to invalid input and identify any information disclosure through error messages.

---

🔍 Triggering the Vulnerability

I submitted a malformed input like this:
[http://localhost:8080/calculate?calculate=+]

And the application responded with this full stack trace:

HTTP Status 500 – Internal Server Error

Exception: java.util.EmptyStackException
at com.service.LoginService.evaluateExpression(LoginService.java:107)
at com.controller.LoginController.login(LoginController.java:23)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:209)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:986)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

---

💡 What Did I Learn From This?

• Internal class structure (LoginService, LoginController)
• Backend logic using Java’s Stack class
• Exact file names and line numbers
• Technology stack: Spring MVC, Java 11+, Apache Tomcat

---

💥 Why This Is Dangerous

These details help an attacker:

• Understand your application logic
• Identify vulnerable entry points
• Craft targeted payloads or exploits
• Reverse-engineer backend behavior

This is a textbook example of an Improper Error Handling vulnerability — and it gave away too much information.

---

🛠️ Fixing the Vulnerability

🔧 The vulnerable code (LoginController.java)

@RequestMapping(method = RequestMethod.GET, value = "/calculate")
ResponseEntity<String> login(HttpServletRequest request, HttpServletResponse response) {
    String expression = request.getParameter("calculate");
    double result = loginService.evaluateExcreption(expression);
    return ResponseEntity.status(200).body(result + "");
}

✅ The fixed version with proper error handling:

@RequestMapping(method = RequestMethod.GET, value = "/calculate")
ResponseEntity<String> login(HttpServletRequest request, HttpServletResponse response) {
    String expression = request.getParameter("calculate");
    try {
        double result = loginService.evaluateExcreption(expression);
        return ResponseEntity.ok(result + "");
    } catch (Exception ex) {
        return ResponseEntity.badRequest().body("Invalid expression provided");
    }
}

This ensures that:

• The stack trace is hidden from the user
• A friendly error message is shown
• Internal logic is kept private

🧠 Backend Fix: Defensive Programming in LoginService

Here’s the vulnerable part of the expression evaluator:

else if (tokens[i] == ')') {
    while (ops.peek() != '(') {
        values.push(applyOp(ops.pop(), values.pop(), values.pop()));
    }
    ops.pop();
}

If ops is empty, calling ops.peek() throws EmptyStackException.

✅ Fixed version:

else if (tokens[i] == ')') {
    while (!ops.isEmpty() && ops.peek() != '(') {
        if (values.size() < 2)
            throw new IllegalArgumentException("Malformed expression");
        values.push(applyOp(ops.pop(), values.pop(), values.pop()));
    }
    if (!ops.isEmpty()) ops.pop();
}

🔐 Final Thoughts

Improper error handling is one of the simplest but most dangerous bugs. It’s easy to overlook, but as this challenge showed me, even a small oversight can expose a big part of your system.

Whether you're building or breaking apps — remember: handle errors properly.