Skip to content

feat(skills): add WebSocket security testing skill - #996

Open
sandiyochristan wants to merge 2 commits into
usestrix:mainfrom
sandiyochristan:contrib/skill-websocket
Open

feat(skills): add WebSocket security testing skill#996
sandiyochristan wants to merge 2 commits into
usestrix:mainfrom
sandiyochristan:contrib/skill-websocket

Conversation

@sandiyochristan

@sandiyochristan sandiyochristan commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@greptile-apps

greptile-apps Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

Adds a standalone WebSocket security-testing skill covering discovery, handshake and message authorization, injection, framework-specific attacks, transport behavior, denial of service, validation, and false-positive guidance.

  • Documents native WebSocket, Socket.IO, GraphQL subscription, SignalR, and ActionCable testing.
  • Adds concrete reconnaissance probes, payloads, authorization tests, and evidence expectations.
  • Includes unsafe unbounded denial-of-service instructions and incomplete validation guidance for token leakage and malformed-frame behavior.

Confidence Score: 3/5

This PR should not merge until the WebSocket denial-of-service procedures are bounded with staged rates, minimal-impact validation, and explicit stop conditions.

The new skill is operational guidance consumed directly by autonomous agents and currently directs maximum connection use and flooding without a global or local safety bound; its token-leakage and malformed-frame sections also need clearer evidence requirements.

Files Needing Attention: strix/skills/protocols/websocket.md

Security Review

The denial-of-service section directs autonomous agents to maximize connections and flood in-scope targets without proactive limits or stop conditions, creating a realistic service-disruption path.

Important Files Changed

Filename Overview
strix/skills/protocols/websocket.md Adds broad WebSocket testing guidance, but its unbounded destructive-load instructions can disrupt targets and several test classes lack sufficient evidence and false-positive criteria.
Prompt To Fix All With AI
### Issue 1
strix/skills/protocols/websocket.md:137-147
**Unbounded denial-of-service testing**

When an autonomous agent follows these instructions against an authorized production or shared target, it opens maximum connections and floods resource-intensive payloads without staged limits or stop conditions, causing connection, memory, CPU, or bandwidth exhaustion that can disrupt the service. Add conservative initial limits, explicit escalation criteria, and immediate stop conditions. **How this was verified:** The skill is loaded verbatim as operational guidance, and neither it nor the global agent prompt places a proactive bound on destructive load.

### Issue 2
strix/skills/protocols/websocket.md:88-89
**Unverified query-token leakage claim**

This treats every query-string token as leaking through Referer, logs, proxies, and browser history without requiring an attacker-observable sink. Require evidence of an actual exposure channel, such as a third-party Referer under the active policy or accessible log entry, to prevent false-positive credential-leakage findings and unsupported remediation.

### Issue 3
strix/skills/protocols/websocket.md:191-196
**Missing protocol-rejection validation**

The skill recommends malformed frames, reserved opcodes, and incomplete fragments but never explains that a compliant protocol error or disconnect is expected behavior. Require demonstrated cross-connection impact, persistent degradation, inspection bypass, or another concrete consequence so normal RFC-compliant rejection is not reported as a frame-abuse or denial-of-service vulnerability.

---

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 WebSocket security tes..." | Re-trigger Greptile

Comment thread strix/skills/protocols/websocket.md Outdated
Comment on lines +137 to +147
- Open maximum connections without sending data
- Slowloris-style: keep connections alive with periodic pings

**Message Flooding**
- Rapid message sends to exhaust server resources
- Large messages exceeding expected size limits
- Deeply nested JSON payloads

**Frame Abuse**
- Fragmented messages never completed
- Ping floods forcing pong responses

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 security Unbounded denial-of-service testing

When an autonomous agent follows these instructions against an authorized production or shared target, it opens maximum connections and floods resource-intensive payloads without staged limits or stop conditions, causing connection, memory, CPU, or bandwidth exhaustion that can disrupt the service. Add conservative initial limits, explicit escalation criteria, and immediate stop conditions. How this was verified: The skill is loaded verbatim as operational guidance, and neither it nor the global agent prompt places a proactive bound on destructive load.

Knowledge Base Used: Skills Library

Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/skills/protocols/websocket.md
Line: 137-147

Comment:
**Unbounded denial-of-service testing**

When an autonomous agent follows these instructions against an authorized production or shared target, it opens maximum connections and floods resource-intensive payloads without staged limits or stop conditions, causing connection, memory, CPU, or bandwidth exhaustion that can disrupt the service. Add conservative initial limits, explicit escalation criteria, and immediate stop conditions. **How this was verified:** The skill is loaded verbatim as operational guidance, and neither it nor the global agent prompt places a proactive bound on destructive load.

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

Comment thread strix/skills/protocols/websocket.md Outdated
Comment on lines +88 to +89
- Auth tokens in WebSocket URL query params (`wss://target.com/ws?token=SECRET`) leak via Referer, server logs, proxy logs, browser history
- Prefer token in first message or `Sec-WebSocket-Protocol` header

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Unverified query-token leakage claim

This treats every query-string token as leaking through Referer, logs, proxies, and browser history without requiring an attacker-observable sink. Require evidence of an actual exposure channel, such as a third-party Referer under the active policy or accessible log entry, to prevent false-positive credential-leakage findings and unsupported remediation.

Knowledge Base Used: Skills Library

Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/skills/protocols/websocket.md
Line: 88-89

Comment:
**Unverified query-token leakage claim**

This treats every query-string token as leaking through Referer, logs, proxies, and browser history without requiring an attacker-observable sink. Require evidence of an actual exposure channel, such as a third-party Referer under the active policy or accessible log entry, to prevent false-positive credential-leakage findings and unsupported remediation.

**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!

Comment on lines +191 to +196
## False Positives

- Server validates Origin but test was same-origin (not actually CSWSH)
- WebSocket requires non-cookie auth token that attacker cannot obtain cross-origin
- Channel names appear guessable but server enforces membership check before delivering messages
- Admin namespace accepts connection but returns empty/error responses for all operations

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Missing protocol-rejection validation

The skill recommends malformed frames, reserved opcodes, and incomplete fragments but never explains that a compliant protocol error or disconnect is expected behavior. Require demonstrated cross-connection impact, persistent degradation, inspection bypass, or another concrete consequence so normal RFC-compliant rejection is not reported as a frame-abuse or denial-of-service vulnerability.

Knowledge Base Used: Skills Library

Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/skills/protocols/websocket.md
Line: 191-196

Comment:
**Missing protocol-rejection validation**

The skill recommends malformed frames, reserved opcodes, and incomplete fragments but never explains that a compliant protocol error or disconnect is expected behavior. Require demonstrated cross-connection impact, persistent degradation, inspection bypass, or another concrete consequence so normal RFC-compliant rejection is not reported as a frame-abuse or denial-of-service vulnerability.

**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!

Covers handshake auth bypass, CSWSH, message-level authorization,
injection, Socket.IO namespace abuse, and GraphQL subscription security.

Addresses usestrix#757
- Add operator approval gate and conservative limits for DoS testing
- Require evidence of actual exposure channel for token leakage claims
- Clarify that RFC-compliant frame rejection is expected behavior, not
  a vulnerability — require cross-connection impact for valid findings
@sandiyochristan
sandiyochristan force-pushed the contrib/skill-websocket branch from 9bca76c to 5e9c9dc Compare August 6, 2026 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant