Horusec-Java

What is it?

Horusec-Java is a SAST tool created by the Horusec team to search for vulnerabilities on Java projects.

Examples of vulnerabilities

File Is World Readable

The file is World Readable. Any App can read from the file. For more information checkout the CWE-276 (https://cwe.mitre.org/data/definitions/276.html) advisory.

Example of a vulnerable code:

fos = openFileOutput(filename, MODE_WORLD_READABLE);
fos.write(userInfo.getBytes());

Example of an invulnerable code:

fos = openFileOutput(filename, MODE_PRIVATE);

File Is World Writable

The file is World Writable. Any App can write to the file. For more information checkout the CWE-276 (https://cwe.mitre.org/data/definitions/276.html) advisory.

Example of a vulnerable code:

fos = openFileOutput(filename, MODE_WORLD_WRITABLE);
fos.write(userInfo.getBytes());

Example of an invulnerable code:

fos = openFileOutput(filename, MODE_PRIVATE);

No Write External Content

App can read/write to External Storage. Any App can read data written to External Storage. For more information checkout the CWE-276 (https://cwe.mitre.org/data/definitions/276.html) advisory.
This rule raises an issue when the following functions are called:

• android.os.Environment.getExternalStorageDirectory
• android.os.Environment.getExternalStoragePublicDirectory
• android.content.Context.getExternalFilesDir
• android.content.Context.getExternalFilesDirs
• android.content.Context.getExternalMediaDirs
• android.content.Context.getExternalCacheDir
• android.content.Context.getExternalCacheDirs
• android.content.Context.getObbDir
• android.content.Context.getObbDirs

Example of a sensible code:

import android.content.Context;
import android.os.Environment;

public class AccessExternalFiles {

    public void accessFiles(Context context) {
        Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES); // Sensitive
        context.getExternalFilesDir(Environment.DIRECTORY_PICTURES); // Sensitive
    }
}

No use IVs weak

The App may use weak IVs like 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 or 0x01,0x02,0x03,0x04,0x05,0x06,0x07. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack. For more information checkout the CWE-329 (https://cwe.mitre.org/data/definitions/329.html) advisory.

This App may have root detection capabilities

• .contains("test-keys")
• /system/app/Superuser.apk
• isDeviceRooted()
• /system/bin/failsafe/su
• /system/sd/xbin/su
• "/system/xbin/which", "su"
• RootTools.isAccessGiven()

Set or Read Clipboard data

• content.ClipboardManager
• CLIPBOARD_SERVICE
• ClipboardManager

Message Digest

The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2, MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.

Example of a vulnerable code:

MyProprietaryMessageDigest extends MessageDigest {
    @Override
    protected byte[] engineDigest() {
        [...]
        //Creativity is a bad idea
        return [...];
    }
}

Example of an invulnerable code:

MessageDigest sha256Digest = MessageDigest.getInstance("SHA256");
sha256Digest.update(password.getBytes());

Overly permissive file permission

It is generally a bad practices to set overly permissive file permission such as read+write+exec for all users. If the file affected is a configuration, a binary, a script or sensitive data, it can lead to privilege escalation or information leakage. For more information checkout the CWE-732 (https://cwe.mitre.org/data/definitions/732.html) advisory.

Example of a vulnerable code:

Set<PosixFilePermission> perms = new HashSet<>();
perms.add(PosixFilePermission.OWNER_READ);
perms.add(PosixFilePermission.OWNER_WRITE);
perms.add(PosixFilePermission.OWNER_EXECUTE);

perms.add(PosixFilePermission.GROUP_READ);
perms.add(PosixFilePermission.GROUP_WRITE);
perms.add(PosixFilePermission.GROUP_EXECUTE);

perms.add(PosixFilePermission.OTHERS_READ);
perms.add(PosixFilePermission.OTHERS_WRITE);
perms.add(PosixFilePermission.OTHERS_EXECUTE);

Example of an invulnerable code:

Set<PosixFilePermission> perms = new HashSet<>();
perms.add(PosixFilePermission.OWNER_READ);
perms.add(PosixFilePermission.OWNER_WRITE);
perms.add(PosixFilePermission.OWNER_EXECUTE);

perms.add(PosixFilePermission.GROUP_READ);
perms.add(PosixFilePermission.GROUP_WRITE);
perms.add(PosixFilePermission.GROUP_EXECUTE);

DES, DESede, RSA is insecure

DES is considered strong ciphers for modern applications. Currently, NIST recommends the usage of AES block ciphers instead of DES. For more information checkout the CWE-326 (https://cwe.mitre.org/data/definitions/326.html) advisory.

Example of a vulnerable code:

Cipher c = Cipher.getInstance("DES/ECB/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

// =========== //

Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

// =========== //

Cipher.getInstance("RSA/NONE/NoPadding")

Example of an invulnerable code:

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

// =========== //

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

// =========== //

Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")

Hidden elements

Hidden elements in view can be used to hide data from user. But this data can be leaked. For more information checkout the CWE-919 (https://cwe.mitre.org/data/definitions/919.html) advisory.

Weak block mode for Cryptographic Hash Function

A weak ECB, (a.k.a ‘block mode’) was found in one of your Ciphers. Always use a strong, high entropy hash, for example the SHA-512 with salt options. For more information check:

• CWE-327
• __CWE-719__
• CWE-326
• _CWE-780 _ for deeper details on how to fix it.

Weak Cryptographic Hash Function used

Using a weak CHF pose a threat to your application security since it can be vulnerable to a number of attacks that could lead to data leaking, improper access of features and resources of your infrastructure and even rogue sessions. For more information checkout the CWE-327 (https://cwe.mitre.org/data/definitions/327.html) advisory.

Possible File With Vulnerability When Open

The file is World Readable and Writable. Any App can read/write to the file. For more information checkout the CWE-276 (https://cwe.mitre.org/data/definitions/276.html) advisory.

Sensitive Information Not Encrypted

App can write to App Directory. Sensitive Information should be encrypted. For more information checkout the CWE-276 (https://cwe.mitre.org/data/definitions/276.html) advisory.

Insecure Random Number Generator

The App uses an insecure Random Number Generator. For more information checkout the CWE-330 (https://cwe.mitre.org/data/definitions/330.html) advisory.

No Default Java Hash

This App uses Java Hash Code. It’s a weak hash function and should never be used in Secure Crypto Implementation. For more information checkout the CWE-327 (https://cwe.mitre.org/data/definitions/327.html) advisory.

Layout Params Flag Secure

These activities prevent screenshot when they go to background.

No use SQL Cipher

This App uses SQL Cipher. But the secret may be hardcoded. For more information checkout the CWE-312 (https://cwe.mitre.org/data/definitions/312.html) advisory.

__

Prevent Tap Jacking Attack

This app has capabilities to prevent tapjacking attacks. For more information checkout the CWE-1021 (https://cwe.mitre.org/data/definitions/1021.html) advisory.

Prevent Write sensitive information in tmp file

App creates temp file. Sensitive information should never be written into a temp file. For more information checkout the CWE-276 (https://cwe.mitre.org/data/definitions/276.html) advisory.

Get Window Flag Secure

App capabilities to prevent screenshots from Recent Task History/Now On Tap etc.

Example of a vulnerable code:

public void disableScreenCapture() {
    getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE);

}

Loading Native Code

Loading Native Code (Shared Library)

Example of a vulnerable code:

System.loadLibrary("library")

Dynamic Class and Dexloading

Dynamic Class and Dexloading

Example of a vulnerable code:

import dalvik.system.DexClassLoader
or
import java.security.ClassLoader
or
import java.net.URLClassLoader
or
import java.security.SecureClassLoader

Java Crypto import

Problems on Java Crypto import.

Exemplo de código vulnerável:

import javax.crypto
or
import kalium.crypto
or
import bouncycastle.crypto

Starting Service

Vulnerabilities related to apps using StartingService or BindService

Example of a vulnerable code:

startService(...)
or
bindService(...)

Sending Broadcast

Vulnerabilities related to Sending Broadcast.

Example of a vulnerable code:

sendBroadcast(...)
or
sendOrderedBroadcast(...)
or
sendStickyBroadcast(...)

Local File I/O Operations

Possible vulnerabilities when use:

• OpenFileOutput
• getSharedPreferences
• SharedPreferences.Editor
• getCacheDir
• getExternalStorageState
• openOrCreateDatabase

Inter Process Communication

Inter Process Communication

Possible vulnerabilities when using:

• IRemoteService
• IRemoteService.Stub
• IBinder

__

DefaultHttpClient with default constructor is not compatible with TLS 1.2

Upgrade your implementation to use one of the recommended constructs and configure https.protocols JVM option to include TLSv1.2. Use SystemDefaultHttpClient instead. For more information checkout (https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https).

Weak SSLContext

Upgrade your implementation to the following, and configure https.protocols JVM option to include TLSv1.2:. Use SSLContext.getInstance(“TLS”). For more information checkout (https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https)

HostnameVerifier that accept any signed certificates

A HostnameVerifier that accept any host are often use because of certificate reuse on many hosts. As a consequence, this is vulnerable to Man-in-the-middle attacks since the client will trust any certificate. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

URL rewriting method

URL rewriting has significant security risks. Since session ID appears in the URL, it may be easily seen by third parties. Session ID in the URL can be disclosed in many ways. For more information checkout the (https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication) advisory.

Disabling HTML escaping

Disabling HTML escaping put the application at risk for Cross-Site Scripting (XSS). For more information checkout the CWE-79 (https://cwe.mitre.org/data/definitions/79.html) advisory.

Overly permissive CORS policy

A web server defines which other domains are allowed to access its domain using cross-origin requests. However, caution should be taken when defining the header because an overly permissive CORS policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks. For more information checkout the (https://fetch.spec.whatwg.org/) advisory.

SQL Injection

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Alternatively to prepare statements, each parameter can be escaped manually. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

SQL Injection With Turbine

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Turbine API provide a DSL to build query with Java code. Alternatively to prepare statements, each parameter can be escaped manually. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

SQL Injection With Hibernate

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Alternatively to prepare statements, Hibernate Criteria can be used. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory and checkout the CWE-564 (https://cwe.mitre.org/data/definitions/564.html) advisory.

SQL Injection With JDO

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

SQL Injection With JPA

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

SQL Injection Spring JDBC

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

SQL Injection JDBC

The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

Potential LDAP Injection

Just like SQL, all inputs passed to an LDAP query need to be passed in safely. Unfortunately, LDAP doesn’t have prepared statement interfaces like SQL. Therefore, the primary defense against LDAP injection is strong input validation of any untrusted data before including it in an LDAP query. For more information checkout the CWE-90 (https://cwe.mitre.org/data/definitions/90.html) advisory.

Potential external control of configuration

Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious ways. An attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database. For more information checkout the CWE-15 (https://cwe.mitre.org/data/definitions/15.html) advisory.

Bad hexadecimal concatenation

When converting a byte array containing a hash signature to a human readable string, a conversion mistake can be made if the array is read byte by byte. The following sample illustrates the use of the method Integer.toHexString() which will trim any leading zeroes from each byte of the computed hash value. For more information checkout the CWE-704 (https://cwe.mitre.org/data/definitions/704.html) advisory.

__

NullCipher is insecure

The NullCipher is rarely used intentionally in production applications. It implements the Cipher interface by returning ciphertext identical to the supplied plaintext. In a few contexts, such as testing, a NullCipher may be appropriate. For more information checkout the CWE-704 (https://cwe.mitre.org/data/definitions/704.html) advisory.

Unsafe hash equals

An attacker might be able to detect the value of the secret hash due to the exposure of comparison timing. When the functions Arrays.equals() or String.equals() are called, they will exit earlier if fewer bytes are matched. For more information checkout the CWE-704 (https://cwe.mitre.org/data/definitions/704.html) advisory.

__

Unvalidated Redirect

Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks. For more information checkout the CWE-601 (https://cwe.mitre.org/data/definitions/601.html) advisory.

__

@RequestMapping methods should be public

A method with a @RequestMapping annotation part of a class annotated with @Controller (directly or indirectly through a meta annotation - @RestController from Spring Boot is a good example) will be called to handle matching web requests. That will happen even if the method is private, because Spring invokes such methods via reflection, without checking visibility. For more information checkout the OWASAP:A6 (https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration) advisory.

__

LDAP deserialization should be disabled

JNDI supports the deserialization of objects from LDAP directories, which is fundamentally insecure and can lead to remote code execution. This rule raises an issue when an LDAP search query is executed with SearchControls configured to allow deserialization. For more information checkout the CWE-502 (https://cwe.mitre.org/data/definitions/502.html) advisory.

__

Databases should be password-protected

Databases should always be password protected. The use of a database connection with an empty password is a clear indication of a database that is not protected. For more information checkout the CWE-521 (https://cwe.mitre.org/data/definitions/521.html) advisory.

XML parsing vulnerable to XXE

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

XML parsing vulnerable to XXE With XMLInputFactory

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

XML parsing vulnerable to XXE With DocumentBuilder

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

XML parsing vulnerable to XXE With SAXParserFactory

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

XML parsing vulnerable to XXE With TransformerFactory using SchemaFactory

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

__

XML parsing vulnerable to XXE With TransformerFactory

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

__

XML parsing vulnerable to XXE With Dom4j

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

__

XML parsing vulnerable to XXE With Jdom2

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. For more information checkout the CWE-611 (https://cwe.mitre.org/data/definitions/611.html) advisory.

Insecure Implementation of SSL

Insecure Implementation of SSL. Trusting all the certificates or accepting self signed certificates is a critical Security Hole. This application is vulnerable to MITM attacks. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

Message digest is custom

Implementing a custom MessageDigest is error-prone. NIST recommends the use of SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256. For more information checkout the CWE-327 (https://cwe.mitre.org/data/definitions/327.html) advisory.

__

TrustManager that accept any certificates Client

Empty TrustManager implementations are often used to connect easily to a host that is not signed by a root certificate authority. As a consequence, this is vulnerable to Man-in-the-middle attacks since the client will trust any certificate. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

Server hostnames should be verified during SSL/TLS connections

To establish a SSL/TLS connection not vulnerable to man-in-the-middle attacks, it’s essential to make sure the server presents the right certificate. The certificate’s hostname-specific data should match the server hostname. It’s not recommended to re-invent the wheel by implementing custom hostname verification. TLS/SSL libraries provide built-in hostname verification functions that should be used. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

Server hostnames should be verified during SSL/TLS connections With SimpleEmail

To establish a SSL/TLS connection not vulnerable to man-in-the-middle attacks, it’s essential to make sure the server presents the right certificate. The certificate’s hostname-specific data should match the server hostname. It’s not recommended to re-invent the wheel by implementing custom hostname verification. TLS/SSL libraries provide built-in hostname verification functions that should be used. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

Server hostnames should be verified during SSL/TLS connections With JavaMail’s

To establish a SSL/TLS connection not vulnerable to man-in-the-middle attacks, it’s essential to make sure the server presents the right certificate. The certificate’s hostname-specific data should match the server hostname. It’s not recommended to re-invent the wheel by implementing custom hostname verification. TLS/SSL libraries provide built-in hostname verification functions that should be used. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

TrustManager that accept any certificates Server

Empty TrustManager implementations are often used to connect easily to a host that is not signed by a root certificate authority. As a consequence, this is vulnerable to Man-in-the-middle attacks since the client will trust any certificate. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

TrustManager that accept any certificates Issuers

Empty TrustManager implementations are often used to connect easily to a host that is not signed by a root certificate authority. As a consequence, this is vulnerable to Man-in-the-middle attacks since the client will trust any certificate. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

WebView Load Files From External Storage

WebView load files from external storage. Files in external storage can be modified by any application. For more information checkout the CWE-919 (https://cwe.mitre.org/data/definitions/919.html) advisory.

__

Insecure Web View Implementation

Insecure WebView Implementation. Execution of user controlled code in WebView is a critical Security Hole. For more information checkout the CWE-749 (https://cwe.mitre.org/data/definitions/749.html) advisory.

__

No Use SQL Cipher

This App uses SQL Cipher. SQLCipher provides 256-bit AES encryption to sqlite database files

Possible vulnerabilities when using:

• SQLiteDatabase.loadLibs(...)
• net.sqlcipher

__

No Use Realm Database With Encryption Key

This App use Realm Database with encryption Possible vulnerabilities when using:

• io.realm.Realm
• content.encryptionKey(...)

__

No Use Webview Debugging Enable

Remote WebView debugging is enabled. For more information checkout the CWE-215 (https://cwe.mitre.org/data/definitions/215.html) advisory.

__

No Listen To Clipboard

This app listens to Clipboard changes. Some malwares also listen to Clipboard changes. Possible vulnerabilities when using:

• content.ClipboardManager
• OnPrimaryClipChangedListener

__

No copy content to clipboard

This App copies data to clipboard. Sensitive data should not be copied to clipboard as other applications can access it. Possible vulnerabilities when using:

• content.ClipboardManager
• setPrimaryClip

No Use Webview Ignoring SSL

Insecure WebView Implementation. WebView ignores SSL Certificate errors and accept any SSL Certificate. This application is vulnerable to MITM attacks. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

__

SQL Injection With SqlUtil

The method identified is susceptible to injection. The input should be validated and properly escaped. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.

__

No Use Frida Server

This App detects frida server.

Possible vulnerabilities when using:

• fridaserver
• 27047 or LIBFRIDA

No Use SSL Pinning Lib

This App uses an SSL Pinning Library (org.thoughtcrime.ssl.pinning) to prevent MITM attacks in secure communication channel.

Possible vulnerabilities when using:

• fridaserver
• 27047 or LIBFRIDA

__

DexGuard Debug Detection

DexGuard Debug Detection code to detect wheather an App is debuggable or not is identified.

Possible vulnerabilities when using:

• import dexguard.util
• DebugDetector.isDebuggable

__

No Use DexGuard Debugger Connected

DexGuard Debugger Detection code is identified.

Possible vulnerabilities when using:

• import dexguard.util
• DebugDetector.isDebuggerConnected

__

No Use DexGuard Emulator Detection

DexGuard Emulator Detection code is identified.

Possible vulnerabilities when using:

• import dexguard.util
• EmulatorDetector.isRunningInEmulator

__

No Use DexGuard With Debug Key

DexGuard code to detect wheather the App is signed with a debug key or not is identified.

Possible vulnerabilities when using:

• import dexguard.util
• DebugDetector.isSignedWithDebugKey

__

No Use DexGuard Root

DexGuard Root Detection code is identified.

Possible vulnerabilities when using:

• import dexguard.util
• RootDetector.isDeviceRooted

__

No Use DexGuard

DexGuard App Tamper Detection code is identified.

Possible vulnerabilities when using:

• import dexguard.util
• TamperDetector.checkApk

__

No Use DexGuard in signer

DexGuard Signer Certificate Tamper Detection code is identified.

Possible vulnerabilities when using:

• import dexguard.util
• TamperDetector.checkApk

__

No use package with tamper detection

The App may use package signature for tamper detection.

Possible vulnerabilities when using:

• PackageManager.GET_SIGNATURES
• getPackageName(...)

__

Load and Manipulate Dex Files

Load and Manipulate Dex Files

Possible vulnerabilities when using:

• dalvik.system.PathClassLoader or dalvik.system.DexFile or dalvik.system.DexPathList
• loadDex or loadClass or DexClassLoader or loadDexFile

__

Obfuscation

Obfuscation

Possible vulnerabilities when using:

• utils.AESObfuscator
• getObfuscator

__

Execute OS Command

Execute OS Command. For more information checkout the CWE-78 (https://cwe.mitre.org/data/definitions/78.html) advisory.

__

TCP Server Socket

TCP Server Socket

Possible vulnerabilities when using:

• new ServerSocket(...)
• net.ServerSocket

__

TCP Socket

TCP Socket

Possible vulnerabilities when using:

• new Socket(...)
• net.Socket

__

UDP Datagram Packet

UDP Datagram Packet

Possible vulnerabilities when using:

• DatagramPacket
• net.DatagramPacket

__

UDP Datagram Socket

UDP Datagram Socket

Possible vulnerabilities when using:

• net.DatagramPacket
• DatagramSocket

__

WebView JavaScript Interface

WebView JavaScript Interface

Possible vulnerabilities when using:

• addJavascriptInterface
• WebView

__

Get Cell Information

Get Cell Information

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getAllCellInfo

__

Get Cell Location

Get Cell Location

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getCellLocation

__

Get Subscriber ID

Get Subscriber ID

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getSubscriberId

__

Get Device ID

Get Device ID

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getDeviceId

__

Get Software Version, IMEI/SV etc

Get Software Version, IMEI/SV etc

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getDeviceSoftwareVersion

__

Get SIM Serial Number

Get SIM Serial Number

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getSimSerialNumber

__

Get SIM Provider Details

Get SIM Provider Details

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getSimOperator

__

Get SIM Operator Name

Get SIM Operator Name

Possible vulnerabilities when using:

• telephony.TelephonyManager
• getSimOperatorName

__

Query Database of SMS, Contacts etc.

Query Database of SMS, Contacts etc.

Possible vulnerabilities when using:

• content.ContentResolver
• query

__

Potential Path Traversal (file read)

A file is opened to read its content. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read. This rule identifies potential path traversal vulnerabilities. Please consider use this example: new File("resources/images/", FilenameUtils.getName(value_received_in_params)). For more information checkout the CWE-22 (https://cwe.mitre.org/data/definitions/22.html) advisory.

__

Potential Path Traversal Using scala API (file read)

A file is opened to read its content. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read. Please consider use this example:

val result = Source.fromFile("public/lists/" + FilenameUtils.getName(value_received_in_params)).getLines().mkString

For more information checkout the CWE-22 (https://cwe.mitre.org/data/definitions/22.html) advisory.

__

SMTP Header Injection

If user input is place in a header line, the application should remove or replace new line characters (CR / LF). For more information checkout the CWE-93 (https://cwe.mitre.org/data/definitions/93.html) advisory.

__

Insecure SMTP SSL connection

Some email libraries that enable SSL connections do not verify the server certificate by default. This is equivalent to trusting all certificates. For more information checkout the CWE-297 (https://cwe.mitre.org/data/definitions/297.html) advisory.

__

Persistent Cookie Usage

Storing sensitive data in a persistent cookie for an extended period can lead to a breach of confidentiality or account compromise. For more information checkout the CWE-539 (https://cwe.mitre.org/data/definitions/539.html) advisory.

__

Anonymous LDAP bind

All LDAP queries executed against the context will be performed without authentication and access control. For more information checkout the (https://docs.oracle.com/javase/tutorial/jndi/ldap/auth_mechs.html) advisory.

__

LDAP Entry Poisoning

If certain attributes are presented, the deserialization of object will be made in the application querying the directory. Object deserialization should be consider a risky operation that can lead to remote code execution. For more information checkout the (https://blog.trendmicro.com/trendlabs-security-intelligence/new-headaches-how-the-pawn-storm-zero-day-evaded-javas-click-to-play-protection) advisory.

__

Ignoring XML comments in SAML

Security Assertion Markup Language (SAML) is a single sign-on protocol that that used XML. The SAMLResponse message include statements that describe the authenticated user. If a user manage to place XML comments (), it may caused issue in the way the parser extract literal value. For more information checkout the (https://spring.io/blog/2018/03/01/spring-security-saml-and-this-week-s-saml-vulnerability) advisory.

__

Information Exposure Through An Error Message

The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more deadly attacks. For more information checkout the CWE-209 (https://cwe.mitre.org/data/definitions/209.html) advisory.

__

HTTP Parameter Pollution

Concatenating unvalidated user input into a URL can allow an attacker to override the value of a request parameter. For more information checkout the CAPEC-460 (https://capec.mitre.org/data/definitions/460.html) advisory.

__

AWS Query Injection

Constructing SimpleDB queries containing user input can allow an attacker to view unauthorized records. For more information checkout the CWE-943 (https://cwe.mitre.org/data/definitions/943.html) advisory.

__

Potential template injection with Pebble

A malicious user in control of a template can run malicious code on the server-side. Freemarker templates should be seen as scripts. For more information checkout the (https://portswigger.net/research/server-side-template-injection) advisory.

__

Potential template injection with Freemarker

A malicious user in control of a template can run malicious code on the server-side. Freemarker templates should be seen as scripts. For more information checkout the (https://portswigger.net/research/server-side-template-injection) advisory.

Request Dispatcher File Disclosure

Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories. For more information checkout the CWE-552 (https://cwe.mitre.org/data/definitions/552.html) advisory.

__

Spring File Disclosure

Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories. For more information checkout the CWE-552 (https://cwe.mitre.org/data/definitions/552.html) advisory.

__

Potential code injection when using Script Engine

Dynamic code is being evaluate. A careful analysis of the code construction should be made. Malicious code execution could lead to data leakage or operating system compromised. For more information checkout the CWE-94 (https://cwe.mitre.org/data/definitions/94.html) advisory and checkout the CWE-95 (https://cwe.mitre.org/data/definitions/95.html) advisory._

Struts File Disclosure

Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories. For more information checkout the CWE-552 (https://cwe.mitre.org/data/definitions/552.html) advisory.

Unsafe Jackson deserialization configuration

When the Jackson databind library is used incorrectly the deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation.

Object deserialization is used

Object deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation. For more information checkout the CWE-502 (https://cwe.mitre.org/data/definitions/502.html) advisory.

Potential code injection when using Spring Expression

A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. For more information checkout the CWE-94 (https://cwe.mitre.org/data/definitions/94.html) advisory and checkout the CWE-95 (https://cwe.mitre.org/data/definitions/95.html) advisory.

Cookie without the HttpOnly flag

A new cookie is created without the HttpOnly flag set. For more information checkout the (https://owasp.org/www-community/HttpOnly) advisory.

WebView with geolocation activated

It is suggested to ask the user for a confirmation about obtaining its geolocation.

__

Use of ESAPI Encryptor

The ESAPI has a small history of vulnerabilities within the cryptography component. Here is a quick validation list to make sure the Authenticated Encryption is working as expected. For more information checkout the CWE-310 (https://cwe.mitre.org/data/definitions/310.html) advisory.

Static IV

Initialization vector must be regenerated for each message to be encrypted. For more information checkout the CWE-329 (https://cwe.mitre.org/data/definitions/329.html) advisory.

XML Decoder usage

XMLDecoder should not be used to parse untrusted data. Deserializing user input can lead to arbitrary code execution. For more information checkout the CWE-20 (https://cwe.mitre.org/data/definitions/20.html) advisory.

__

Potential XSS in Servlet

A potential XSS was found. It could be used to execute unwanted JavaScript in a client’s browser. For more information checkout the CWE-79 (https://cwe.mitre.org/data/definitions/79.html) advisory.

__

Escaping of special XML characters is disabled

A potential XSS was found. It could be used to execute unwanted JavaScript in a client’s browser. For more information checkout the CWE-79 (https://cwe.mitre.org/data/definitions/79.html) advisory.

__

Dynamic variable in Spring expression

A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation. For more information checkout the CWE-95 (https://cwe.mitre.org/data/definitions/95.html) advisory.

RSA usage with short key

The NIST recommends the use of 2048 bits and higher keys for the RSA algorithm. For more information checkout the CWE-326 (https://cwe.mitre.org/data/definitions/326.html) advisory.

Blowfish usage with short key

The Blowfish cipher supports key sizes from 32 bits to 448 bits. A small key size makes the ciphertext vulnerable to brute force attacks. At least 128 bits of entropy should be used when generating the key if use of Blowfish is required. For more information checkout the CWE-326 (https://cwe.mitre.org/data/definitions/326.html) advisory.

Classes should not be loaded dynamically

Dynamically loaded classes could contain malicious code executed by a static class initializer. I.E. you wouldn’t even have to instantiate or explicitly invoke methods on such classes to be vulnerable to an attack. For more information checkout the CWE-326 (https://cwe.mitre.org/data/definitions/326.html) advisory.

__

HostnameVerifier.verify should not always return true

To prevent URL spoofing, HostnameVerifier.verify() methods should do more than simply return true. Doing so may get you quickly past an exception, but that comes at the cost of opening a security hole in your application. For more information checkout the CWE-295 (https://cwe.mitre.org/data/definitions/295.html) advisory.

XPath expressions should not be vulnerable to injection attacks

User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing XPath expressions directly from tainted data enables attackers to inject specially crafted values that changes the initial meaning of the expression itself. Successful XPath injection attacks can read sensitive information from XML documents. For more information checkout the CWE-643 (https://cwe.mitre.org/data/definitions/643.html) advisory.

Exceptions should not be thrown from servlet methods

Even though the signatures for methods in a servlet include throws IOException, ServletException, it’s a bad idea to let such exceptions be thrown. Failure to catch exceptions in a servlet could leave a system in a vulnerable state. For more information checkout the CWE-600 (https://cwe.mitre.org/data/definitions/600.html) advisory.

I/O function calls should not be vulnerable to path injection attacks

User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Constructing file system paths directly from tainted data could enable an attacker to inject specially crafted values, such as ‘../’, that change the initial path and, when accessed, resolve to a path on the filesystem where the user should normally not have access. A successful attack might give an attacker the ability to read, modify, or delete sensitive information from the file system and sometimes even execute arbitrary operating system commands. This is often referred to as a “path traversal” or “directory traversal” attack. For more information checkout the CWE-99 (https://cwe.mitre.org/data/definitions/99.html) advisory and checkout the (https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection)

ActiveMQConnectionFactory should not be vulnerable to malicious code deserialization

Internally, ActiveMQ relies on Java serialization mechanism for marshaling/unmashaling of the message payload. Deserialization based on data supplied by the user could lead to remote code execution attacks, where the structure of the serialized data is changed to modify the behavior of the object being unserialized. For more information checkout the CWE-502 (https://cwe.mitre.org/data/definitions/502.html) advisory

HTTP response headers should not be vulnerable to injection attacks

User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications constructing HTTP response headers based on tainted data could allow attackers to change security sensitive headers like Cross-Origin Resource Sharing headers. This could, for example, enable Cross-Site Scripting (XSS) attacks. Web application frameworks and servers might also allow attackers to inject new line characters in headers to craft malformed HTTP response. In this case the application would be vulnerable to a larger range of attacks like HTTP Response Splitting/Smuggling. Most of the time this type of attack is mitigated by default modern web application frameworks but there might be rare cases where older versions are still vulnerable. As a best practice, applications that use user provided data to construct the response header should always validate the data first. Validation should be based on a whitelist. For more information checkout the CWE-79 (https://cwe.mitre.org/data/definitions/79.html) advisory and checkout (https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)).

OpenSAML2 should be configured to prevent authentication bypass

From a specially crafted file, an attacker having already access to the SAML system with his own account can bypass the authentication mechanism and be authenticated as another user. This is due to the fact that SAML protocol rely on XML format and how the underlying XML parser interprets XML comments. If an attacker manage to change the field identifying the authenticated user with XML comments, he can exploit the vulnerability. For more information checkout the OWASP (https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication) advisory.

HttpServletRequest.getRequestedSessionId should not be used

Due to the ability of the end-user to manually change the value, the session ID in the request should only be used by a servlet container (E.G. Tomcat or Jetty) to see if the value matches the ID of an an existing session. If it does not, the user should be considered unauthenticated. Moreover, this session ID should never be logged to prevent hijacking of active sessions. For more information checkout the CWE-807 (https://cwe.mitre.org/data/definitions/807) advisory.

LDAP authenticated Analyze your code

An LDAP client authenticates to an LDAP server with a “bind request” which provides, among other, a simple authentication method. Anonymous binds and unauthenticated binds allow access to information in the LDAP directory without providing a password, their use is therefore strongly discouraged. For more information checkout the CWE-521 (https://cwe.mitre.org/data/definitions/521.html) advisory and checkout (https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication).

Web applications should not have a main method

Having a main method in a web application opens a door to the application logic that an attacker may never be able to reach (but watch out if one does!), but it is a sloppy practice and indicates that other problems may be present. For more information checkout the CWE-489 (https://cwe.mitre.org/data/definitions/489.html) advisory.

SecureRandom seeds should not be predictable

The java.security.SecureRandom class provides a strong random number generator (RNG) appropriate for cryptography. However, seeding it with a constant or another predictable value will weaken it significantly. In general, it is much safer to rely on the seed provided by the SecureRandom implementation. For more information checkout the CWE-330 (https://cwe.mitre.org/data/definitions/330.html) advisory and checkout (https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration).

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.