Many languages: Update broken algo qhelp

[owen-mc]

Currently it focusses too much on the risk of data being decrypted, and doesn't explain why using weak algorithms can be a problem in other contexts.

Note that many of these queries would only alert for encryption algorithms, so the current text makes sense for them. But java/potentially-weak-cryptographic-algorithm, which shares the same help text as java/weak-cryptographic-algorithm, alerts for more algorithms, and so does js/weak-cryptographic-algorithm. It seems good to update all the qhelp files at once.

[Copilot]

Pull Request Overview

This PR updates the qhelp documentation for broken cryptographic algorithm queries across multiple programming languages to provide a more comprehensive explanation of the security risks beyond just data decryption.

• Updates the overview text to explain that weak cryptographic algorithms may compromise confidentiality, integrity, and authenticity
• Adds specific examples of risks for encryption, hashing, and digital signature algorithms
• Standardizes the documentation across Rust, Ruby, Python, JavaScript, Java, and C++ implementations

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
rust/ql/src/queries/security/CWE-327/BrokenCryptoAlgorithm.qhelp	Enhanced overview with broader security context and specific risk examples
ruby/ql/src/queries/security/cwe-327/BrokenCryptoAlgorithm.qhelp	Updated documentation with comprehensive security risk explanations
python/ql/src/Security/CWE-327/BrokenCryptoAlgorithm.qhelp	Improved overview text with detailed risk scenarios
javascript/ql/src/Security/CWE-327/BrokenCryptoAlgorithm.qhelp	Enhanced documentation with broader security risk context
java/ql/src/Security/CWE/CWE-327/BrokenCryptoAlgorithm.qhelp	Updated overview with comprehensive security guarantees explanation
cpp/ql/src/Security/CWE/CWE-327/BrokenCryptoAlgorithm.qhelp	Enhanced documentation with detailed security risk examples

[github-actions]

QHelp previews:

cpp/ql/src/Security/CWE/CWE-327/BrokenCryptoAlgorithm.qhelp

Use of a broken or risky cryptographic algorithm

Using broken or weak cryptographic algorithms may compromise security guarantees such as confidentiality, integrity, and authenticity.

Many cryptographic algorithms are known to be weak or flawed. The security guarantees of a system often rely on the underlying cryptography, so using a weak algorithm can have severe consequences. For example:

• If a weak encryption algorithm is used, an attacker may be able to decrypt sensitive data.
• If a weak hashing algorithm is used to protect data integrity, an attacker may be able to craft a malicious input that has the same hash as a benign one.
• If a weak algorithm is used for digital signatures, an attacker may be able to forge signatures and impersonate legitimate users.

Recommendation

Ensure that you use a strong, modern cryptographic algorithm. Use at least AES-128 or RSA-2048.

Example

The following code shows an example of using the advapi windows API to decrypt some data. When creating a key, you must specify which algorithm to use. The first example uses DES which is an older algorithm that is now considered weak. The second example uses AES, which is a strong modern algorithm.

voidadvapi() {
HCRYPTPROVhCryptProv;
HCRYPTKEYhKey;
HCRYPTHASHhHash;
// other preparation goes here// BAD: use 3DES for keyCryptDeriveKey(hCryptProv, CALG_3DES, hHash, 0, &hKey);
// GOOD: use AESCryptDeriveKey(hCryptProv, CALG_AES_256, hHash, 0, &hKey);
}

References

• NIST, FIPS 140 Annex a: Approved Security Functions.
• NIST, SP 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.
• Common Weakness Enumeration: CWE-327.

java/ql/src/Security/CWE/CWE-327/BrokenCryptoAlgorithm.qhelp

Use of a broken or risky cryptographic algorithm

Using broken or weak cryptographic algorithms may compromise security guarantees such as confidentiality, integrity, and authenticity.

Many cryptographic algorithms are known to be weak or flawed. The security guarantees of a system often rely on the underlying cryptography, so using a weak algorithm can have severe consequences. For example:

• If a weak encryption algorithm is used, an attacker may be able to decrypt sensitive data.
• If a weak hashing algorithm is used to protect data integrity, an attacker may be able to craft a malicious input that has the same hash as a benign one.
• If a weak algorithm is used for digital signatures, an attacker may be able to forge signatures and impersonate legitimate users.

Recommendation

Ensure that you use a strong, modern cryptographic algorithm. Use at least AES-128 or RSA-2048. Do not use the ECB encryption mode since it is vulnerable to replay and other attacks.

Example

The following code shows an example of using a java Cipher to encrypt some data. When creating a Cipher instance, you must specify the encryption algorithm to use. The first example uses DES, which is an older algorithm that is now considered weak. The second example uses AES, which is a strong modern algorithm.

// BAD: DES is a weak algorithm Cipherdes = Cipher.getInstance("DES");
cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec);
byte[] encrypted = cipher.doFinal(input.getBytes("UTF-8"));
// ...// GOOD: AES is a strong algorithmCipheraes = Cipher.getInstance("AES");
// ...

References

• NIST, FIPS 140 Annex a: Approved Security Functions.
• NIST, SP 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.
• Common Weakness Enumeration: CWE-327.
• Common Weakness Enumeration: CWE-328.

javascript/ql/src/Security/CWE-327/BrokenCryptoAlgorithm.qhelp

Use of a broken or weak cryptographic algorithm

Using broken or weak cryptographic algorithms may compromise security guarantees such as confidentiality, integrity, and authenticity.

Many cryptographic algorithms are known to be weak or flawed. The security guarantees of a system often rely on the underlying cryptography, so using a weak algorithm can have severe consequences. For example:

• If a weak encryption algorithm is used, an attacker may be able to decrypt sensitive data.
• If a weak hashing algorithm is used to protect data integrity, an attacker may be able to craft a malicious input that has the same hash as a benign one.
• If a weak algorithm is used for digital signatures, an attacker may be able to forge signatures and impersonate legitimate users.

Recommendation

Ensure that you use a strong, modern cryptographic algorithm. Use at least AES-128 or RSA-2048 for encryption, and SHA-2 or SHA-3 for secure hashing.

Example

The following code shows an example of using the builtin cryptographic library of NodeJS to encrypt some secret data. When creating a Cipher instance to encrypt the secret data with, you must specify the encryption algorithm to use. The first example uses DES, which is an older algorithm that is now considered weak. The second example uses AES, which is a strong modern algorithm.

constcrypto=require('crypto');varsecretText=obj.getSecretText();constdesCipher=crypto.createCipher('des',key);letdesEncrypted=desCipher.write(secretText,'utf8','hex');// BAD: weak encryptionconstaesCipher=crypto.createCipher('aes-128',key);letaesEncrypted=aesCipher.update(secretText,'utf8','hex');// GOOD: strong encryption

References

• NIST, FIPS 140 Annex a: Approved Security Functions.
• NIST, SP 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.
• OWASP: Rule - Use strong approved cryptographic algorithms.
• Common Weakness Enumeration: CWE-327.
• Common Weakness Enumeration: CWE-328.

python/ql/src/Security/CWE-327/BrokenCryptoAlgorithm.qhelp

Use of a broken or weak cryptographic algorithm

Using broken or weak cryptographic algorithms may compromise security guarantees such as confidentiality, integrity, and authenticity.

Many cryptographic algorithms are known to be weak or flawed. The security guarantees of a system often rely on the underlying cryptography, so using a weak algorithm can have severe consequences. For example:

• If a weak encryption algorithm is used, an attacker may be able to decrypt sensitive data.
• If a weak algorithm is used for digital signatures, an attacker may be able to forge signatures and impersonate legitimate users.
  This query alerts on any use of a weak cryptographic algorithm that is not a hashing algorithm. Use of broken or weak cryptographic hash functions are handled by the py/weak-sensitive-data-hashing query.

Recommendation

Ensure that you use a strong, modern cryptographic algorithm, such as AES-128 or RSA-2048.

Example

The following code uses the pycryptodome library to encrypt some secret data. When you create a cipher using pycryptodome you must specify the encryption algorithm to use. The first example uses DES, which is an older algorithm that is now considered weak. The second example uses AES, which is a stronger modern algorithm.

fromCrypto.CipherimportDES, AEScipher=DES.new(SECRET_KEY)
defsend_encrypted(channel, message):
channel.send(cipher.encrypt(message)) # BAD: weak encryptioncipher=AES.new(SECRET_KEY)
defsend_encrypted(channel, message):
channel.send(cipher.encrypt(message)) # GOOD: strong encryption

NOTICE: the original [pycrypto](https://pypi.org/project/pycrypto/) PyPI package that provided the Crypto module is not longer actively maintained, so you should use the [pycryptodome](https://pypi.org/project/pycryptodome/) PyPI package instead (which has a compatible API).

References

• NIST, FIPS 140 Annex a: Approved Security Functions.
• NIST, SP 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.
• OWASP: Rule - Use strong approved cryptographic algorithms.
• Common Weakness Enumeration: CWE-327.

ruby/ql/src/queries/security/cwe-327/BrokenCryptoAlgorithm.qhelp

Use of a broken or weak cryptographic algorithm

Using broken or weak cryptographic algorithms may compromise security guarantees such as confidentiality, integrity, and authenticity.

Many cryptographic algorithms are known to be weak or flawed. The security guarantees of a system often rely on the underlying cryptography, so using a weak algorithm can have severe consequences. For example:

• If a weak encryption algorithm is used, an attacker may be able to decrypt sensitive data.
• If a weak algorithm is used for digital signatures, an attacker may be able to forge signatures and impersonate legitimate users.
  This query alerts on any use of a weak cryptographic algorithm that is not a hashing algorithm. Use of broken or weak cryptographic hash functions are handled by the rb/weak-sensitive-data-hashing query.

Recommendation

Ensure that you use a strong, modern cryptographic algorithm, such as AES-128 or RSA-2048.

Example

The following code uses the OpenSSL library to encrypt some secret data. When you create a cipher using OpenSSL you must specify the encryption algorithm to use. The first example uses DES, which is an older algorithm that is now considered weak. The second example uses AES, which is a stronger modern algorithm.

require'openssl'classEncryptorattr_accessor:secret_keydefencrypt_message_weak(message)cipher=OpenSSL::Cipher.new('des')# BAD: weak encryptioncipher.encryptcipher.key=secret_keycipher.update(message)cipher.finalenddefencrypt_message_strong(message)cipher=OpenSSL::Cipher::AES128.new# GOOD: strong encryptioncipher.encryptcipher.key=secret_keycipher.update(message)cipher.finalendend

References

• NIST, FIPS 140 Annex a: Approved Security Functions.
• NIST, SP 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.
• OWASP: Rule - Use strong approved cryptographic algorithms.
• Common Weakness Enumeration: CWE-327.

rust/ql/src/queries/security/CWE-327/BrokenCryptoAlgorithm.qhelp

Use of a broken or weak cryptographic algorithm

Using broken or weak cryptographic algorithms may compromise security guarantees such as confidentiality, integrity, and authenticity.

Many cryptographic algorithms are known to be weak or flawed. The security guarantees of a system often rely on the underlying cryptography, so using a weak algorithm can have severe consequences. For example:

• If a weak encryption algorithm is used, an attacker may be able to decrypt sensitive data.
• If a weak algorithm is used for digital signatures, an attacker may be able to forge signatures and impersonate legitimate users.
  This query alerts on any use of a weak cryptographic algorithm that is not a hashing algorithm. Use of broken or weak cryptographic hash functions are handled by the rust/weak-sensitive-data-hashing query.

Recommendation

Ensure that you use a strong, modern cryptographic algorithm, such as AES-128 or RSA-2048.

Example

The following code uses the des crate from the RustCrypto family to encrypt some secret data. The DES algorithm is old and considered very weak.

let des_cipher = cbc::Encryptor::<des::Des>::new(key.into(), iv.into());// BAD: weak encryptionlet encryption_result = des_cipher.encrypt_padded_mut::<des::cipher::block_padding::Pkcs7>(data, data_len);

Instead, we should use a strong modern algorithm. In this case, we have selected the 256-bit version of the AES algorithm.

let aes_cipher = cbc::Encryptor::<aes::Aes256>::new(key.into(), iv.into());// GOOD: strong encryptionlet encryption_result = aes_cipher.encrypt_padded_mut::<aes::cipher::block_padding::Pkcs7>(data, data_len);

References

• NIST, FIPS 140 Annex A: Approved Security Functions.
• NIST, SP 800-131A Revision 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths.
• OWASP: Cryptographic Storage Cheat Sheet - Algorithms.
• Common Weakness Enumeration: CWE-327.

[aibaars]

That's a nice improvement! Would it be useful/possible to extract the common text in a shared snippet that is imported in the various qhelp files?

[geoffw0]

C/C++ 👍

Rust 👍 - personally I would delete the bullet point about weak hashing from this file, but I'm also OK with this being merged as is (after a docs review that is) --- update: it's deleted now :)

[owen-mc]

@aibaars My only issue with that is where it should go. A new shared library with things related to (security) queries? I guess we will want one at some point, if we implement concepts further. Or in the shared concepts library, by the crypto information? I was about to say that most of the languages already depend on that, but I see that it's the library qlpacks that depend on it, and we would be adding this dependency to the source qlpacks.

[owen-mc]

@aibaars I appreciate you may be busy. If so, perhaps I will merge this for now and we can consolidate it in future?

[joefarebrother]

Python 👍

[mchammer01]

Approving this on behalf of Docs ✨