Unbounded default frame size allows DoS via memory exhaustion (OOM) #1499
Description
Description
I have identified a potential Denial of Service (DoS) vulnerability in the default configuration of Java-WebSocket.
The library currently appears to initialize with no strict upper limit (or an excessively high limit) on incoming WebSocket frame sizes by default. Consequently, if a developer instantiates a server without explicitly configuring, the application is immediately vulnerable to memory exhaustion attacks.
The Issue
An attacker can initiate a handshake and subsequently send a frame declaring a massive payload length (e.g., several GBs). The server attempts to allocate a buffer to accommodate this frame, leading to an immediate java.lang.OutOfMemoryError and crashing the JVM.
While it is possible for developers to manually set these limits, the default behavior is unsafe.
Impact
- Severity: High
- Consequence: Application crash / Denial of Service.
- Prerequisites: None (if the developer uses the default constructor/settings).
Recommendation
The library should adhere to the "Secure by Default" philosophy.
- Enforce a reasonable default limit: Instead of allowing
Integer.MAX_VALUEor unlimited sizes, the default should be set to a conservative value (e.g., 16MB or 64MB) that covers 99% of use cases. - Opt-in for larger sizes: If a specific use case requires transferring gigabytes of data in a single frame, the developer should be required to explicitly increase the limit.
Leaving the limit open by default places an undue burden on the user to be aware of this specific attack vector, whereas a safe default protects them automatically.