You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, each masking could be drawn from a cryptographically strong random number generator. If the same key is used or a decipherable pattern exists for how the next key is chosen, the attacker can send a message that, when masked, could appear to be an HTTP request (by taking the message the attacker wishes to see on the wire and masking it with the next masking key to be used, the masking key will effectively unmask the data when the client applies it).
According to this specification the library should be using SecureRandom to prevent brute force attacks.
Environment(please complete the following information):
Version used: 1.5.1
Java version: 1.8
Operating System and version: Android
Endpoint Name and version:
Link to your project:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
@PhilipRoman I also tried to ping @TooTallNate but he did not respond yet.
The same issue was raised here but looking at the spec again I would not say that it is only used to defeat proxies.
The masking key is a 32-bit value chosen at random by the client. When preparing a masked frame, the client MUST pick a fresh masking key from the set of allowed 32-bit values. The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame. The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. RFC 4086 [RFC4086] discusses what entails a suitable source of entropy for security-sensitive applications.
Our veracode scan flagged usage of
Random
in Draft_6455.java as a vulnerability.https://cwe.mitre.org/data/definitions/331.html
According to Websocket Protocol:
For example, each masking could be drawn from a cryptographically strong random number generator. If the same key is used or a decipherable pattern exists for how the next key is chosen, the attacker can send a message that, when masked, could appear to be an HTTP request (by taking the message the attacker wishes to see on the wire and masking it with the next masking key to be used, the masking key will effectively unmask the data when the client applies it).
According to this specification the library should be using SecureRandom to prevent brute force attacks.
Environment(please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: