Fix DB Query Leak when passing too long Values to Users Endpoint - #4077
adrianhoelzl-sap wants to merge 6 commits into
Conversation
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Database-error sanitization gaps and incomplete validation of persisted fields remain.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 2
Open (3)
What changed in this PR
Adds SCIM field-length validation and database-error sanitization to prevent oversized user data from reaching database columns.
Changes:
- Validates username, given name, and family name lengths.
- Adds endpoint and unit tests for oversized values.
- Adds database-error handling.
| File | Summary |
|---|---|
uaa/src/test/java/org/cloudfoundry/identity/uaa/scim/endpoints/ScimUserEndpointsMockMvcTests.java |
Adds endpoint regression tests. |
server/src/test/java/org/cloudfoundry/identity/uaa/scim/util/ScimUtilsTest.java |
Tests field-length validation boundaries. |
server/src/main/java/org/cloudfoundry/identity/uaa/scim/util/ScimUtils.java |
Implements field-length validation. |
server/src/main/java/org/cloudfoundry/identity/uaa/scim/endpoints/ScimUserEndpoints.java |
Applies validation and sanitizes database errors. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // Never leak DB internals (SQL statements, column names, driver messages) to the caller | ||
| // for any DataAccessException not explicitly mapped to a status above. | ||
| if (e.getStatus() == HttpStatus.INTERNAL_SERVER_ERROR && t instanceof DataAccessException) { | ||
| e = new ScimException("A database error occurred.", t, HttpStatus.INTERNAL_SERVER_ERROR); |
| // Never leak DB internals (SQL statements, column names, driver messages) to the caller | ||
| // for any DataAccessException not explicitly mapped to a status above. | ||
| if (e.getStatus() == HttpStatus.INTERNAL_SERVER_ERROR && t instanceof DataAccessException) { | ||
| e = new ScimException("A database error occurred.", t, HttpStatus.INTERNAL_SERVER_ERROR); | ||
| } | ||
| } | ||
| } |
| if (user.getGivenName() != null && user.getGivenName().length() > 255) { | ||
| throw new InvalidScimResourceException("Given name must be no more than 255 characters in length."); | ||
| } | ||
| if (user.getFamilyName() != null && user.getFamilyName().length() > 255) { | ||
| throw new InvalidScimResourceException("Family name must be no more than 255 characters in length."); |
| incrementErrorCounts(e); | ||
| // User can supply trace=true or just trace (unspecified) to get stack | ||
| // traces | ||
| boolean trace = request.getParameter("trace") != null && !"false".equals(request.getParameter("trace")); |
There was a problem hiding this comment.
Hmm, should we remove this trace option? It does not seem the best idea to expose exception stack trace as API response. Maybe adding a traceId to the response that is also logged server side would be the best of both worlds.
|
|
||
| @ExceptionHandler | ||
| public View handleException(Exception t, HttpServletRequest request) throws ScimException, InternalUserManagementDisabledException { | ||
| logger.error("Unhandled exception in SCIM user endpoints. {}", t.getMessage()); |
There was a problem hiding this comment.
This is a strange decision - log server side only the exception message, but return to API caller HTTP response with full stack trace. I would prefer the opposite.
|
@adrianhoelzl-sap is it ready for review ? because of draft status |


No description provided.