R266. Disable insecure functionalities

Requirement

The organization must disable or carefully control the insecure functions of a system (system hardening).

Description

Sometimes platforms include functionalities that are not required or could be harmful for some applications built on top of or residing in them. Other times, applications are developed including functionalities that allow actions that could be considered insecure. All these functionalities should be disabled or otherwise controlled to prevent them from compromising the system’s security. Furthermore, the system must enforce those controls on trusted enforcement points such as access control gateways, severs and serverless functions.

References

  1. CWE-284: Improper Access Control The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

  2. CWE-602: Client-Side Enforcement of Server-Side Security The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

  3. CWE-749: Exposed Dangerous Method or Function The software provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.

  4. OWASP Top 10 A5:2017-Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

  5. OWASP Top 10 A6:2017-Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

  6. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.1) Verify that application layer debugging interfaces such USB, UART, and other serial variants are disabled or protected by a complex password.

  7. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.4) Verify that on-chip debugging interfaces such as JTAG or SWD are disabled or that an available protection mechanism is enabled and configured appropriately.

  8. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.11) Verify that any use of banned C functions are replaced with the appropriate safe equivalent functions.

  9. OWASP-ASVS v4.0.1 V1.4 Access Control Architectural Requirements.(1.4.1) Verify that trusted enforcement points such as at access control gateways, servers, and serverless functions enforce access controls. Never enforce access controls on the client.

  10. OWASP-ASVS v4.0.1 V4.1 General Access Control Design.(4.1.1) Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.

  11. OWASP-ASVS v4.0.1 V6.2 Algorithms.(6.2.5) Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.

  12. OWASP-ASVS v4.0.1 V9.1 Communications Security Requirements.(9.1.3) Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.

  13. OWASP-ASVS v4.0.1 V14.2 Dependency.(14.2.2) Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.

  14. OWASP-ASVS v4.0.1 V14.5 Validate HTTP Request Header Requirements.(14.5.1) Verify that the application server only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy