[PR #18] [MERGED] Potential fix for code scanning alert no. 35: Information exposure through an exception #17

New issue

Closed

opened 2026-03-15 11:26:51 +03:00 by kerem · 0 comments

kerem commented

2026-03-15 11:26:51 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/atiilla/GeoIntel/pull/18
Author: @atiilla
Created: 3/9/2026
Status: ✅ Merged
Merged: 3/9/2026
Merged by: @atiilla

Base: main ← Head: alert-autofix-35

📝 Commits (1)

5cb6dbb Potential fix for code scanning alert no. 35: Information exposure through an exception

📊 Changes

1 file changed (+4 additions, -2 deletions)

View changed files

📝 geointel/geointel.py (+4 -2)

📄 Description

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

In general, to fix this type of issue you keep detailed exception information on the server (logs) and send only high-level, non-sensitive messages to clients. You avoid returning raw exception messages or stack traces, especially for generic exceptions.

For this codebase, the cleanest fix without changing functionality is:

In geointel/geointel.py, change the GeoIntel.locate error handling so that:
- For GeoIntelError, still distinguish the error type, but do not expose str(e) directly; instead send a stable, generic message while logging the detailed exception.
- For generic Exception, do not return str(e) to the caller; instead return a generic “unexpected error” message, possibly with a non-sensitive details field like a static string or error code.
In geointel/web_server.py, keep the existing analyze_image logic, but when 'error' in result, ensure that the data from locate no longer contains raw exception text, so returning it is safe. No structural change is needed in analyze_image once locate is sanitized.

Concretely:

In GeoIntel.locate, update the two except blocks:
- Keep logging with full details (logger.error(..., exc_info=True)).
- Return dicts with:
  - "error": a generic message (for example "GeoIntel processing error" or "An unexpected error occurred").
  - "details": for GeoIntelError, a non-sensitive identifier such as type(e).__name__; for generic exceptions, a generic string like "Internal processing error" instead of str(e).

No changes are needed to imports, and no new methods or external libraries are required.

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

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/atiilla/GeoIntel/pull/18 **Author:** [@atiilla](https://github.com/atiilla) **Created:** 3/9/2026 **Status:** ✅ Merged **Merged:** 3/9/2026 **Merged by:** [@atiilla](https://github.com/atiilla) **Base:** `main` ← **Head:** `alert-autofix-35` --- ### 📝 Commits (1) - [`5cb6dbb`](https://github.com/atiilla/GeoIntel/commit/5cb6dbb18a8a3679367d89e459237e88ac89b5fe) Potential fix for code scanning alert no. 35: Information exposure through an exception ### 📊 Changes **1 file changed** (+4 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `geointel/geointel.py` (+4 -2) </details> ### 📄 Description Potential fix for [https://github.com/atiilla/GeoIntel/security/code-scanning/35](https://github.com/atiilla/GeoIntel/security/code-scanning/35) In general, to fix this type of issue you keep detailed exception information on the server (logs) and send only high-level, non-sensitive messages to clients. You avoid returning raw exception messages or stack traces, especially for generic exceptions. For this codebase, the cleanest fix without changing functionality is: 1. In `geointel/geointel.py`, change the `GeoIntel.locate` error handling so that: - For `GeoIntelError`, still distinguish the error type, but do not expose `str(e)` directly; instead send a stable, generic message while logging the detailed exception. - For generic `Exception`, do not return `str(e)` to the caller; instead return a generic “unexpected error” message, possibly with a non-sensitive `details` field like a static string or error code. 2. In `geointel/web_server.py`, keep the existing `analyze_image` logic, but when `'error' in result`, ensure that the data from `locate` no longer contains raw exception text, so returning it is safe. No structural change is needed in `analyze_image` once `locate` is sanitized. Concretely: - In `GeoIntel.locate`, update the two `except` blocks: - Keep logging with full details (`logger.error(..., exc_info=True)`). - Return dicts with: - `"error"`: a generic message (for example `"GeoIntel processing error"` or `"An unexpected error occurred"`). - `"details"`: for `GeoIntelError`, a non-sensitive identifier such as `type(e).__name__`; for generic exceptions, a generic string like `"Internal processing error"` instead of `str(e)`. No changes are needed to imports, and no new methods or external libraries are required. _Suggested fixes powered by Copilot Autofix. Review carefully before merging._ --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>