reject oversized websocket origin in callback_broker_mqtt

[jmestwa-coder]

WebSocket Origin allowlist fails open on an oversized header
When ws_allowed_origin is configured, a present Origin header longer than the 256-byte copy buffer makes lws_hdr_copy return <= 0, so the gate reads it as "no Origin" and lets the connection through, bypassing the CSWSH allowlist. A browser served from an attacker-controlled origin string over 255 bytes hits this path. Keyed the allow/deny on lws_hdr_total_length so a present-but-unverifiable Origin is rejected while a genuinely absent one still passes for native clients.

[wolfSSL-Bot]

Can one of the admins verify this patch?

[dgarske]

Hi @jmestwa-coder , thank you for this code contribution. I have asked @embhorn to look it over. Can you tell us more about your project and use of wolfMQTT? In order to accept this code we need to have a signed contributor agreement. Please email support at wolfssl dot com and reference this pull request.
Thanks, David Garske, wolfSSL

[Copilot]

Pull request overview

This PR hardens the embedded broker’s libwebsockets handshake filtering so that an oversized Origin header cannot bypass the configured WebSocket Origin allowlist (CSWSH defense).

Changes:

• Treat a present-but-unreadable Origin (e.g., too large for the copy buffer) as rejectable by checking lws_hdr_total_length() rather than relying solely on lws_hdr_copy()’s return code.
• Improve the rejection log message to avoid logging uninitialized/invalid origin data when the header is oversized.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jmestwa-coder]

Sure. I'm running wolfMQTT in broker mode with the websocket transport on an embedded IoT gateway, and I keep ws_allowed_origin set so browser dashboards stay pinned to our own front end. That allowlist path is what I was going through when I noticed an oversized Origin slips past it. I'll email support@wolfssl.com and reference this PR to get the contributor agreement signed.