1. Home
  2. Mitigations
  3. Application Developer Guidance

Application Developer Guidance

This mitigation describes any guidance or training given to developers of applications to avoid introducing security weaknesses that an adversary may be able to take advantage of.

ID: M1013
Version: 1.0
Created: 25 October 2017
Last Modified: 17 October 2018
Version Permalink
Enterprise Layer
download view
Mobile Layer
download view

Techniques Addressed by Mitigation

Domain ID Name Use
Enterprise T1547 .011 Boot or Logon Autostart Execution: Plist Modification

Ensure applications are using Apple's developer guidance which enables hardened runtime.[1]
Enterprise T1564 .009 Hide Artifacts: Resource Forking

Configure applications to use the application bundle structure which leverages the /Resources folder location.[2]

Enterprise T1574 Hijack Execution Flow

When possible, include hash values in manifest files to help prevent side-loading of malicious libraries.[3]
.002 DLL Side-Loading

When possible, include hash values in manifest files to help prevent side-loading of malicious libraries.[3]
Enterprise T1078 Valid Accounts

Ensure that applications do not store sensitive data or credentials insecurely. (e.g. plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage).
Mobile T1517 Access Notifications

Application developers could be encouraged to avoid placing sensitive data in notification text.
Mobile T1413 Access Sensitive Data in Device Logs

Application developers should be discouraged from writing sensitive data to the system log in production apps.
Mobile T1513 Screen Capture

Application developers can apply FLAG_SECURE to sensitive screens within their apps to make it more difficult for the screen contents to be captured.[4]
Mobile T1416 URI Hijacking

Developers should use Android App Links[5] and iOS Universal Links[6] to provide a secure binding between URIs and applications, preventing malicious applications from intercepting redirections. Additionally, for OAuth use cases, PKCE[7] should be used to prevent use of stolen authorization codes.

References

  1. Apple Inc.. (2021, January 1). Hardened Runtime: Manage security protections and resource access for your macOS apps.. Retrieved March 24, 2021.
  2. Apple Inc. (2021, February 18). App security overview. Retrieved October 12, 2021.
  3. Amanda Steward. (2014). FireEye DLL Side-Loading: A Thorn in the Side of the Anti-Virus Industry. Retrieved March 13, 2020.
  4. Nightwatch Cybersecurity. (2016, April 13). Research: Securing Android Applications from Screen Capture (FLAG_SECURE). Retrieved November 5, 2019.
  1. Google. (n.d.). Verify Android App Links. Retrieved September 11, 2020.
  2. Apple. (n.d.). Universal Links for Developers. Retrieved September 11, 2020.
  3. N. Sakimura, J. Bradley, and N. Agarwal. (2015, September). IETF RFC 7636: Proof Key for Code Exchange by OAuth Public Clients. Retrieved December 21, 2016.