[INS-444] Fix verification logic in Mesibo detector

[mustansir14]

Problem

The Mesibo detector was incorrectly marking unverified secrets as verified. The original implementation sent a GET request to https://api.mesibo.com/api.php?op=useradd&token=<token> and checked whether the response body contained the string "AUTHFAIL". This endpoint no longer works correctly — it now returns 502 on all requests, meaning the "AUTHFAIL" string is never present and every candidate token is marked as verified regardless of its validity. Even setting aside the broken endpoint, checking for a specific error string in the body is an unreliable verification strategy compared to inspecting a structured response field.

Fix

Switched to the current Mesibo backend API (POST https://api.mesibo.com/backend) as documented at https://docs.mesibo.com/api/backend-api/.

The backend API always returns HTTP 200. The actual outcome is encoded in the JSON response body via a code field, which contains an RFC 9110 compliant HTTP status code. We probe using the useradd operation:

• A valid token passes authentication but fails the operation due to missing required user parameters, yielding code: 400.
• An invalid or unauthorized token yields a different code (e.g. 401).

The verification logic was refactored into a dedicated verify() method that:

1. POSTs a JSON payload with op=useradd and the candidate token.
2. Checks that the HTTP status is 200, returning a verification error otherwise.
3. Parses the JSON response into a typed apiResponse struct.
4. Returns true only if code == 400.

All errors are wrapped with context using fmt.Errorf(..., %w) and surfaced via SetVerificationError.

Tests

Added a test case "found, verification error on 502" to the integration test suite using common.ConstantResponseHttpClient(502, "") to simulate an unexpected HTTP status from the API, asserting that the result is unverified and a verification error is set.

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

---

Note

Medium Risk
Changes Mesibo secret verification behavior by switching endpoints and parsing JSON code responses, which can impact detection accuracy (false positives/negatives) and adds new HTTP request/response error handling paths.

Overview
Updates the Mesibo detector to stop using the legacy GET /api.php probe and instead verify tokens via POST https://api.mesibo.com/backend, parsing the JSON code field and marking secrets verified only when code == 400.

Refactors verification into a dedicated verify() method with an injectable HTTP client and surfaces unexpected API responses as VerificationErrors; integration tests were updated to use go-cmp and now include a case asserting verification errors on non-200 (simulated 502) responses.

^{Reviewed by Cursor Bugbot for commit 5cdc6d4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5cdc6d4. Configure here.}

[cursor]

Missing defaultClient causes new HTTP client per call

Low Severity

The getClient() method calls common.SaneHttpClient() on every invocation when s.client is nil, creating a new HTTP client and transport each time. Every other detector in the codebase (e.g., abstract, abuseipdb, adafruitio) initializes a package-level defaultClient variable once via var defaultClient = common.SaneHttpClient() and returns that from getClient(). This deviation prevents HTTP connection reuse across verification calls.

 

^{Reviewed by Cursor Bugbot for commit 5cdc6d4. Configure here.}