Potential fix for code scanning alert no. 34: Information exposure through an exception

[atiilla]

Potential fix for https://github.com/atiilla/GeoIntel/security/code-scanning/34

General approach: Ensure that client-facing responses never include raw exception messages or type names. Instead, log detailed error information on the server and return generic messages. Specifically, adjust GeoIntel.locate so that on errors it returns a safe, generic error structure without str(e) or type(e).__name__, and, in the web handler, avoid blindly returning whatever result contains on error.

Best concrete fix with minimal behavior change:

1. In geointel/geointel.py, update the two except blocks in GeoIntel.locate:

   • Keep detailed logging, including str(e) and exc_info=True.
   • Change the returned dicts to only contain generic error messages that do not echo str(e) or the exception class name. For example:
     • For GeoIntelError: "error": "Request cannot be processed" and optionally a generic "details": "GeoIntelError" or omit details.
     • For generic Exception: "error": "An unexpected error occurred" and omit or genericize details.
   • This preserves that callers see an "error" key when something goes wrong, but without internal detail.

2. In geointel/web_server.py’s analyze_image:

   • Instead of returning jsonify(result), 400 directly when 'error' in result, wrap it into a safer structure that does not trust arbitrary contents from GeoIntel.locate. For example:
     • Use error_message = result.get("error") or "Request could not be processed" but clamp it to a short, non-technical message.
     • Optionally, only allow a limited set of known user-safe messages, or fall back to a default.
   • Alternatively, drop result entirely and always return a fixed generic 400 for these cases, but that is a slightly larger behavior change.

Given the information-exposure focus, the single most impactful change is to sanitize what GeoIntel.locate returns, removing inclusion of str(e) in returned data, and to avoid echoing any untrusted details to clients.

Concretely:

• Edit geointel/geointel.py lines 46–59 to:

  • Keep logger.error(...) calls but adjust return dicts to:
    • For GeoIntelError: no str(e) or type name in the client-visible dict (or use a non-specific code like "invalid_request").
    • For Exception: no str(e) at all in returned dict.

• Edit geointel/web_server.py around lines 169–174:

  • When 'error' in result, construct a new dict with a generic message rather than passing through the entire result. This also future-proofs against any other sensitive fields that might be added to result later.

No new utilities or external libraries are required; we only use existing logging and Flask facilities.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.