Dangerous Functions

What are dangerous functions?

Dangerous functions are the root cause of all Application Security (AppSec) problems.  In programming, “functions,” also known as procedures, methods, routines or subroutines, are a callable unit of code that has a well-defined behavior and can be invoked by other software. “Dangerous” functions are simply functions that perform a powerful task that could potentially cause harm if misused.  A typical software stack will have thousands of these dangerous methods, to perform tasks such as creating files, parsing documents, executing native commands, deserializing objects and making database queries.

How are dangerous functions exploited?

Dangerous functions are little pieces of code that do dangerous things:  for example, start operating system commands, execute SQL queries, parse XML documents, make a backend connection to an application programming interface (API), or encrypt or hash something. These functions are dangerous because they do  things that can affect security. If an attacker could take control of one or more of these functions, they could cause harm to the company by exploiting the relevant application. There are thousands of dangerous functions available to developers across the application stack, rendering the scale of the AppSec problem enormous. . 

Why are applications, APIs and open-source libraries easy to exploit?

There are thousands of dangerous methods in the typical software stack, and they are complex.  It’s difficult for developers to know how to use them safely. These dangerous functions generally do not give developers any security guidance. There’s neither documentation nor compiler warnings to ensure that developers take the proper precautions.  This virtually guarantees that there will be many vulnerabilities in production.  And these functions typically do not detect or block attacks.  This explains why so many applications, APIs and open-source libraries have so many vulnerabilities and why they are so easy to exploit.

What are dangerous JS functions and PHP functions?

Every language and framework has a huge list of these dangerous functions. Globally, JavaScript is one of the top most-used code languages among developers. As such, it makes dangerous js functions available to the developer, with neither indications nor documentation regarding their potential danger.  When dangerous functions are used, there are no warning signs that their use could potentially allow attackers to take control of the application. The creation of vulnerabilities is inevitable, given the widespread use of these   dangerous functions.  Attackers are also targeting these dangerous functions in order to exploit those vulnerabilities.  

The same applies to dangerous PHP functions — another coding language popular among developers globally. 

How does Contrast Security protect dangerous functions?

Contrast Security has the only application security application security tool that addresses the root cause of this  AppSec problem. Contrast Security adopts a zero-trust approach to application security through its Runtime Security product. Contrast’s Runtime Security platform unifies IAST (Interactive Application Security Testing), RASP (Runtime Application Self-Protection) and runtime SCA (Software Composition Analysis) into one product. It actively monitors and analyzes application behavior in real time, surrounding dangerous functions with trust boundaries,  identifying vulnerabilities in the development and testing phase, and blocking attacks in production. We alert the developer when dangerous functions have been invoked without proper sanitization, and we give the developer instant feedback on vulnerabilities. Think of runtime security as adding a security boundary around each application that protects them in production and in the development phase. 

Contrast Runtime Security puts in the right checks, in all the right places, to alert the developers of real vulnerabilities and to alert security teams of real attacks, giving them full context and insights into the application, the code, the library in use, the vulnerability and the attack.