Giter VIP home page Giter VIP logo

bloop-portfolio's People

Contributors

evanagee avatar joshuagomora avatar klentoy avatar nattatorn-dev avatar wester97 avatar

bloop-portfolio's Issues

NowSecure static analysis: Application Includes Insecure Library for Processing Biometric Authentication

Summary

The Local Authentication library was found included in your application binary. At worst, it is being used for biometric authentication that is easily bypassed by someone with access to the device. At best, it is extraneous functionality that should not be included in the app as a best practice.

Recommendation

Consider using Keychain ACLs (Access Control Lists) to achieve similar
functionality.

An example implementation would store the application's
secret in a Keychain and assign an ACL to this Keychain item that would
instruct iOS to perform a user presence check before reading and returning
the Keychain item to the application. Sample code can be found
on Apple's website.

Risk and Regulatory Information

Severity: low
CVSS: 3.8

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure static analysis: Manifest Declared Broadcast Receivers Not Protected With Permissions Can Leak Data to Other Apps

Summary

Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. A malicious app installed on the device can attempt to send broadcast intents that trigger the unprotected broadcast receiver. These intents can modify the runtime of the app, making the app a potential phishing vector. If the sender app's broadcasts contain sensitive information, a malicious app may be able to perform intent sniffing, leaking sensitive data. Furthermore, a malicious app can register itself with high priority, if the broadcast is an ordered broadcast, to receive the broadcast first. If the malicious app is the first to receive the broadcast, it could cancel the broadcast causing a denial of service, or it could inject a malicious data into the broadcast.

Recommendation

If the broadcast receiver handles sensitive information, specify Signature or SignatureorSystem level permissions to restrict access to only certain applications. When there is no requirement to send broadcasts across apps on the device i.e when the receivers are in the same app as the sender, use local broadcasts instead. Details and code snippets can be found at (https://developer.android.com/guide/components/broadcasts)

Risk and Regulatory Information

Severity: medium
CVSS: 4

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure static analysis: Selectively Disabled App Protection (ATS) Can Lead to Insecure Network Connections

Summary

ATS Exemptions were identified within the app and need to be reviewed to ensure they are both appropriate and have allowable exemptions.

On Apple platforms, a networking security feature called App Transport Security (ATS) improves privacy and data integrity for all apps and app extensions. ATS blocks connections that don't meet minimum security requirements. In some cases it may be necessary to connect to a server that isn't fully secure and cannot be reconfigured. In this case, exemptions can be added to the ATS requirements. By allowing exemptions, the app may be able to communicate using insecure network protocols which can lead to data exposure or manipulation. Unless absolutely necessary, ATS exemptions should always be avoided. If absolutely required, an additional and continuous review of the data transmitted must be performed to ensure changes to the app, SDK, or the API endpoints called do not lead to security issues.

Adding certain ATS exceptions to the app's Information Property List file requires a justification to be provided and may trigger additional App Store review for the app. Using ATS can prevent man-in-the-middle attacks in situations where weak ciphers and/or old versions of TLS are used since valid self-signed certificates are accepted. This client side protection can be used to enforce widely-adopted best practice network security standards and should be used on all apps.

Recommendation

Ensure that the server meets the following minimum security requirements to avoid having to implement any ATS exemptions:

  • The certificate has an intact digital signature that shows the certificate has not been tampered with.
  • The certificate has not expired.
  • The certificate has a name that matches the server's DNS name.
  • The certificate is signed by another valid certificate, which is in turned signed by another, and so on back to a trusted anchor certificate. The trusted anchor certificate must be issued by a Certificate Authority (CA). The anchor certificate must be part of the client operating system, as indicated in lists of available trusted root certificates in iOS, or be installed on the client by the user or a system administrator.
  • The server certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key of at least 2048 bits or an Elliptic-Curve Cryptography (ECC) key of at least 256 bits.
  • The certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a fingerprint, of at least 256 bits (SHA-256 or greater).
  • The connection must use Transport Layer Security (TLS) protocol version 1.2 or later.
  • Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.
  • The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

If the server cannot be configured according to the minimum security requirements mentioned above, ensure that the justifications associated with each of the listed exemptions provides sufficient information for the App Store to determine why the app cannot make secure connections by default. Failure to do so may result in rejection from the App Store. Examples of justifications include:

  • The app must connect to a server managed by another entity that doesn't support secure connections.
  • The app must support connecting to devices that cannot be upgraded to use secure connections and that must be accessed using public host names.
  • The app must display embedded web content from a variety of sources but can't use a class supported by the web content exception.
  • The app loads media content that is encrypted and that contains no personalized information.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Using HTTP Exposing Network Data to Interception and Manipulation

Summary

HTTP requests were detected during dynamic analysis. Every HTTP request can potentially reveal information about the behaviors and identities of the user. A remote attacker with access to the same local or upstream network as the user could use network monitoring software such as Wireshark to observe and modify the data.

Recommendation

Risk and Regulatory Information

Severity: medium
CVSS: 6.5

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Use of Unsafe Serialization API Exposes App to Remote Code Execution

Summary

When an application has some logic to receive arbitrary data (for example over the network) and to then de-serialize the data into an object, caution should be used when implementing this logic. If raw data can choose an arbitrary class as the the object it gets de-serialized to, this can lead to remote code execution.

In iOS applications, object deserialization/serialization is usually implemented using the NSCoding protocol, which allows the developer to implement the serialization logic for their own classes, or the NSSecureCoding protocol which extends the NSCoding protocol. An implementation which uses the NSCoding protocol is vulnerable to data being deserialized to a different object than what was expected by the developer, also referred to as an “object substitution attack” in Apple's documentation. For more information, watch https://developer.apple.com/videos/play/wwdc2018/222/.

Recommendation

Make sure you have adopted NSSecureCoding in the data you decode. When writing a class that supports secure coding, ensure that the + (BOOL)supportsSecureCoding class property's getter returns true. Ensure that all - (id)decodeObjectForKey:(NSString*)key calls are replaced with - (id)decodeObjectOfClass:(Class)c forKey:(NSString*)key. Also avoid using the deprecated unarchive*ObjectWithData and unarchive*ObjectWithFile classes and implement unarchive*OfClass classes instead. Refer to NSSecureCoding for further details.

Risk and Regulatory Information

Severity: medium
CVSS: 4.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Zip Code Leaked To Device Logs

Summary

The information specified has been found within device logs. Data written to device system logs can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust. Another attack vector includes devices that allow other apps to view the device system logs. This is common on various OEM devices.

Recommendation

To prevent this sensitive information from being compromised (such as by
another application or process running on the same device), it is recommended
that debug logs be disabled in a production environment. More details and code snippets can be found at https://developer.android.com/studio/publish/preparing.

Another method involves leveraging ProGuard or DexGuard (or an alternative) to completely remove the
method calls to the Log class, thus stripping all calls to Log.d, Log.i,
Log.v, Log.e methods. One example is use add the following snippet to
proguard.cfg:

-assumenosideeffects class android.util.Log {
public static *** d(...);
public static *** v(...);
public static *** i(...);
public static *** e(...);
}

The context table below shows the log entries that contained the sensitive information specified.

Risk and Regulatory Information

Severity: low
CVSS: 3.3

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "Secure" Misconfiguration Can Lead to Web Vulnerabilies

Summary

Cookies were found to have the "Secure" flag set to false. If a cookie is not marked as “Secure,” it may be transmitted over an insecure connection whether or not the session with the host is secure. In other words, it may be be transmitted over an HTTP connection. If an attacker can intercept a cookie intended to be transmitted over a secure channel, the attacker may be able to get access to secure session tokens or other authentication information.

Recommendation

It is recommended to enable the "secure" flag to instruct the browser to only send the cookie if the request is sent using a secure channel.

More information on this type of vulnerability can be found at: https://www.owasp.org/index.php/SecureFlag#Setting_the_Secure_Flag and https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this, one of which is to set it within the
response header:

Set-Cookie: =[; =]
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure static analysis: Not Using Built-in Binary Protection (ARC) Exposes Components to Memory Corruption Attacks

Summary

Libraries found in the app were not compiled using ARC, a free feature of Objective-C and Swift. Enabling it has no discernable downsides, and prevents memory corruption attack such as object-use-after-free exploits. If those exploits are possible, attackers can potentially gain access to a wide variety of information and access with potentially severe consequences.

Evaluation Criteria

This is a warning because the components in question may be outside of your control. The context table below should be checked and if libraries that can be controlled are listed it should be considered a vulnerability and remediated.

Recommendation

All newer apps will have ARC enabled by default. However, if it has become disabled you can go to the Build Settings for the App and make sure that "Objective-C Automatic Reference Counting" is set to YES.
It may be necessary to migrate existing projects to ARC with the Refactoring tool provided by Apple in Xcode that helps the developer in the process. This will enable automatic memory management in your app as described in the iOS Developer Library.

Risk and Regulatory Information

Severity: low
CVSS: 1.6

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Advertiser ID Stored Insecurely On Device

Summary

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Recommendation

Sensitive data should not be stored in local app files without the right protection level and unencrypted. It is highly recommended to encrypt all locally stored sensitive data using a strong encryption algorithm. It is also recommended to set the strongest possible data protection level on the file containing the sensitive data. Review the data protection level(s) set on the file(s) listed here and ensure that they are either NSFileProtectionComplete for complete protection or NSFileProtectionCompleteUntilFirstUserAuthentication to be protected until the user first authenticates to the device. Details and code snippets can be found at https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: low
CVSS: 2.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Failure to Validate Certificate Hostname Allows Data to be Exposed and Modified Remotely

Summary

The application does not have proper hostname validation implemented.

A remote attacker with access to the local or upstream network as the user could use a certificate from a valid certificate authority to intercept and modify traffic from these endpoints.

Recommendation

Risk and Regulatory Information

Severity: high
CVSS: 7

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure static analysis: Use of JavaScript Interface Potentially Exposes New Attack Vector

Summary

Your application is using addJavascriptInterface(). This may allow an attacker to execute arbitrary code on Android devices. The vulnerability is exploited by injecting JavaScript into a WebView which then would be loaded by the application and executed.

Recommendation

Disable JavaScript and Plugin support if they are not needed. They are
disabled by default but it is good practice to explicitly set these.
Disable local file access. This restricts access to the app's resource
and asset directory and mitigates against an attack from a web page
which seeks to gain access to other locally accessible files. Prevent
loading content from 3rd party hosts. This is tricky to completely
prevent from within an app but a developer can override shouldOverrideUrlLoading
and code shouldInterceptRequest to intercept,
inspect, and validate most requests initiated from within a WebView. A
whitelist scheme can also be implemented by using the URI class to
inspect the components of a URI and ensure it matches a whitelist of
approved resources. Google provides remediation steps at https://support.google.com/faqs/answer/9095419?hl=en
and sample code can be found on GitHub.

This method can be used to allow JavaScript to control the host
application. This is a powerful feature, but also presents a security risk
for apps targeting JELLY_BEAN or earlier. Apps that target a version later
than JELLY_BEAN are still vulnerable if the app runs on a device running
Android earlier than 4.2. The most secure way to use this method is to
target JELLY_BEAN_MR1 and to ensure the method is called only when
running on Android 4.2 or later. With these older versions, JavaScript
could use reflection to access an injected object's public fields. Use of
this method in a WebView containing untrusted content could allow an
attacker to manipulate the host application in unintended ways, executing
Java code with the permissions of the host application. Use extreme care
when using this method in a WebView which could contain untrusted
content.

Risk and Regulatory Information

Severity: low
CVSS: 3.1

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure dynamic analysis: Advertiser ID Stored Insecurely On Device

Summary

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Recommendation

Sensitive data should not be stored in local app files without the right protection level and unencrypted. It is highly recommended to encrypt all locally stored sensitive data using a strong encryption algorithm. It is also recommended to set the strongest possible data protection level on the file containing the sensitive data. Review the data protection level(s) set on the file(s) listed here and ensure that they are either NSFileProtectionComplete for complete protection or NSFileProtectionCompleteUntilFirstUserAuthentication to be protected until the user first authenticates to the device. Details and code snippets can be found at https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: low
CVSS: 2.3

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "HTTPOnly" Misconfiguration Can Lead to Web Vulnerabilities

Summary

The following cookie was found to have the "httponly" flag disabled.
Setting the "HTTPOnly" flag on a cookie prevents attacks such as cross-site scripting (XSS), because the cookie cannot be accessed via the client side (e.g., cannot be accessed using a snippet of JavaScript code). If an attacker can access via the cookie on the client side, malicious code may be written to collect that cookie and any session/authentication information.

Recommendation

It is recommended to enable the httponly flag to prevent access via a
client-side script.

More information can be found on this vulnerability at https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this flag, one of
which is to set it within the response header:

Set-Cookie: =[; =]q
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure static analysis: Use of JavaScript Interface Potentially Exposes New Attack Vector

Summary

Your application is using addJavascriptInterface(). This may allow an attacker to execute arbitrary code on Android devices. The vulnerability is exploited by injecting JavaScript into a WebView which then would be loaded by the application and executed.

Recommendation

Disable JavaScript and Plugin support if they are not needed. They are
disabled by default but it is good practice to explicitly set these.
Disable local file access. This restricts access to the app's resource
and asset directory and mitigates against an attack from a web page
which seeks to gain access to other locally accessible files. Prevent
loading content from 3rd party hosts. This is tricky to completely
prevent from within an app but a developer can override shouldOverrideUrlLoading
and code shouldInterceptRequest to intercept,
inspect, and validate most requests initiated from within a WebView. A
whitelist scheme can also be implemented by using the URI class to
inspect the components of a URI and ensure it matches a whitelist of
approved resources. Google provides remediation steps at https://support.google.com/faqs/answer/9095419?hl=en
and sample code can be found on GitHub.

This method can be used to allow JavaScript to control the host
application. This is a powerful feature, but also presents a security risk
for apps targeting JELLY_BEAN or earlier. Apps that target a version later
than JELLY_BEAN are still vulnerable if the app runs on a device running
Android earlier than 4.2. The most secure way to use this method is to
target JELLY_BEAN_MR1 and to ensure the method is called only when
running on Android 4.2 or later. With these older versions, JavaScript
could use reflection to access an injected object's public fields. Use of
this method in a WebView containing untrusted content could allow an
attacker to manipulate the host application in unintended ways, executing
Java code with the permissions of the host application. Use extreme care
when using this method in a WebView which could contain untrusted
content.

Risk and Regulatory Information

Severity: low
CVSS: 3.1

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "HTTPOnly" Misconfiguration Can Lead to Web Vulnerabilities

Summary

The following cookie was found to have the "httponly" flag disabled.
Setting the "HTTPOnly" flag on a cookie prevents attacks such as cross-site scripting (XSS), because the cookie cannot be accessed via the client side (e.g., cannot be accessed using a snippet of JavaScript code). If an attacker can access via the cookie on the client side, malicious code may be written to collect that cookie and any session/authentication information.

Recommendation

It is recommended to enable the httponly flag to prevent access via a
client-side script.

More information can be found on this vulnerability at https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this flag, one of
which is to set it within the response header:

Set-Cookie: =[; =]q
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Improper Permissions Granting Read Access to Other Apps

Summary

Violations were detected while monitoring file calls during dynamic analysis. Although it is possible that the permissions on the respective file(s) were changed later during runtime, the issue is that at some
point in between, another process could have opened the file and read it. If the other process didn't close the file, the opened file descriptor could still be used to read the file's content. Because of this,
it possible that manually checking the file permissions on a local device may not yield the same result as shown here.

Recommendation

Creating world-readable files is very dangerous, likely to cause security holes in applications, and is strongly discouraged. Instead, applications should use more formal mechanism for interactions such as
ContentProvider, BroadcastReceiver, and Service. There are also no guarantees that this access mode will remain on a file, such as when it goes through a backup and restore, so code that relies on this can
fail unexpectedly. For instances where the file permissions are set correctly later at runtime, it is recommended to find the initial source of the violation in the code, and use less permissive permissions
when making file calls.

Risk and Regulatory Information

Severity: medium
CVSS: 4.7

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure dynamic analysis: App is Using Outdated or Insecure Cryptography

Summary

The application was found to use weak cryptographic algorithms during app runtime. These methods are usually easily reverse engineered, so the data is not really protected very well. An attacked with access to the encrypted data could easily see the data that was obfuscated.##Evaluation Criteria
It is a best practice not to use insecure methods to encrypt data. However, not all companies require this. The context table below should be evaulated against the standards for the app. Also, please note there is a separate finding specifically for sensitive data being encrypted using these methods.

Recommendation

Change to using algrythms that are secure. Guidance can be found for Android and from Apple.

For more guidance on best practices in picking strong cryptography, please see OWASP's
Cryptographic Storage Cheat_Sheet.',

Risk and Regulatory Information

Severity: low
CVSS: 3.7

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: App is Encoding Sensitive Information Using Outdated or Insecure Cryptography

Summary

The application was found to use weak cryptographic algorithms to encode sensitive data while exercising the app. These outdated algorithms are often in violation of common compliance standards. They may also be vulnerable to publicly disclosed attacks. The sensitive data being encoded is also at a greated risk of being exposed due to the often trivial effort to decode the data.

Recommendation

Avoid using outdated algorithms for processes involving the confidentiality or integrity of the app. For guidance on best practices in picking strong cryptography, please see Apple's documentation on cryptography or OWASP's
Cryptographic Storage Cheat_Sheet.

Risk and Regulatory Information

Severity: medium
CVSS: 4.8

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: Build Fingerprint Stored Insecurely On Device

Summary

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Recommendation

Sensitive data should be transmitted and displayed but not persisted to memory. This is typically achieved by storing sensitive data in RAM - which gets cleared when the app is closed - or encrypting the data using strong encryption.

If sensitive data must be persisted on the device, it should be protected appropriately. See https://developer.android.com/topic/security/data for details and code snippets to implement these protections.

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: low
CVSS: 2.3

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "HTTPOnly" Misconfiguration Can Lead to Web Vulnerabilities

Summary

The following cookie was found to have the "httponly" flag disabled.
Setting the "HTTPOnly" flag on a cookie prevents attacks such as cross-site scripting (XSS), because the cookie cannot be accessed via the client side (e.g., cannot be accessed using a snippet of JavaScript code). If an attacker can access via the cookie on the client side, malicious code may be written to collect that cookie and any session/authentication information.

Recommendation

It is recommended to enable the httponly flag to prevent access via a
client-side script.

More information can be found on this vulnerability at https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this flag, one of
which is to set it within the response header:

Set-Cookie: =[; =]q
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure static analysis: Key Used to Publish App is Potentially Forgeable

Summary

Your application was signed using a key length less than or equal to 1024 bits, making it potentially vulnerable to forged digital signatures. Short key lengths may be vulnerable to brute force attacks and allow an attacker, with access to this key, to inject malware into trusted versions of apps, or tarnish the publishers brand. When signed with a short key length, an attacker will require significantly less time to crack your signing key. Once an attacker has access to the key, they may publish updates for your app that will accepted by the OS as valid.

Recommendation

We recommend signing your app using a key with a length of at least 2048
bits (preferably 4096 bits) to provide optimum protection against forged
digital signatures. Keytool, used to sign Android applications as described
here: http://developer.android.com/tools/publishing/app-signing.html,
can be used with the parameter -keysize to specify a longer key
length than the 1024-bit default.

Risk and Regulatory Information

Severity: medium
CVSS: 5.9

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "Secure" Misconfiguration Can Lead to Web Vulnerabilies

Summary

Cookies were found to have the "Secure" flag set to false. If a cookie is not marked as “Secure,” it may be transmitted over an insecure connection whether or not the session with the host is secure. In other words, it may be be transmitted over an HTTP connection. If an attacker can intercept a cookie intended to be transmitted over a secure channel, the attacker may be able to get access to secure session tokens or other authentication information.

Recommendation

It is recommended to enable the "secure" flag to instruct the browser to only send the cookie if the request is sent using a secure channel.

More information on this type of vulnerability can be found at: https://www.owasp.org/index.php/SecureFlag#Setting_the_Secure_Flag and https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this, one of which is to set it within the
response header:

Set-Cookie: =[; =]
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure static analysis: Failure to Use Platform Data Protections Leaves App Data Potentially Exposed on the Device

Summary

The application was found to implement an improper Data Protection Entitlement based on the data handled by the application. This could expose sensitive information about the device or user to an attacker with access to the device. Apple provides Data Protection Entitlements to protect sensitive data in iOS by encrypting it on disk. Developers can set 4 different levels of protection: 1) No protection (file is always accessible), 2) Complete protection until first user authentication (default), 3) Complete unless already open and 4) Complete (file is accessible only when the device is unlocked). All sensitive user data and device identifiers should be protected at rest on the device.

Recommendation

Data Protection Entitlements represent the level of data protection that encrypts sensitive user
data when accessed on some devices. The level of protection may vary depending on the information
that is being handled by the application. Sensitive user data, files containing personal information
about the user, or files created directly by the user, always warrant the strongest level of
protection (NSFileProtectionComplete), meaning that the file is accessible only when the device is
unlocked. Assign the complete protection level to user data files and manage access to those files
using the app delegate methods.

Risk and Regulatory Information

Severity: low
CVSS: 3.9

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure static analysis: Context Registered Broadcast Receivers Not Protected With Permissions

Summary

Android apps can dynamically register broadcast receivers and specify permissions to restrict access to them. Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. This test detects any context-registered broadcast receivers that have not been protected with permissions.

Recommendation

If the broadcast receiver handles sensitive information, specify Signature or SignatureorSystem level permissions to restrict access to only certain applications. When there is no requirement to send broadcasts across apps on the device i.e when the receivers are in the same app as the sender, use local broadcasts instead.

Risk and Regulatory Information

Severity: medium
CVSS: 4

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure static analysis: Application Includes Insecure Library for Processing Biometric Authentication

Summary

The Local Authentication library was found included in your application binary. At worst, it is being used for biometric authentication that is easily bypassed by someone with access to the device. At best, it is extraneous functionality that should not be included in the app as a best practice.

Recommendation

Consider using Keychain ACLs (Access Control Lists) to achieve similar
functionality.

An example implementation would store the application's
secret in a Keychain and assign an ACL to this Keychain item that would
instruct iOS to perform a user presence check before reading and returning
the Keychain item to the application. Sample code can be found
on Apple's website.

Risk and Regulatory Information

Severity: low
CVSS: 3.8

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: WiFi IP Address Stored Insecurely On Device

Summary

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Recommendation

Sensitive data should be transmitted and displayed but not persisted to memory. This is typically achieved by storing sensitive data in RAM - which gets cleared when the app is closed - or encrypting the data using strong encryption.

If sensitive data must be persisted on the device, it should be protected appropriately. See https://developer.android.com/topic/security/data for details and code snippets to implement these protections.

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: low
CVSS: 2.3

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure static analysis: Disabled App Protection (ATS) Can Lead to Insecure Network Connections

Summary

The application has globally disabled App Transport Security (ATS).

ATS helps ensure secure connections between an app and the back end server(s) and is a client side protection that should be used on all apps. It is widely used to enforce best practice network security standards. Disabling the ATS functionality globally will allow a connection regardless of HTTP or HTTPS configuration, allow connections to servers with lower TLS versions and allow connections using cipher suites that do not support forward secrecy.

ATS is on by default when an app is linked to iOS 9.0 SDK or later. With ATS enabled, HTTP connections are forced to use HTTPS (TLS v1.2), and any attempts to connect using insecure HTTP will fail. Options for implementing ATS include:

  • ATS can be enabled globally (by linking to iOS 9.0 or later SDK) and the developer can choose to decrease ATS restrictions on a specific server using an exception key.
  • ATS can be disabled globally (by setting the NSAllowsArbitraryLoads key to YES). An exception could then allow the developer to increase ATS restrictions on a specific server. Use of weak ciphers and old versions of TLS, along with only accepting valid self-signed certificates are all processes that can lead to man-in-the-middle attacks, but can be prevented through the use of App Transport Security.

Recommendation

For apps running on iOS 9.0 or higher, ATS must be
enabled globally by linking to the iOS 9.0 or later SDK, and avoid
setting the "NSAllowsArbitraryLoads" key to "Yes" or "True". For any
existing apps which communicate to servers inside HTTP, an exception must
be set using either the "NSExceptionAllowsInsecureHTTPLoads" or
"NSThirdPartyExceptionAllowsInsecureHTTPLoads" key.

Instructions for Cordova can be found at https://cordova.apache.org/docs/en/9.x/guide/appdev/whitelist/index.html#ios-whitelisting

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: App is Using Outdated or Insecure Cryptography

Summary

The application was found to use weak cryptographic algorithms during app runtime. These methods are usually easily reverse engineered, so the data is not really protected very well. An attacked with access to the encrypted data could easily see the data that was obfuscated.##Evaluation Criteria
It is a best practice not to use insecure methods to encrypt data. However, not all companies require this. The context table below should be evaulated against the standards for the app. Also, please note there is a separate finding specifically for sensitive data being encrypted using these methods.

Recommendation

Change to using algrythms that are secure. Guidance can be found for Android and from Apple.

For more guidance on best practices in picking strong cryptography, please see OWASP's
Cryptographic Storage Cheat_Sheet.',

Risk and Regulatory Information

Severity: low
CVSS: 3.7

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure static analysis: Application Includes Insecure Library for Processing Biometric Authentication

Summary

The Local Authentication library was found included in your application binary. At worst, it is being used for biometric authentication that is easily bypassed by someone with access to the device. At best, it is extraneous functionality that should not be included in the app as a best practice.

Recommendation

Consider using Keychain ACLs (Access Control Lists) to achieve similar
functionality.

An example implementation would store the application's
secret in a Keychain and assign an ACL to this Keychain item that would
instruct iOS to perform a user presence check before reading and returning
the Keychain item to the application. Sample code can be found
on Apple's website.

Risk and Regulatory Information

Severity: low
CVSS: 3.8

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: Improper Permissions Granting Write Access to Other Apps

Summary

Files were found to be world readable during dynamic analysis. Although it is possible that the permissions on the respective file(s) were changed later during runtime, the issue is that at some
point in between, another process could have opened the file and read it. If the other process didn't close the file, the opened file descriptor could still be used to read the file's content. Because of this,
it possible that manually checking the file permissions on a local device may not yield the same result as shown here. There are also no guarantees that this access mode will remain on a file, such as when it goes through a backup and restore, so code that relies on this can
fail unexpectedly. For instances where the file permissions are set correctly later at runtime, it is recommended to find the initial source of the violation in the code, and use less permissive permissions
when making file calls.

Recommendation

Creating world-readable files is very dangerous, likely to cause security holes in applications, and is strongly discouraged. Instead, applications should use more formal mechanism for interactions such as
Content Providers. Details and code snippets can be found at https://developer.android.com/guide/topics/providers/content-provider-creating.

The context table below give the location of all files that were found to be world-readable at any time while the app was running.

Risk and Regulatory Information

Severity: medium
CVSS: 5

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Failure to Validate Certificate Authority Allows Data to be Exposed and Modified Remotely

Summary

The application does not properly validate the Certificate Authority (CA) for the implemented certificate. CAs vouch for the authenticity of a website by verifying the registration of the site's domain name and the company/organization behind it. If the certificate's CA data is not properly validated, a malicious actor could create an invalid certificate by utilizing any CA, effectively making the app susceptible to an Man-in-the-Middle attack. This type of attack gives the culprit the ability to capture, view, and modify traffic sent and received between the app and the server. Impacted URLs are listed in the table below.

Recommendation

Risk and Regulatory Information

Severity: high
CVSS: 7

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure static analysis: Manifest Declared Broadcast Receivers Not Protected With Permissions Can Leak Data to Other Apps

Summary

Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. A malicious app installed on the device can attempt to send broadcast intents that trigger the unprotected broadcast receiver. These intents can modify the runtime of the app, making the app a potential phishing vector. If the sender app's broadcasts contain sensitive information, a malicious app may be able to perform intent sniffing, leaking sensitive data. Furthermore, a malicious app can register itself with high priority, if the broadcast is an ordered broadcast, to receive the broadcast first. If the malicious app is the first to receive the broadcast, it could cancel the broadcast causing a denial of service, or it could inject a malicious data into the broadcast.

Recommendation

If the broadcast receiver handles sensitive information, specify Signature or SignatureorSystem level permissions to restrict access to only certain applications. When there is no requirement to send broadcasts across apps on the device i.e when the receivers are in the same app as the sender, use local broadcasts instead. Details and code snippets can be found at (https://developer.android.com/guide/components/broadcasts)

Risk and Regulatory Information

Severity: medium
CVSS: 4

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure static analysis: Failure to Use Platform Data Protections Leaves App Data Potentially Exposed on the Device

Summary

The application was found to implement an improper Data Protection Entitlement based on the data handled by the application. This could expose sensitive information about the device or user to an attacker with access to the device. Apple provides Data Protection Entitlements to protect sensitive data in iOS by encrypting it on disk. Developers can set 4 different levels of protection: 1) No protection (file is always accessible), 2) Complete protection until first user authentication (default), 3) Complete unless already open and 4) Complete (file is accessible only when the device is unlocked). All sensitive user data and device identifiers should be protected at rest on the device.

Recommendation

Data Protection Entitlements represent the level of data protection that encrypts sensitive user
data when accessed on some devices. The level of protection may vary depending on the information
that is being handled by the application. Sensitive user data, files containing personal information
about the user, or files created directly by the user, always warrant the strongest level of
protection (NSFileProtectionComplete), meaning that the file is accessible only when the device is
unlocked. Assign the complete protection level to user data files and manage access to those files
using the app delegate methods.

Risk and Regulatory Information

Severity: low
CVSS: 3.9

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: App is Using Outdated or Insecure Cryptography

Summary

The application was found to use weak cryptographic algorithms during app runtime. These methods are usually easily reverse engineered, so the data is not really protected very well. An attacked with access to the encrypted data could easily see the data that was obfuscated.##Evaluation Criteria
It is a best practice not to use insecure methods to encrypt data. However, not all companies require this. The context table below should be evaulated against the standards for the app. Also, please note there is a separate finding specifically for sensitive data being encrypted using these methods.

Recommendation

Change to using algrythms that are secure. Guidance can be found for Android and from Apple.

For more guidance on best practices in picking strong cryptography, please see OWASP's
Cryptographic Storage Cheat_Sheet.',

Risk and Regulatory Information

Severity: low
CVSS: 3.7

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "Secure" Misconfiguration Can Lead to Web Vulnerabilies

Summary

Cookies were found to have the "Secure" flag set to false. If a cookie is not marked as “Secure,” it may be transmitted over an insecure connection whether or not the session with the host is secure. In other words, it may be be transmitted over an HTTP connection. If an attacker can intercept a cookie intended to be transmitted over a secure channel, the attacker may be able to get access to secure session tokens or other authentication information.

Recommendation

It is recommended to enable the "secure" flag to instruct the browser to only send the cookie if the request is sent using a secure channel.

More information on this type of vulnerability can be found at: https://www.owasp.org/index.php/SecureFlag#Setting_the_Secure_Flag and https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this, one of which is to set it within the
response header:

Set-Cookie: =[; =]
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Vendor ID Stored Insecurely On Device

Summary

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Recommendation

Sensitive data should not be stored in local app files without the right protection level and unencrypted. It is highly recommended to encrypt all locally stored sensitive data using a strong encryption algorithm. It is also recommended to set the strongest possible data protection level on the file containing the sensitive data. Review the data protection level(s) set on the file(s) listed here and ensure that they are either NSFileProtectionComplete for complete protection or NSFileProtectionCompleteUntilFirstUserAuthentication to be protected until the user first authenticates to the device. Details and code snippets can be found at https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: low
CVSS: 2.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "Secure" Misconfiguration Can Lead to Web Vulnerabilies

Summary

Cookies were found to have the "Secure" flag set to false. If a cookie is not marked as “Secure,” it may be transmitted over an insecure connection whether or not the session with the host is secure. In other words, it may be be transmitted over an HTTP connection. If an attacker can intercept a cookie intended to be transmitted over a secure channel, the attacker may be able to get access to secure session tokens or other authentication information.

Recommendation

It is recommended to enable the "secure" flag to instruct the browser to only send the cookie if the request is sent using a secure channel.

More information on this type of vulnerability can be found at: https://www.owasp.org/index.php/SecureFlag#Setting_the_Secure_Flag and https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this, one of which is to set it within the
response header:

Set-Cookie: =[; =]
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure static analysis: Context Registered Broadcast Receivers Not Protected With Permissions

Summary

Android apps can dynamically register broadcast receivers and specify permissions to restrict access to them. Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. This test detects any context-registered broadcast receivers that have not been protected with permissions.

Recommendation

If the broadcast receiver handles sensitive information, specify Signature or SignatureorSystem level permissions to restrict access to only certain applications. When there is no requirement to send broadcasts across apps on the device i.e when the receivers are in the same app as the sender, use local broadcasts instead.

Risk and Regulatory Information

Severity: medium
CVSS: 4

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure static analysis: Disabled App Protection (ATS) Can Lead to Insecure Network Connections

Summary

The application has globally disabled App Transport Security (ATS).

ATS helps ensure secure connections between an app and the back end server(s) and is a client side protection that should be used on all apps. It is widely used to enforce best practice network security standards. Disabling the ATS functionality globally will allow a connection regardless of HTTP or HTTPS configuration, allow connections to servers with lower TLS versions and allow connections using cipher suites that do not support forward secrecy.

ATS is on by default when an app is linked to iOS 9.0 SDK or later. With ATS enabled, HTTP connections are forced to use HTTPS (TLS v1.2), and any attempts to connect using insecure HTTP will fail. Options for implementing ATS include:

  • ATS can be enabled globally (by linking to iOS 9.0 or later SDK) and the developer can choose to decrease ATS restrictions on a specific server using an exception key.
  • ATS can be disabled globally (by setting the NSAllowsArbitraryLoads key to YES). An exception could then allow the developer to increase ATS restrictions on a specific server. Use of weak ciphers and old versions of TLS, along with only accepting valid self-signed certificates are all processes that can lead to man-in-the-middle attacks, but can be prevented through the use of App Transport Security.

Recommendation

For apps running on iOS 9.0 or higher, ATS must be
enabled globally by linking to the iOS 9.0 or later SDK, and avoid
setting the "NSAllowsArbitraryLoads" key to "Yes" or "True". For any
existing apps which communicate to servers inside HTTP, an exception must
be set using either the "NSExceptionAllowsInsecureHTTPLoads" or
"NSThirdPartyExceptionAllowsInsecureHTTPLoads" key.

Instructions for Cordova can be found at https://cordova.apache.org/docs/en/9.x/guide/appdev/whitelist/index.html#ios-whitelisting

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure static analysis: APK Loads Code Dynamically

Summary

Your application was found to be using dynamic code loading. While this
is not a vulnerability per se, it is not a secure code practice and can
lead to code injection or malicious side-loading of code. This mechanism allows a developer to specify which components of the application should not be loaded by default when the application is started. Typically, core components and additional dependencies are loaded natively at runtime, however, dynamically loaded components are only loaded as they are specifically requested. While this can have a positive impact on performance, or grant additional functionality (i.e. a non-invasive update feature), it can also open the application to serious security vulnerabilities if not implemented properly. Dynamic code loading, if performed using insecure mechanisms, can be vulnerable to arbitrary code execution. If vulnerable, and attacker may be able to use these issues to exploit the app, changing runtime activities.

Recommendation

It is strongly discouraged to load code from outside of the application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management, application testing and can make it impossible to verify the behavior of an application. Dynamically loaded code runs with the same security permissions as the application APK. If the modules are included directly within the APK, then they cannot be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader. There can be instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage. These locations could allow modification of the content in transit, or another application to modify the content on the device, respectively.

Risk and Regulatory Information

Severity: medium
CVSS: 4.3

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: App is Encoding Sensitive Information Using Outdated or Insecure Cryptography

Summary

The application was found to use weak cryptographic algorithms to encode sensitive data while exercising the app. These outdated algorithms are often in violation of common compliance standards. They may also be vulnerable to publicly disclosed attacks. The sensitive data being encoded is also at a greated risk of being exposed due to the often trivial effort to decode the data.

Recommendation

Avoid using outdated algorithms for processes involving the confidentiality or integrity of the app. For guidance on best practices in picking strong cryptography, please see Apple's documentation on cryptography or OWASP's
Cryptographic Storage Cheat_Sheet.

Risk and Regulatory Information

Severity: medium
CVSS: 4.8

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure static analysis: Selectively Disabled App Protection (ATS) Can Lead to Insecure Network Connections

Summary

ATS Exemptions were identified within the app and need to be reviewed to ensure they are both appropriate and have allowable exemptions.

On Apple platforms, a networking security feature called App Transport Security (ATS) improves privacy and data integrity for all apps and app extensions. ATS blocks connections that don't meet minimum security requirements. In some cases it may be necessary to connect to a server that isn't fully secure and cannot be reconfigured. In this case, exemptions can be added to the ATS requirements. By allowing exemptions, the app may be able to communicate using insecure network protocols which can lead to data exposure or manipulation. Unless absolutely necessary, ATS exemptions should always be avoided. If absolutely required, an additional and continuous review of the data transmitted must be performed to ensure changes to the app, SDK, or the API endpoints called do not lead to security issues.

Adding certain ATS exceptions to the app's Information Property List file requires a justification to be provided and may trigger additional App Store review for the app. Using ATS can prevent man-in-the-middle attacks in situations where weak ciphers and/or old versions of TLS are used since valid self-signed certificates are accepted. This client side protection can be used to enforce widely-adopted best practice network security standards and should be used on all apps.

Recommendation

Ensure that the server meets the following minimum security requirements to avoid having to implement any ATS exemptions:

  • The certificate has an intact digital signature that shows the certificate has not been tampered with.
  • The certificate has not expired.
  • The certificate has a name that matches the server's DNS name.
  • The certificate is signed by another valid certificate, which is in turned signed by another, and so on back to a trusted anchor certificate. The trusted anchor certificate must be issued by a Certificate Authority (CA). The anchor certificate must be part of the client operating system, as indicated in lists of available trusted root certificates in iOS, or be installed on the client by the user or a system administrator.
  • The server certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key of at least 2048 bits or an Elliptic-Curve Cryptography (ECC) key of at least 256 bits.
  • The certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a fingerprint, of at least 256 bits (SHA-256 or greater).
  • The connection must use Transport Layer Security (TLS) protocol version 1.2 or later.
  • Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.
  • The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

If the server cannot be configured according to the minimum security requirements mentioned above, ensure that the justifications associated with each of the listed exemptions provides sufficient information for the App Store to determine why the app cannot make secure connections by default. Failure to do so may result in rejection from the App Store. Examples of justifications include:

  • The app must connect to a server managed by another entity that doesn't support secure connections.
  • The app must support connecting to devices that cannot be upgraded to use secure connections and that must be accessed using public host names.
  • The app must display embedded web content from a variety of sources but can't use a class supported by the web content exception.
  • The app loads media content that is encrypted and that contains no personalized information.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure static analysis: Disabled App Protection (ATS) Can Lead to Insecure Network Connections

Summary

The application has globally disabled App Transport Security (ATS).

ATS helps ensure secure connections between an app and the back end server(s) and is a client side protection that should be used on all apps. It is widely used to enforce best practice network security standards. Disabling the ATS functionality globally will allow a connection regardless of HTTP or HTTPS configuration, allow connections to servers with lower TLS versions and allow connections using cipher suites that do not support forward secrecy.

ATS is on by default when an app is linked to iOS 9.0 SDK or later. With ATS enabled, HTTP connections are forced to use HTTPS (TLS v1.2), and any attempts to connect using insecure HTTP will fail. Options for implementing ATS include:

  • ATS can be enabled globally (by linking to iOS 9.0 or later SDK) and the developer can choose to decrease ATS restrictions on a specific server using an exception key.
  • ATS can be disabled globally (by setting the NSAllowsArbitraryLoads key to YES). An exception could then allow the developer to increase ATS restrictions on a specific server. Use of weak ciphers and old versions of TLS, along with only accepting valid self-signed certificates are all processes that can lead to man-in-the-middle attacks, but can be prevented through the use of App Transport Security.

Recommendation

For apps running on iOS 9.0 or higher, ATS must be
enabled globally by linking to the iOS 9.0 or later SDK, and avoid
setting the "NSAllowsArbitraryLoads" key to "Yes" or "True". For any
existing apps which communicate to servers inside HTTP, an exception must
be set using either the "NSExceptionAllowsInsecureHTTPLoads" or
"NSThirdPartyExceptionAllowsInsecureHTTPLoads" key.

Instructions for Cordova can be found at https://cordova.apache.org/docs/en/9.x/guide/appdev/whitelist/index.html#ios-whitelisting

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Improper Permissions Granting Read Access to Other Apps

Summary

Violations were detected while monitoring file calls during dynamic analysis. Although it is possible that the permissions on the respective file(s) were changed later during runtime, the issue is that at some
point in between, another process could have opened the file and read it. If the other process didn't close the file, the opened file descriptor could still be used to read the file's content. Because of this,
it possible that manually checking the file permissions on a local device may not yield the same result as shown here.

Recommendation

Creating world-readable files is very dangerous, likely to cause security holes in applications, and is strongly discouraged. Instead, applications should use more formal mechanism for interactions such as
ContentProvider, BroadcastReceiver, and Service. There are also no guarantees that this access mode will remain on a file, such as when it goes through a backup and restore, so code that relies on this can
fail unexpectedly. For instances where the file permissions are set correctly later at runtime, it is recommended to find the initial source of the violation in the code, and use less permissive permissions
when making file calls.

Risk and Regulatory Information

Severity: medium
CVSS: 4.7

Application

  • Platform: android
  • Package: com.ninegag.android.app

See more detail in the NowSecure Report

NowSecure dynamic analysis: Zip Code Stored Insecurely On Device

Summary

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Recommendation

Sensitive data should not be stored in local app files without the right protection level and unencrypted. It is highly recommended to encrypt all locally stored sensitive data using a strong encryption algorithm. It is also recommended to set the strongest possible data protection level on the file containing the sensitive data. Review the data protection level(s) set on the file(s) listed here and ensure that they are either NSFileProtectionComplete for complete protection or NSFileProtectionCompleteUntilFirstUserAuthentication to be protected until the user first authenticates to the device. Details and code snippets can be found at https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: low
CVSS: 2.3

Application

  • Platform: ios
  • Package: com.yourcompany.PPClient

See more detail in the NowSecure Report

NowSecure dynamic analysis: Vendor ID Leaked to Device Logs

Summary

The information specified has been found within the Apple System Logs. Data written to device system logs can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust. Another attack vector includes devices that allow other apps to view the device system logs. This is common on various OEM devices.

Recommendation

Applications in production should not output logging information. If logs must be generated, they should not include sensitive information. More details and code snippets can be found at https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code

The context table below identifies the logging messages that were observed containing the data specified.

Risk and Regulatory Information

Severity: low
CVSS: 2.1

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: Allowing Third Party Keyboards Potentially Exposes User Input

Summary

This application does not use application:shouldAllowExtensionPointIdentifier: on the application delegate to disable third-party keyboards.
iOS apps can choose to grant permissions to use app extensions such as 3rd party keyboards. Allowing 3rd party keyboards can introduce privacy risks such as keystroke logging and in turn, sensitive data leaks. It is considered a security best practice to disable 3rd party keyboard extensions unless necessary.

Recommendation

Implement application:shouldAllowExtensionPointIdentifier: on the application delegate and return NO for the identifier UIApplicationKeyboardExtensionPointIdentifier.

Details and code snippets can be found at Apple's documentation.

Risk and Regulatory Information

Severity: medium
CVSS: 4

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

NowSecure static analysis: Selectively Disabled App Protection (ATS) Can Lead to Insecure Network Connections

Summary

ATS Exemptions were identified within the app and need to be reviewed to ensure they are both appropriate and have allowable exemptions.

On Apple platforms, a networking security feature called App Transport Security (ATS) improves privacy and data integrity for all apps and app extensions. ATS blocks connections that don't meet minimum security requirements. In some cases it may be necessary to connect to a server that isn't fully secure and cannot be reconfigured. In this case, exemptions can be added to the ATS requirements. By allowing exemptions, the app may be able to communicate using insecure network protocols which can lead to data exposure or manipulation. Unless absolutely necessary, ATS exemptions should always be avoided. If absolutely required, an additional and continuous review of the data transmitted must be performed to ensure changes to the app, SDK, or the API endpoints called do not lead to security issues.

Adding certain ATS exceptions to the app's Information Property List file requires a justification to be provided and may trigger additional App Store review for the app. Using ATS can prevent man-in-the-middle attacks in situations where weak ciphers and/or old versions of TLS are used since valid self-signed certificates are accepted. This client side protection can be used to enforce widely-adopted best practice network security standards and should be used on all apps.

Recommendation

Ensure that the server meets the following minimum security requirements to avoid having to implement any ATS exemptions:

  • The certificate has an intact digital signature that shows the certificate has not been tampered with.
  • The certificate has not expired.
  • The certificate has a name that matches the server's DNS name.
  • The certificate is signed by another valid certificate, which is in turned signed by another, and so on back to a trusted anchor certificate. The trusted anchor certificate must be issued by a Certificate Authority (CA). The anchor certificate must be part of the client operating system, as indicated in lists of available trusted root certificates in iOS, or be installed on the client by the user or a system administrator.
  • The server certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key of at least 2048 bits or an Elliptic-Curve Cryptography (ECC) key of at least 256 bits.
  • The certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a fingerprint, of at least 256 bits (SHA-256 or greater).
  • The connection must use Transport Layer Security (TLS) protocol version 1.2 or later.
  • Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.
  • The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

If the server cannot be configured according to the minimum security requirements mentioned above, ensure that the justifications associated with each of the listed exemptions provides sufficient information for the App Store to determine why the app cannot make secure connections by default. Failure to do so may result in rejection from the App Store. Examples of justifications include:

  • The app must connect to a server managed by another entity that doesn't support secure connections.
  • The app must support connecting to devices that cannot be upgraded to use secure connections and that must be accessed using public host names.
  • The app must display embedded web content from a variety of sources but can't use a class supported by the web content exception.
  • The app loads media content that is encrypted and that contains no personalized information.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.hm.goe

See more detail in the NowSecure Report

NowSecure dynamic analysis: Improper Permissions Granting Write Access to Other Apps

Summary

Files were found to be world readable during dynamic analysis. Although it is possible that the permissions on the respective file(s) were changed later during runtime, the issue is that at some
point in between, another process could have opened the file and read it. If the other process didn't close the file, the opened file descriptor could still be used to read the file's content. Because of this,
it possible that manually checking the file permissions on a local device may not yield the same result as shown here. There are also no guarantees that this access mode will remain on a file, such as when it goes through a backup and restore, so code that relies on this can
fail unexpectedly. For instances where the file permissions are set correctly later at runtime, it is recommended to find the initial source of the violation in the code, and use less permissive permissions
when making file calls.

Recommendation

Creating world-readable files is very dangerous, likely to cause security holes in applications, and is strongly discouraged. Instead, applications should use more formal mechanism for interactions such as
Content Providers. Details and code snippets can be found at https://developer.android.com/guide/topics/providers/content-provider-creating.

The context table below give the location of all files that were found to be world-readable at any time while the app was running.

Risk and Regulatory Information

Severity: medium
CVSS: 5

Application

  • Platform: android
  • Package: com.udemy.android

See more detail in the NowSecure Report

NowSecure dynamic analysis: Cookie "HTTPOnly" Misconfiguration Can Lead to Web Vulnerabilities

Summary

The following cookie was found to have the "httponly" flag disabled.
Setting the "HTTPOnly" flag on a cookie prevents attacks such as cross-site scripting (XSS), because the cookie cannot be accessed via the client side (e.g., cannot be accessed using a snippet of JavaScript code). If an attacker can access via the cookie on the client side, malicious code may be written to collect that cookie and any session/authentication information.

Recommendation

It is recommended to enable the httponly flag to prevent access via a
client-side script.

More information can be found on this vulnerability at https://www.owasp.org/index.php/HttpOnly#Mitigating_the_Most_Common_XSS_attack_using_HttpOnly

There are multiple ways to enable this flag, one of
which is to set it within the response header:

Set-Cookie: =[; =]q
[; expires=][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

The context table below provides the source and the type of cookie which was found to be vulnerable.

Risk and Regulatory Information

Severity: medium
CVSS: 5.3

Application

  • Platform: ios
  • Package: com.vanguard.app

See more detail in the NowSecure Report

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.