Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft_6455 flagged by Veracode CWE-331 replace Random with SecureRandom #1132

Closed
dsuresh-ap opened this issue Mar 19, 2021 · 2 comments · Fixed by #1133
Closed

Draft_6455 flagged by Veracode CWE-331 replace Random with SecureRandom #1132

dsuresh-ap opened this issue Mar 19, 2021 · 2 comments · Fixed by #1133

Comments

@dsuresh-ap
Copy link

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):

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

@PhilipRoman
Copy link
Collaborator

Can @TooTallNate delete this issue and open a security advisory?

marci4 added a commit to marci4/Java-WebSocket-Dev that referenced this issue Mar 22, 2021
@marci4
Copy link
Collaborator

marci4 commented Mar 22, 2021

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

What do you think?

Pushed #1133 with the change.

Best regards,
Marcel

@marci4 marci4 mentioned this issue Mar 22, 2021
12 tasks
@marci4 marci4 added this to the Release 1.5.2 milestone Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants