Use of Dangerous Functionality
Play Labs on this vulnerability with SecureFlag!
Description
Use of Dangerous Functionality describes vulnerabilities that arise from the use of proven dangerous programming patterns, misconceived business logic, or the non-adherence to up-to-date standards and guidelines that specify how the software should be implemented.
While more contemporary programming languages are no strangers to newly-found exploits in their source code, this category lends itself in large part to instances in which the bad practice is well documented and yet, whether due to negligence or ignorance, is performed or actioned anyway.
On the other hand, even newer languages are prone to the misuse of dangerous functionality if such functionality - for example, an inherently insecure programming pattern is used - is the result of non-adherence to best practices that advise against such risky behavior.
Impact
Misused and lacking secure programming patterns can be the precursor to a raft of impacts, from overlooked code smells to critical vulnerabilities affecting the compromised system’s confidentiality, availability, and integrity.
Scenarios
The C standard library, which can trace its origins back to the late 60s, is still very much in use today, providing type definitions and functions string handling, input/output processing, computations, memory management, and other operating system services.
Many of the functions still perform reliably; however, threat models evolve, as do additional (mis)use methods and awareness of conditions that open doors to compromise. There are some C functions - for example, gets and scanf - whose use has long been advised against due to the inherent risk of introducing buffer overflow vulnerabilities.
Prevention
If a programming language feature has been deemed dangerous, particularly by multiple peers and standards bodies, then its security risk is not unexpected. It is the responsibility of the developer to ensure they are up-to-date with programming languages’ documentation and inherent security considerations. For languages that have been around for a while (in software terms!), documentation advising against certain practices will almost certainly exist.
In general, to prevent this risk type, developers must do the following:
- Build and maintain practicable secure coding skills.
- Adhere to accepted Coding Standards and Conventions as they pertain to design, architecture, source code, and documentation of the language.
- Formalize a list of dangerous/prohibited programming patterns and ensure they are not used, providing safer alternatives in their place.
- Harden applications with regular testing and review processes.
- Perform automated and manual analysis of the code, both static and dynamic.
Testing
Verify the use of a secure software development lifecycle that addresses security in all stages of development and ensures all features contain functional security constraints. Ensure that a secure coding checklist, security requirements, guidelines, or a set of policies are in place, articulating the dos and don’ts for developers and testers.
- OWASP ASVS: 1