starred/GeoIntel

Fork 0

mirror of https://github.com/atiilla/GeoIntel.git synced 2026-04-26 16:15:57 +03:00

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

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/17
Author: @atiilla
Created: 3/9/2026
Status: ✅ Merged
Merged: 3/9/2026
Merged by: @atiilla

Base: main ← Head: alert-autofix-34

📝 Commits (2)

61fca7b Potential fix for code scanning alert no. 34: Information exposure through an exception
16c233a Merge branch 'main' into alert-autofix-34

📊 Changes

2 files changed (+6 additions, -1 deletions)

View changed files

📝 geointel/geointel.py (+2 -0)
📝 geointel/web_server.py (+4 -1)

📄 Description

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:

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.
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.

_{🔄 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/17 **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-34` --- ### 📝 Commits (2) - [`61fca7b`](https://github.com/atiilla/GeoIntel/commit/61fca7bf734f77dd7fc8f5325816825a93decc4b) Potential fix for code scanning alert no. 34: Information exposure through an exception - [`16c233a`](https://github.com/atiilla/GeoIntel/commit/16c233a70709841d642631a84d488b72b547a43c) Merge branch 'main' into alert-autofix-34 ### 📊 Changes **2 files changed** (+6 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `geointel/geointel.py` (+2 -0) 📝 `geointel/web_server.py` (+4 -1) </details> ### 📄 Description Potential fix for [https://github.com/atiilla/GeoIntel/security/code-scanning/34](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._ --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

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

closed this issue
added the
pull-request
label

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/GeoIntel#18

No description provided.

Rows
Columns