Guessable CAPTCHA in /common/mall/kaptcha of newbee-mall (CWE-804)

[ez-lbz]

Guessable CAPTCHA in /common/mall/kaptcha of newbee-mall (CWE-804)

Summary

In newbee-mall, the CAPTCHA mechanism relies on the client explicitly requesting /common/mall/kaptcha to obtain a code. The CAPTCHA is reset only when /common/mall/kaptcha is accessed, which makes the validation ineffective. Attackers can bypass the intended protection by directly sending requests, allowing brute-force password attempts.

Analysis

Reviewing the /common/mall/kaptcha implementation shows that the CAPTCHA value is stored in the session.

@GetMapping("/common/mall/kaptcha")
    public void mallKaptcha(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws Exception {
        httpServletResponse.setHeader("Cache-Control", "no-store");
        httpServletResponse.setHeader("Pragma", "no-cache");
        httpServletResponse.setDateHeader("Expires", 0);
        httpServletResponse.setContentType("image/png");

        ShearCaptcha shearCaptcha= CaptchaUtil.createShearCaptcha(110, 40, 4, 2);

        // 验证码存入session
        httpServletRequest.getSession().setAttribute(Constants.MALL_VERIFY_CODE_KEY, shearCaptcha);

        // 输出图片流
        shearCaptcha.write(httpServletResponse.getOutputStream());
    }

As a result, when the same session is reused, the same CAPTCHA is applied repeatedly. This allows attackers to predict and brute-force the CAPTCHA without restriction.

Exploitation

Captured traffic during a front-end request demonstrates this behavior.

By reusing the same session and sending repeated login requests, brute-force attempts can bypass the CAPTCHA protection.

Impact

• CAPTCHA fails to prevent brute-force attacks

• Increased risk of account takeover through automated guessing

Remediation

The CAPTCHA should be regenerated on every login attempt, rather than depending on the client-side request to /common/mall/kaptcha. This ensures uniqueness and prevents brute-force bypass.