ORM Leaking More Than You Joined For #1707
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🤖 Automated Content Update
This PR was automatically generated by the HackTricks News Bot based on a technical blog post.
📝 Source Information
🎯 Content Summary
This article extends elttam's ORM Leak research by presenting concrete bugs and exploitation patterns in multiple ORMs (Beego, Harbor, Prisma, Entity Framework, OData, and middleware), showing how robust filtering/search features can leak sensitive fields (passwords, salts, tokens, TOTP secrets) or bypass authentication. It preserves a low-level focus on how filter expressions are parsed, how user input is mapped to ORM operators, and how attackers can practically exploit these behaviours.🔧 Technical Details
Beego / Harbor filter expression overwrite via
parseExprsbug: Beego’sparseExprssplits filter keys on__and iterates the segments. If the first segment is a non-relational field (e.g.,email) but additional segments look like field names (e.g.,password), Beego effectively overwrites the field with the later segment. Thus, an expression likeemail__password__startswithis interpreted aspassword__startswith. Any protection that only validates the first segment (e.g., checkingemailis non-sensitive) can be bypassed by chaining a sensitive field name after it. Attackers can craftfield1__field2__oppayloads to filter onfield2even whenfield2is marked non-filterable, then use response-based oracles to leak its contents.Bypassing separator-count limits using application-level operator mappings🤖 Agent Actions
Summary:
parseExprsbug enable secret-leak oracles plus the progression of Harbor’s patches and bypasses.$filtercomparison oracles.Tests: Not run (documentation-only changes).
This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.
📚 Repository Maintenance
All .md files have been checked for proper formatting (headers, includes, etc.).