feat(skills): add validation methods doctrine skill - #995
feat(skills): add validation methods doctrine skill#995sandiyochristan wants to merge 2 commits into
Conversation
Greptile SummaryAdds a user-selectable validation-methods skill that teaches canary, differential, browser-based, and out-of-band strategies for validating security findings.
Confidence Score: 2/5The PR should not merge until its validation criteria distinguish observed data flow or expected functionality from demonstrated security impact. The new skill tells agents to confirm XSS from reflection, IDOR from status codes, and SSRF from an expected webhook callback without establishing executable or unauthorized impact, so it can systematically promote false positives into final reports. Files Needing Attention: strix/skills/custom/validation_methods.md Important Files Changed
Prompt To Fix All With AI### Issue 1
strix/skills/custom/validation_methods.md:35-39
**Reflection is not exploit confirmation**
When a unique payload appears in an output, this procedure treats the finding as confirmed even though reflection establishes only data flow, not executable impact. Encoded text or content placed in a non-executable context will therefore be promoted to a validated XSS or injection report.
### Issue 2
strix/skills/custom/validation_methods.md:75-78
**Status codes do not prove IDOR**
When an authenticated user receives `200` for another user's profile, this example declares IDOR without establishing that the resource is private or comparing the returned data and permitted behavior. Legitimately shared or sanitized foreign profiles will therefore be reported as confirmed authorization vulnerabilities.
### Issue 3
strix/skills/custom/validation_methods.md:135-139
**Expected callbacks do not prove SSRF**
When an endpoint is designed to fetch URLs or deliver webhooks, receiving its callback proves server-side request capability but not access to a prohibited destination, protocol, credential context, or network boundary. This example consequently classifies normal webhook delivery as validated SSRF.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "feat(skills): add validation methods doc..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ``` | ||
| Input: <img src=x onerror="fetch('//canary.strix_7f3a2b')"> | ||
| Check: Does the payload appear unencoded in the response HTML? | ||
| Proof: DOM snapshot showing the <img> tag rendered with onerror intact | ||
| ``` |
There was a problem hiding this comment.
When a unique payload appears in an output, this procedure treats the finding as confirmed even though reflection establishes only data flow, not executable impact. Encoded text or content placed in a non-executable context will therefore be promoted to a validated XSS or injection report.
Knowledge Base Used: Skills Library
Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/skills/custom/validation_methods.md
Line: 35-39
Comment:
**Reflection is not exploit confirmation**
When a unique payload appears in an output, this procedure treats the finding as confirmed even though reflection establishes only data flow, not executable impact. Encoded text or content placed in a non-executable context will therefore be promoted to a validated XSS or injection report.
**Knowledge Base Used:** [Skills Library](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/skills-library.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| Own: GET /api/users/42/profile (with user 42's token) → 200 | ||
| Foreign: GET /api/users/43/profile (with user 42's token) → 200 (IDOR confirmed) | ||
| Control: GET /api/users/43/profile (no token) → 401 (auth works, authz doesn't) | ||
| ``` |
There was a problem hiding this comment.
When an authenticated user receives 200 for another user's profile, this example declares IDOR without establishing that the resource is private or comparing the returned data and permitted behavior. Legitimately shared or sanitized foreign profiles will therefore be reported as confirmed authorization vulnerabilities.
Knowledge Base Used: Skills Library
Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/skills/custom/validation_methods.md
Line: 75-78
Comment:
**Status codes do not prove IDOR**
When an authenticated user receives `200` for another user's profile, this example declares IDOR without establishing that the resource is private or comparing the returned data and permitted behavior. Legitimately shared or sanitized foreign profiles will therefore be reported as confirmed authorization vulnerabilities.
**Knowledge Base Used:** [Skills Library](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/skills-library.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| - DNS rebinding confirmation | ||
| - Email/webhook trigger verification | ||
| - Any asynchronous or blind vulnerability class | ||
|
|
||
| **How It Works** |
There was a problem hiding this comment.
When an endpoint is designed to fetch URLs or deliver webhooks, receiving its callback proves server-side request capability but not access to a prohibited destination, protocol, credential context, or network boundary. This example consequently classifies normal webhook delivery as validated SSRF.
Knowledge Base Used: Skills Library
Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/skills/custom/validation_methods.md
Line: 135-139
Comment:
**Expected callbacks do not prove SSRF**
When an endpoint is designed to fetch URLs or deliver webhooks, receiving its callback proves server-side request capability but not access to a prohibited destination, protocol, credential context, or network boundary. This example consequently classifies normal webhook delivery as validated SSRF.
**Knowledge Base Used:** [Skills Library](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/skills-library.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Codifies four systematic validation strategies — canary, heuristic, headless, and out-of-band — with a strategy selection matrix mapping finding classes to primary/fallback strategies. Closes usestrix#992
- Clarify that canary reflection alone does not prove XSS execution; require executable context or headless confirmation - Require response body comparison for IDOR, not just status codes - Require prohibited-destination evidence for SSRF, not just callbacks from URL-fetching endpoints
8a8237a to
e204a84
Compare
1 participant
No description provided.