RACE CONDITION

What Is a Race Condition Vulnerability?

A race condition attack happens when a computing system that’s designed to handle tasks in a specific sequence is forced to perform two or more operations simultaneously. This technique takes advantage of a time gap between the moment a service is initiated and the moment a security control takes effect. This attack, which depends on multithreaded applications, can be delivered in one of two ways: interference caused by untrusted processes (essentially a piece of code that slips into a sequence between steps of a secure programs), and interference caused by a trusted process, which may have the "same'' privileges. Without proper controls, different processes can interfere with each other. Other names used to refer to this vulnerability include Time of Check/Time of Use or TOC/TOU attacks.

Rates of Race Condition Flaws in Software

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

What Happens During a Race Condition Attack?

Web applications, file systems, and networking environments are all vulnerable to a race condition attack. Attackers might target an access control list (ACL), a payroll or human resources database, a transactional system, a financial ledger, or some other data repository. Although race condition attacks don’t happen frequently — because they’re relatively difficult to engineer and attackers must exploit a very brief window of opportunity — when they do happen, they can lead to serious repercussions, including a system granting unauthorized privileges. What’s more, race condition attacks are inherently difficult to detect.

Anatomy of an Race Condition Flaw

When a normal update to an application or database takes place — and names, numbers, or other data are changed to reflect the most current state of information — a cybercriminal could unleash a race condition attack. This is possible because the database isn’t completely rewritten during the update process. As the update takes place, a gap exists, one that can last less than a second or up to a few minutes, during which the system is unprotected. This allows attackers to gain unauthorized access. During this brief period, an attacker can send queries that compromise the system and result in a race condition attack.

Impact of a Race Condition Attack

Once an intruder has breached a system using a race condition attack, it’s possible to alter, manipulate, or steal data, make changes to privileges, insert malicious code, unleash a denial of service (DoS) attack, and deactivate security controls. A race condition attack can also encompass APIs. In one high profile case, the FBI reported that attackers used this methodology to steal more than $1 million from Citibank using cash advance ATM kiosks at casinos located in California and Nevada. The attackers sent near identical queries within a 60-second time window.

Race Condition Flaw Examples

Here’s an example of a race condition vulnerability :(

/* vulp.c */

#include 

#include

#define DELAY 10000

int main()

{

char * fn = "/tmp/XYZ";

char buffer[60];

FILE *fp;

long int i;

/* get user input */

scanf("%50s", buffer );

if(!access(fn, W_OK)){

/* simulating delay */

Laboratory for Computer Security Education 2

for (i=0; i < DELAY; i++){

int a = iˆ2;

}

fp = fopen(fn, "a+");

fwrite("\n", sizeof(char), 1, fp);

fwrite(buffer, sizeof(char), strlen(buffer), fp);

fclose(fp);

}

else printf("No permission \n");

 

This example was created by Wenliang Du at Syracuse University. It is part of a Set-UID program (owned by root). The example appends a string of user input to the end of a temporary file /tmp/XYZ. Since the code uses the root privilege, it checks whether the user actually has access permission for the file /tmp/XYZ. In fact, this is the specific purpose of the access() call. Once the program has verified that the intended user has the privilege, the program opens the file and writes the user input into the file.

At first glance, the program appears to be sound. However, it contains a race condition vulnerability. Due to the window (the simulated delay) between the check (access) and the use (fopen), there is a possibility that the file used by access is different from the file used by fopen, despite the fact that they share the file name /tmp/XYZ. A malicious attacker who can make /tmp/XYZ a symbolic link pointing to /etc/shadow can cause the user input to be appended to /etc/shadow. The program runs with the root privilege and so it can overwrite any file.

Preventing Damage and Remediating Code Are Critical

It’s critical to scan and review code for race condition vulnerabilities. This includes the use of static analysis. Overall, SANS Technology Institute points out: “Careful programming and good administration practices usually can clear [race condition vulnerabilities] up, but you've got to find them first.” This means educating development teams about the risks of race condition attacks and how to prevent them.

CA Veracode Can Aid in the Removal of Race Condition Flaws

CA Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including race condition, in running web applications, in either production or pre-production environments.

CA Veracode Static Analysis can accurately identify race condition vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing race condition and other security flaws through integrated eLearning materials.

ERROR HANDLING FLAWS - INFORMATION AND HOW TO FIX TUTORIAL

What Is Improper Error Handling?

It’s not unusual for web applications or databases to generate error messages. In fact, they’re a normal part of operations, and they provide valuable insights into issues and problems. However, improper error handling introduces significant security risks.

The most common vulnerabilities occur when a system reveals detailed error messages or codes generated from stack traces, database dumps, and a wide variety of other problems, including out of memory, null pointer exceptions, and network timeout errors.

Attackers can use this information to exploit flaws and break into systems. In addition, inconsistencies in messages may offer clues about how a site operates and how to exploit it. Improper error handling may result in system crashes, buffer overflows and denial of service attacks. They can also expose sensitive data and information, including passwords.

Rates of Error Handling Flaws in Software

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

How Does Improper Error Handling Occur?

Improper error handling results when security mechanisms fail to deny access until it’s specifically granted. This may occur as a result of a mismatch in policy and coding practice. It may also result from code that lacks appropriate error handling logic.

For example, a system may grant access until it’s denied. When users input a set of instructions that the system can’t accommodate, they may receive an error message such as “file not found” or “access denied.” Frequently, the user isn’t supposed to know the file exists. But the message confirms that an inaccessible file or directory structure resides on the system. It’s then possible to use a number of attack methods to gain access to the system.

Anatomy of an Error Handling Attack

An intruder enters different commands and instructions and uses specific error messages to gather information about potential vulnerabilities. Once the intruder has sufficient information, he or she unleashes an attack.

Error Handling Attack and Defense Examples

Here’s an OWASP example of a HTTP 404 Not Found error that reveals sensitive information:

Not Found
The requested URL /page.html was not found on this server.
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g  DAV/2 PHP/5.1.2 Server at localhost Port 80

This error message is generated when the user requests a non-existent URL. In addition to informing the user that an error has occurred and the file can’t be found, the code delivers valuable information about the web server version, OS, modules, and code used. An attacker can use this information to design an attack.

Here’s an example of a database error that offers attackers insights into the system structure. It’s written in PHP:

try {
openDbConnection();
}
//print exception message that includes exception message and configuration file location 
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';
}

This example from Mitre.org demonstrates how an attacker can target a configuration file, such as a Path Traversal weakness. If the attacker is successful in reading the file, this person could gain credentials for accessing the database. At that point, the attacker might replace the actual file with a malicious file. This could result in the application using an arbitrary database.

Preventing Damage and Remediating Code Are Critical

Relying on default settings for generating error messages from servers, operating systems, databases, and web application is inadequate. It’s important to provide error messages that deliver useful information without revealing unnecessary system or application details. This requires security teams to test sites and other resources for various types of errors and understand how they respond. The next step is a detailed code review that examines error handling logic.

Once an organization has identified vulnerabilities, it’s vital to address any gaps or deficiencies, and strive for consistency across all sites, databases, and web applications. OWASP recommends developing specific policies for how to address errors and for determining what information is provided to users who receive error messages. Finally, it’s critical to log errors and analyze the data to help detect flaws as well as possible hacking attempts. For instance, if a log file shows that errors are generating numerous messages from a default exception handler, a code update is likely required.

CA Veracode Can Aid in the Defense of Improper Error Handling

CA Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including improper error handling, in running web applications, in either production or pre-production environments.

CA Veracode Static Analysis can accurately identify error handling vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing improper error handling and other security flaws through integrated eLearning materials.

 

CREDENTIALS MANAGEMENT FLAWS, TUTORIAL AND CHEAT SHEET

What Is a Credentials Management Attack?

A credentials management attack attempts to breach username/password pairs and take control of user accounts. Once inside a system, an attacker can alter, steal, or delete data; initiate transactions; install additional malware; and gain broader and deeper access to systems and files. There are four primary way attackers breach credentials: 

  1. Through unprotected storage of credentials, which results when a password is stored in plaintext.
  2. Through the use of a hard-coded password, which, as the name implies, uses a hard-coded password for inbound authentication or for outbound communication with external components.
  3. Through insufficiently protected credentials, which is a weakness that occurs when an application transmits or stores authentication credentials and relies on insecure protection methods that may result in unauthorized interception and retrieval.
  4. Through the use of a hard-coded credential that stores passwords or cryptographic keys used for inbound authentication or outbound communication, or for encryption of internal data.

Rates of Credentials Management Flaws in Software

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

How Credentials Management Attacks Work

Credential management vulnerabilities result when developers fail to build in essential protections. This may include a failure to encrypt password data or store credentials in an easily accessible file, or it may involve the use hard-coded passwords that allow an attacker to bypass authentication requirements. In order to pull off a credential attack, intruders might intercept insecure data or use brute force methods. In some cases, such as with hard-coded passwords, attacks can be difficult for a system administrator to detect and fixing a flaw can prove challenging. In fact, in some cases, it may be necessary to disable a product or site entirely. A Veracode analysis of static scan data indicated that credential vulnerabilities exist in 42 percent of applications.

Attack and Defense Examples

Example 1

This is an example of unprotected storage of credentials:

Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, password);

This code reads a password from a properties file and uses the password to connect to a database. Although this code will run correctly, someone with access to the config.properties file can read the value of password. This might include an employee who uses this information to breach the system.

Example 2

This is an example of the use of a hard-coded password vulnerability in Java:

int VerifyAdmin(String password) {
if (!password.equals("Mew!")) {
return(0)
}
//Diagnostic Mode
return(1);
}

The problem with this code is that every instance of this program can be placed into diagnostic mode using the same password. Making matters worse, a binary-only distribution of the program makes it extremely difficult to change the password or disable its "functionality."

Example 3

This is an example in PHP of insufficiently protected credentials:

$user = $_GET['user'];
$pass = $_GET['pass'];
$checkpass = $_GET['checkpass'];
if ($pass == $checkpass) {
SetUserPassword($user, $pass);
}

The above code alters a user’s password. Once the code confirms that the user entered the same password twice, it provides access to the account. It doesn’t check the identity of the user to ensure that it’s the same person. This allows an attacker to take over the account.

Example 4

This is an example of a hard-coded credentials attack:

int VerifyAdmin(String password) {
if (password.Equals("68af404b513073584c4b6f22b6c63e6b")) {
Console.WriteLine("Entering Diagnostic Mode...");
return(1);
}
Console.WriteLine("Incorrect Password!");
return(0);
}

This example demonstrates how a cryptographic key is hard-coded into a string value that’s compared to the password. An attacker who views this code can compromise the system.

Preventing Damage and Remediating Code Are Critical

It’s critical to ensure that developers avoid risky coding practices, including storing passwords in easy to access locations, using plaintext in software, and using hard-coded credentials. The use of encryption is critical, particularly for outbound authentication. It’s also important to limit permissions to only those who absolutely require access to a file, limit key functions to the system console, and design strong protections for files and encryption keys.

For inbound authentication using passwords, it’s smart to use strong one-way hashes to passwords and store the hashes in a strongly protected configuration file or database. It’s also advisable to use randomly assigned salts for every hash that’s generated. This forces an attacker to use more computing resources for a brute force attack, thereby reducing risk. Finally, for front-end to back-end connections, consider the use of randomly and automatically generated passwords that a system administrator must enter within a given time window; limiting functions that a user can access with a password; and ensuring that messages sent are tagged and checksummed with time-sensitive values to thwart replay style attacks.

CA Veracode Can Aid in the Defense of a Credential Management Attack

CA Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including credential management, in running web applications, in either production or pre-production environments.

CA Veracode Static Analysis can accurately identify credential management vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing credential management and other security flaws through integrated eLearning materials.

 

FORMAT STRING FLAWS

What Is a Format String Attack?

A format string attack occurs when an application interprets data as a command and allows an attacker to access the underlying code base. The offending code alters the flow of an application using string formatting library features. This lets an attacker gain access to other memory space. A format string attack can result in a number of exploits, including the ability to inject malware, execute unauthorized commands, and cause segmentation faults that result in changes that diminish the stability of a system or exploit it directly. A format string attack takes place because the application doesn’t properly validate input from the attacker. It most commonly occurs in applications running C, C++ and Perl.

Relevant CWEs:

Severity: 5 Very High

Prevalence: Very Low, Format String vulnerabilities are found in less than 1% of applications

Anatomy of an Attack

A format string attack begins when an intruder takes aim at the Format Function, an ANSII conversion tool designed to convert a more primitive variable of a programming language into a useful human-readable format. Format Function is designed to handle routine tasks such as printf (which outputs a formatted string), fprint (which writes the printf to a file), and sprint (which prints into a string).

However, if these functions aren’t adequately protected, the application can be at risk for a format string attack. The attacker may explore and test the software by inserting specific formatting characters via a form at a website or another input tool. When an application receives certain conversion characters, such as "%f", "%p", or "%n", the attacker is allowed to execute arbitrary code on a server, read values from an attack, or cause segmentation faults or software crashes.

Impact of an Attack

Once an attacker finds a successful intrusion point, he or she can read data from the stack, read character strings from the process memory, or write an integer to locations in the process memory. This allows the attacker to override critical program flags and controls. A format string attack is similar to a buffer overflow or integer overflow. All are rooted in an attacker’s ability to manipulate memory functions. Someone who gains control of a system using a format string attack can read or alter data, change security controls, crash applications, or launch a denial of service (DoS) attack.

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

Attack and Defense Examples

Example #1

This example from OWASP demonstrates how an application will react and behave when it doesn’t receive the necessary validation in the input of a format string. In this example, the application operates normally and has normal inputs. Here’s what the source code for this normal state looks like:

#include  
#include  
#include  

int main (int argc, char **argv)
{
	char buf [100];
	int x = 1 ; 
	snprintf ( buf, sizeof buf, argv [1] ) ;
	buf [ sizeof buf -1 ] = 0;
	printf ( “Buffer size is: (%d) \nData input: %s \n” , strlen (buf) , buf ) ;
	printf ( “X equals: %d/ in hex: %#x\nMemory address for x: (%p) \n” , x, x, &x) ;
	return 0 ;
}

Next, the program supplies outputs when running expected inputs. In this case, the program received the string “Bob” as input and returned it in the output.

./formattest “Bob %x %x”
Buffer size is (14)
Data input : Bob bffff 8740
X equals: 1/ in hex: 0x1
Memory address for x (0xbffff73c)

The inputs “Bob” along with the format strings parameters will be attributed to the variable “buf” inside the code which should take the place of the “%s” in the Data input. So now the “printf: argument looks like:

printf ( “Buffer size is: (%d) \n Data input: Bob %x %x \n” , strlen (buf) , buf ) ;

At this point, when the application prints the results, the format function will interpret the format string inputs, showing the content of a memory address. This allows the attacker to proceed with the exploit.

Example #2

This example shows how a string format attack can lead to denial of service. Normally, when an invalid memory address is requested, the program is terminated.

printf (userName);

However, if the attacker inserts a sequence of format strings, the program will reveal the memory address where other data are stored. This increases the possibility that the program will read an illegal address, crashing the program and causing its non-availability.

printf (%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s);

Preventing Damage

The discovery of a format string attack requires an organization to check for further signs of intrusion or code modification. It also requires a fix for the vulnerable code so that no further damage will take place. Unchecked, a format string attack can lead to a serious breach of data as well as denial of service and other problems.

Remediation Is Critical

It’s important to check all code for format string attack vulnerabilities. One effective method is static analysis. It’s also crucial to fix existing code vulnerabilities. A simple line of code is typically effective. This might take the form of: “write("%s",s);” or “output (s);”

CA Veracode Can Aid in the Defense of Encapsulation Vulnerabilities

CA Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including SQL injection, in running web applications, in either production or pre-production environments.

CA Veracode Static Analysis can accurately identify SQL injection vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them. All without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing SQL injection and other security flaws through integrated eLearning materials.

ENCAPSULATION VULNERABILITIES

What Is an Encapsulation Vulnerability?

Encapsulation refers to a programming approach that revolves around data and functions contained, or encapsulated, within a set of operating instructions. Applications become vulnerable to an attack when they fail to separate or differentiate critical data or functionality within components. When an encapsulation vulnerability exists, bad code creeps across software components or "leaks" from an application. This problem can also lead to cross-domain attacks. Without strong and clearly defined boundaries between control spheres, attackers can gain unauthorized access to data and functions.

Encapsulation Is a Persistent Threat

Source: Veracode State of Software Security 2017

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

Anatomy of an Attack

Step 1: An attacker initiates a non-typical request to a web application or other exposure point and views the resulting error codes. These error codes provide clues about technologies, operating systems, product versions, and other system details.

Step 2: After obtaining detailed system or application information—including things like debugging information or logging data—the attacker fashions an assault based on known vulnerabilities. There are a variety of attack methods possible. These include trust boundary violations, protection mechanism failures, and deserialization of untrusted data.

Step 3: The attacker launches the attack to deny service, cause security mechanisms to fail, or crash a server. This breach can take place via a mobile platform, web server, or other computing system.

The Impact of an Attack

An encapsulation attack can lead to problems that range from relatively benign to catastrophic. By denying service, critical system functionality may be unavailable to users for a period of time. Switching off security controls may lead to extensive damage, including modified, destroyed or stolen data. There’s also the possibility of damage to applications and other tools and resources, or a ransomware attack.

Secure Coding Handbook

Learn best practices from the pros at Veracode.

Get the Handbook

Real-Life Attack Example

In 2016, the San Francisco Metropolitan Transit Agency’s Municipal Rail (known as MUNI) suffered a significant ransomware attack based on an encapsulation vulnerability. The perpetrator demanded a US $73,000 ransom from the transit authority. The transit agency had neglected to patch a Java deserialization flaw that had existed for more than a year. Fortunately, MUNI officials were able to quickly restore systems from backups and thus avoid paying the ransom.

Attack and Defense Code Examples

Example #1:

This example in C Language prints the path environment variable to the standard error stream:

Example #2:

This example in Java prints an exception code to the standard error stream:

The above example exposes a system to a breach by allowing an attacker to dump data into a console, write data to a log file, or view it as a remote user. The system may provide specific information about system vulnerabilities. It might also deliver general information or clues about the underlying operating system in use, the types or nature of applications, and the approach developers have taken in coding applications.

Example #3:

Here’s an example in C#

This example exploits a system or application using the same type of methodology as the Java example above.

Preventing Damage

The discovery of an encapsulation vulnerability requires an organization to cut access to the affected application, database, or system until it can be fully protected. In the case of ransomware, a backup allows the organization to return to a working state quickly and without paying the fee demanded by the attacker.

Remediation Is Critical

It’s critical to check all code for encapsulation vulnerabilities and protect all application sessions from information leakage. One of the most effective tools for this is static analysis. It’s also vitally important to understand how code functions and retest it in different environments and for different uses. For example, a code string may pose no risk in a single-user environment but may introduce a huge vulnerability in a multi-user framework. In a multithreading environment, it’s important to avoid storing user data in Servlet member fields and member fields to store information in the Servlet.

CA Veracode Can Aid in the Defense Against Encapsulation Vulnerabilities

CA Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including SQL injection, in running web applications, in either production or pre-production environments.

CA Veracode Static Analysis can accurately identify SQL injection vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them. All without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing SQL injection and other security flaws through integrated eLearning materials.

About CA Veracode Developer Training

Learn More

Common Web Application Vulnerabilities

Buffer Overflow

Cross-Site Scripting

Cross-Site Request Forgery

Directory Traversal

Failure to Restrict URL Access

Insecure Cryptographic Storage

Insufficient Transport Layer Protection

LDAP Injection

OS COMMAND INJECTION PRIMER: HOW THEY WORK AND HOW TO PREVENT ATTACKS

What is OS Command Injection?

Command injection refers to a class of critical application vulnerabilities involving dynamically generated content. Attackers execute arbitrary commands on a host operating system using a vulnerable application. They pass the bad data to the system shell through forms, cookies, and HTTP headers. This allows the attackers to gain control over a web site and carry out any action or process that the underlying application accommodates. Attackers who gain access to these systems can modify, manipulate, or read data; inject commands that steal data or attack infrastructure; and engage in other damaging activities. Command injection is highly dependent on privileges. It occurs when insufficient input validation takes place.

How Command Injection Works

Step 1: Attackers identify a critical vulnerability in an application. This allows them to insert malicious code into the OS and gain any functionality the underlying application offers. The attackers can unleash the attack even without direct access to the OS.

Step 2: The attacker alters dynamically generated content on a web page using HTML code through an input mechanism such as a form field or cookies.

Step 3: Once the code is inserted into the affected web page, browsers interpret the code. This allows the attackers to execute specific commands across user's computers — along with both users’ networks and the infected system's network.

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

Anatomy of an Attack

There are two basic ways attackers deploy OS command injection:

An application executes a fixed program that operates under its control. After the breach, it accepts outside input as arguments. These arguments trigger various actions and behavior.

Example: The attack script accesses the system call ("nslookup [hostname]") to run nslookup with the HOSTNAME appearing as an argument from the user. If the program does not removed separators included with the externally generated HOSTNAME argument, the attacker can place separators inside the argument and executive his or her own commands.

An application relies on input to select the program that will run along with the commands to include in the attack. The application sanitizes the input and then redirects the command to the OS.

Example: The application relies on exec([COMMAND]). The input is supplied from an external source. Once an attacker controls the [COMMAND] argument, he or she can execute arbitrary commands and desired scripts on the system.

The Impact of an Attack

Problems resulting from an OS command injection attack can range from minor to highly disruptive. An attacker might alter or corrupt a database, steal customer records, use an API to launch a specific process or event, or launch a distributed denial of service (DDoS) attack. Once attackers have gained control of a server, they can use the underlying application to exploit any and all capabilities built into the software. The resulting damage is determined by the user authorizations and security protections an organization has in place. What's more, attackers may retain access to systems even after an organization has detected and fixed the underlying vulnerability.

Preventing Damage

After discovering that an OS command injection attack has taken place, it's critical to cut off access to the application that’s been compromised. This may require a temporary solution, such as blocking access to the vulnerable script until a development or security team can resolve the underlying issue. The task can be addressed in one of two ways: making changes using the native functionality of the web server or altering system access permissions to the affected file.

Secure Coding Handbook

Learn best practices from the pros at Veracode.

Get the Handbook

Remediation is Critical

It's vital to address potential vulnerabilities that could lead to an OS command injection attack. There are a few ways to handle the task:

Preventing manipulation at the source. It's vital that any applications accessible through a web browser avoid user-controllable data in operating system commands. Development and cybersecurity teams should focus on the use of code that doesn't allow for manipulation of server-level tasks via unintended commands.

Rejecting unacceptable code. If it's impossible to find a safer and more secure way to perform server-level tasks, then it's critical to strictly validate all user data. This is often achieved by creating a whitelist of acceptable values. In addition, some organizations limit input to short alphanumeric strings. Any input outside the range of acceptable data is automatically rejected by the system.

Controls over APIs. In some cases, an application might pass a command string for an API to a shell interpreter that handles command chaining and redirection. This can lead to a breach. Instead, the application should only launch a specific process based on a specific name and command line parameters. This way, even if attackers circumvent basic input validation methods, their options and choices are limited.

CA Veracode Can Help with OS Command Injection

CA Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including OS command injection, in running web applications in either production or pre-production environments.

CA Veracode Static Analysis can accurately identify OS command injection vulnerabilities and other flaws in your application and its third-party components, and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing OS command injection and other security flaws through integrated eLearning materials.

About CA Veracode Developer Training

Learn More

Common Web Application Vulnerabilities

CRYPTOGRAPHIC

The danger of Insecure Cryptographic Storage.

Insecure Cryptographic Storageis a common collection of vulnerabilities related to storing sensitive data without the appropriate encryption.

Ideally, in a secure software development lifecycle, all sensitive data should be encrypted. This would include making sure the right data is encrypted, that keys are properly stored and managed, that algorithms known to be bad are not used as part of the process, and that developers are not implementing their own cryptographically insecure technology.

When these guidelines are not followed, and Insecure Cryptographic Storage flaws exist, attackers may gain unauthorized access through malicious software to steal sensitive information like trade secrets, personal information, edit card numbers, personally identifiable information (PII) and trade secrets may be exposed.

To address Insecure Cryptographic Storage issues, developers should also:

  • Identify all sensitive information and encrypt it, even when it’s stored on a hard drive.
  • Overwrite sensitive memory locations as soon as the data is no longer needed in memory.
  • Make sure that sensitive data cannot be overwritten.
  • Identify users who should and should not have access to sensitive data.
  • Identify sensitive data read into memory and overwrite it with random data using strong encryption.

Preventing Insecure Cryptographic Storage with CA Veracode.

There are essentially two approaches to finding and remediating Insecure Cryptographic Storage issues. When the wrong data is being encrypted or keys are being improperly managed, IT teams must reevaluate the scope of their applications, assess internal business processes and find ways to ensure that best practices are being followed.

When Insecure Cryptographic Storage issues arise from using insecure algorithms or deploying an organization’s own insecure cryptography, application security testing technology can remediate a wide range of issues. That’s where CA Veracode can help.

CA Veracode is a leading provider of cloud-based application security testing services that enable organizations to protect their most important software. Built on a unified cloud platform, our suite of testing technologies can be used throughout the SDLC from inception through production toquickly, easily and cost-efficiently find and fix flaws like SQL injection, broken authentication and session management, cross site scripting and more. Our testing services take security beyond software firewalls, adding powerful application-layer security to network security tools.

Software testing services for Insecure Cryptographic Storage.

CA Veracode application security testing services for remediating Insecure Cryptographic Storage include:

  • CA Veracode Greenlight, a service that runs in a developer’s IDE to provide immediate feedback on potential flaws as code is being built.
  • CA Veracode Static Analysis, a service that scans binaries to identify weaknesses and vulnerabilities in code that is built, bought and assembled.
  • CA Veracode Software Composition Analysis, for inventorying and managing vulnerabilities in open source and commercial code.
  • CA Veracode Web Application Scanning, a service that discovers, scans and monitors websites and applications.
  • CA Veracode Vendor Application Security Testing, a service that can find flaws like Insecure Cryptographic Storage in third-party software without requiring access to source code.

Learn more about Insecure Cryptographic Storage and CA Veracode, or visit our AppSec knowledgebase to get answers to questions like “What is spoofing?

UNIT TESTING TOOLS

Unit testing tools can streamline application security.

Unit testing is an approach to application security that uses unit testing tools to determine whether small individual microservices and units of source code are free of flaws and fit for use. By scanning smaller bits of code earlier in the process, unit testing tools enable developers to find flaws faster, fix them more easily and deliver more secure applications with less cost.

The challenge of unit testing tools is the amount of time they can take to administer. Some developers find that writing unit tests can take as long as actually writing the code to be tested. For software development teams facing aggressive build timelines, the added delays that unit testing tools introduce are simply acceptable.

That’s where CA Veracode can help. By providing automated unit testing tools that enable developers to test code quickly, easily and continually, CA Veracode helps software teams build more secure applications from the very start of development.

Unit testing tools from CA Veracode.

As a leading provider of automated software testing solutions, CA Veracode helps to secure and protect the software the world relies on for business-critical operations. CA Veracode’s application security solutions are built on a unified platform that combines automation, process and speed to deliver comprehensive testing technology. In addition to unit testing tools, CA Veracode provides solutions for static analysis, blackbox testing techniques, software composition analysis, vendor application security testing and other approaches to evaluating code. With CA Veracode, developers have the tools they need to find flaws at the very point in development/deployment chain where it is easiest and most cost efficient to fix them.

CA Veracode Greenlight provides unit testing tools that can find security defects in code as it is being written and provide contextual remediation suggestions to fix issues within seconds – right in the developer’s IDE. Most CA Veracode Greenlight scans complete in less than 10 seconds, enabling developers to continue building applications without delay. Greenlight runs in the background and provides actionable and accurate results with very few false positives. With CA Veracode, developers get immediate feedback as soon as a flaw is introduced, and positive feedback when they have taken action to secure the application.

Advantages of CA Veracode’s unit testing tools.

With unit testing tools in CA Veracode Greenlight, development teams can:

  • Identify and remediate flaws in software earlier in the process – with less effort to find them and less time to fix them.
  • Flag flaws as soon as they are written, providing developers with recommendations for efficient remediation.
  • Protect applications with CA Veracode’s static analysis engine which has scanned more than 2 trillion lines of code to date.

 

Learn more about unit testing tools and CA Veracode, and about CA Veracode solutions for mitigating shellshock and complying pci 3.0 with shellshock

UNIT TESTING

The challenge of unit testing.

Unit testing is a software testing method that has been gaining in use and popularity in recent years. By testing small individual units of source code as applications are developed – rather than waiting until a later security hardening stage – defects can be found earlier in the process and flaws can often be remediated faster and with less cost. Unit testing supports Agile development, as it builds testing into the process in a way that let developers make changes more easily. Ultimately, unit testing improves the quality of code and of the shipped product.

The challenge of unit testing: time. Writing effective unit testing programs can sometimes take longer than writing the code to be tested. And for many software development teams, this additional hurdle adds unacceptable delays to the build schedule.

That’s where CA Veracode can help. By providing automated software testing tools that streamline testing processes, CA Veracode is helping to make unit testing faster and easier, enabling teams to use unit testing tools to increase the pace of development rather than slow it.

Unit testing solutions from CA Veracode.

CA Veracode provides application security solutions and Dev Ops tools that help enterprises protect the software they rely on for business-critical operations. Built on a unified platform, CA Veracode testing solutions and software development tools provide a variety of testing methods – from unit testing and static analysis to black box testing techniques and software composition analysis – delivering a comprehensive approach that makes application security testing easier, more effective and more-cost efficient.

CA Veracode Greenlight is a unit testing solution that runs in the background of an IDE and scans smaller units of code as they are being written. Results are immediate, accurate and actionable, with very low false positives. Greenlight provides feedback as soon as a flaw is introduced, along with contextual remediation advice to help fix the issue quickly. Developers can rescan in seconds to ensure that the defect no longer exists. And Greenlight even provides positive feedback when developers take active steps to secure an application.

Benefits of CA Veracode’s unit testing tools.

With unit testing technology from CA Veracode, organizations can

  • Test units of code earlier in the development process to find and fix flaws when it is most cost-effective to remediate them.
  • Combine unit testing with static analysis to ensure that applications meet the organization’s security requirements.
  • Enable developers to get immediate feedback as they are in the act of writing code.
  • Benefit from CA Veracode’s proven application testing engine which has analyzed over 2 trillion lines of code.

 

Learn more about unit testing and CA Veracode, and about CA Veracode’s solutions for PCI 3 compliance.

SOFTWARE DEVELOPMENT TOOLS

Increase speed and security with automated software development tools.

As organizations work to protect software applications from an ever-evolving landscape of threats, automated software development tools for testing can help to improve security while enabling development teams to meet aggressive deadlines.

In a world that is increasingly dependent on mission-critical applications, secure software development is a high priority for enterprises everywhere. Yet, in a recent survey, fewer than 10% of enterprise security officers were certain that their most important applications were tested for flaws before and during production.

In too many cases, build deadlines deter the kind of comprehensive security testing that can find and fix flaws during development. That’s often because traditional software development tools for security testing are cumbersome and time-consuming to use. The result: software is either tested for flaws late in the development process, or worse – not tested at all.

CA Veracode’s automated software testing provide an easy solution to this pervasive problem. With comprehensive software development tools for testing applications from inception through production, CA Veracode enables organizations to produce better software faster and more cost-efficiently.

Software development tools for testing from CA Veracode.

CA Veracode software development tools and application security solutions protect the software that enterprises rely on every day. With CA Veracode, development teams can buy, build and assemble applications with greater confidence that they are free from vulnerabilities and flaws.

CA Veracode’s software development tools are built on a unified platform that combines automation, speed and process to add security testing throughout the SDLC. With CA Veracode’s SaaS-based software development tools, organizations can test software at any point in the development process where it is easy and cost-efficient to do so.

CA Veracode’s comprehensive software development tools.

CA Veracode provides a suite of software development tools that provide multiple approaches to finding and remediating flaws.

CA Veracode Vendor Application Security Testing provides software development tools that can assess the security of third-party applications without needing access to source code.

  • Static Analysis tools scan software from the inside out, reviewing compiled binaries for common vulnerabilities such as cross-site scripting and SQL injection.
  • CA Veracode Greenlight provides developers with immediate feedback on potential flaws as code is being written, running in the background of the developer’s preferred IDE. Greenlight also enables unit testing on microservices as they are being developed.
  • CA Veracode Web Application Scanning (WAS) discovers and inventories all external websites and applications, running lightweight scans on thousands of sites in parallel to identify and prioritize flaws for remediation. WAS combines static analysis and blackbox testing techniques for a comprehensive approach to security testing.
  • CA Veracode Software Composition Analysis offers tools for identifying flaws in open source and commercial applications.

 

Learn more about software development tools from CA Veracode, and about CA Veracode’s solutions for PCI 3 compliance and PCI security.

Pages

 

 

contact menu