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
My team is conducting academic research on Java Cryptography API based misuse using your tool. We found that we could not detect some potential cryptographic misuses.
We believe this may be due to underlying implementation or design gaps. Each cryptographic vulnerability was generated as a barebone Java project that only contained a single vulnerability in the main function and used up to two java source files. A jar was made which was then scanned using CryptoGuard.
Additionally, all cryptographic API calls were from Java Cryptographic Architecture (JCA).
Attempting to use an insecure validation of an overridden checkServerTrusted method that is created within an anonymous inner class object created from an empty abstract class which implements the X509TrustManager interface from JCA, which we believe is due to not detecting security exceptions thrown under impossible conditions; e.g., if(!(true || arg0== null || arg1 == null)) throw new CertificateException();
Attempting to use an insecure analysis of vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an empty interface that implements the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g., if(true || session == null) return true; return false;
Attempting to use a vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an abstract class that extends the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g., if(true || session == null) return true; return false;
Hi,
My team is conducting academic research on Java Cryptography API based misuse using your tool. We found that we could not detect some potential cryptographic misuses.
We believe this may be due to underlying implementation or design gaps. Each cryptographic vulnerability was generated as a barebone Java project that only contained a single vulnerability in the main function and used up to two java source files. A jar was made which was then scanned using CryptoGuard.
Additionally, all cryptographic API calls were from Java Cryptographic Architecture (JCA).
Environment
Problem
Attempting to use an insecure validation of an overridden checkServerTrusted method that is created within an anonymous inner class object created from an empty abstract class which implements the X509TrustManager interface from JCA, which we believe is due to not detecting security exceptions thrown under impossible conditions; e.g.,
if(!(true || arg0== null || arg1 == null)) throw new CertificateException();
Attempting to use an insecure analysis of vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an empty interface that implements the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g.,
if(true || session == null) return true; return false;
Attempting to use a vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an abstract class that extends the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g.,
if(true || session == null) return true; return false;
Please let me know if you need any additional information (e.g., logs from our side) in fixing these issues.
Thanks! :)
The text was updated successfully, but these errors were encountered: