Code audit

Last updated

A software code audit is a comprehensive analysis of source code in a programming project with the intent of discovering bugs, security breaches or violations of programming conventions. It is an integral part of the defensive programming paradigm, which attempts to reduce errors before the software is released.

Contents

Guidelines

When auditing software, every critical component should be audited separately and together with the entire program. It is a good idea to search for high-risk vulnerabilities first and work down to low-risk vulnerabilities. Vulnerabilities in between high-risk and low-risk generally exist depending on the situation and how the source code in question is being used. Application penetration testing tries to identify vulnerabilities in software by launching as many known attack techniques as possible on likely access points in an attempt to bring down the application. [1] This is a common auditing method and can be used to find out if any specific vulnerabilities exist, but not where they are in the source code. Some claim that end-of-cycle audit methods tend to overwhelm developers, ultimately leaving the team with a long list of known problems, but little actual improvement; in these cases, an in-line auditing approach is recommended as an alternative.

High-risk vulnerabilities

Some common high-risk vulnerabilities may exist due to the use of:

Low-risk vulnerabilities

The following is a list of low-risk vulnerabilities that should be found when auditing code, but do not produce a high risk situation.

Tools

Source code auditing tools generally look for common vulnerabilities and only work for specific programming languages. Such automated tools could be used to save time, but should not be relied on for an in-depth audit. Applying such tools as part of a policy-based approach is recommended. [3]

Dependency on requirements

If set to the low threshold, most of the software auditing tools detect a lot of vulnerabilities, especially if the code has not been audited before. However the actual importance of these alerts also depends on how the application is used. The library that may be linked with the malicious code (and must be immune against it) has very strict requirements like cloning all returned data structures, as the intentional attempts to break the system are expected. The program that may only be exposed to the malicious input (like web server backend) must first care about this input (buffer overruns, SQL injection, etc.). Such attacks may never occur for the program that is only internally used by authorized users in a protected infrastructure.

See also

Related Research Articles

<span class="mw-page-title-main">Buffer overflow</span> Anomaly in computer security and programming

In programming and information security, a buffer overflow or buffer overrun is an anomaly whereby a program writes data to a buffer beyond the buffer's allocated memory, overwriting adjacent memory locations.

Defensive programming is a form of defensive design intended to develop programs that are capable of detecting potential security abnormalities and make predetermined responses. It ensures the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.

In computer science, program analysis is the process of automatically analyzing the behavior of computer programs regarding a property such as correctness, robustness, safety and liveness. Program analysis focuses on two major areas: program optimization and program correctness. The first focuses on improving the program’s performance while reducing the resource usage while the latter focuses on ensuring that the program does what it is supposed to do.

Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. During the second half of 2007, XSSed documented 11,253 site-specific cross-site vulnerabilities, compared to 2,134 "traditional" vulnerabilities documented by Symantec. XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.

<span class="mw-page-title-main">SQL injection</span> Computer hacking technique

In computing, SQL injection is a code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution. SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

Uncontrolled format string is a type of code injection vulnerability discovered around 1989 that can be used in security exploits. Originally thought harmless, format string exploits can be used to crash a program or to execute harmful code. The problem stems from the use of unchecked user input as the format string parameter in certain C functions that perform formatting, such as printf . A malicious user may use the %s and %x format tokens, among others, to print data from the call stack or possibly other locations in memory. One may also write arbitrary data to arbitrary locations using the %n format token, which commands printf and similar functions to write the number of bytes formatted to an address stored on the stack.

Code injection is the exploitation of a computer bug that is caused by processing invalid data. The injection is used by an attacker to introduce code into a vulnerable computer program and change the course of execution. The result of successful code injection can be disastrous, for example, by allowing computer viruses or computer worms to propagate.

Vulnerabilities are flaws in a computer system that weaken the overall security of the system.

Application security includes all tasks that introduce a secure software development life cycle to development teams. Its final goal is to improve security practices and, through that, to find, fix and preferably prevent security issues within applications. It encompasses the whole application life cycle from requirements analysis, design, implementation, verification as well as maintenance.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

Taint checking is a feature in some computer programming languages, such as Perl, Ruby or Ballerina designed to increase security by preventing malicious users from executing commands on a host computer. Taint checks highlight specific security risks primarily associated with web sites which are attacked using techniques such as SQL injection or buffer overflow attack approaches.

A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file inclusion vulnerability will result in remote code execution on the web server that runs the affected web application. An attacker can use remote code execution to create a web shell on the web server, which can be used for website defacement.

Dynamic application security testing (DAST) represents a non-functional testing process to identify security weaknesses and vulnerabilities in an application. This testing process can be carried out either manually or by using automated tools. Manual assessment of an application involves human intervention to identify the security flaws which might slip from an automated tool. Usually business logic errors, race condition checks, and certain zero-day vulnerabilities can only be identified using manual assessments.

Secure coding is the practice of developing computer software in such a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities. Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.

Sentrigo was a privately held software company located in Santa Clara, California, USA, until its acquisition in April, 2011 by McAfee.

Software subversion is the process of making software perform unintended actions either by tampering with program code or by altering behavior in another fashion. For example, code tampering could be used to change program code to load malicious rules or heuristics, SQL injection is a form of subversion for the purpose of data corruption or theft and buffer overflows are a form of subversion for the purpose of unauthorised access. These attacks are examples of computer hacking.

In computer science, language-based security (LBS) is a set of techniques that may be used to strengthen the security of applications on a high level by using the properties of programming languages. LBS is considered to enforce computer security on an application-level, making it possible to prevent vulnerabilities which traditional operating system security is unable to handle.

RIPS is a static code analysis software, designed for automated detection of security vulnerabilities in PHP and Java applications. The initial tool was written by Johannes Dahse and released during the Month of PHP Security in May 2010 as open-source software. The open-source version is released under the GNU Lesser General Public License and was maintained until 2013.

Data center security is the set of policies, precautions and practices adopted at a data center to avoid unauthorized access and manipulation of its resources. The data center houses the enterprise applications and data, hence why providing a proper security system is critical. Denial of service (DoS), theft of confidential information, data alteration, and data loss are some of the common security problems afflicting data center environments.

Static application security testing (SAST) is used to secure software by reviewing the source code of the software to identify sources of vulnerabilities. Although the process of statically analyzing the source code has existed as long as computers have existed, the technique spread to security in the late 90s and the first public discussion of SQL injection in 1998 when Web applications integrated new technologies like JavaScript and Flash.

References

  1. "Source Code Audit - FAQ". Archived from the original on 2009-02-10. Retrieved 2008-02-12.
  2. 1 2 3 "Guidelines for C source code auditing". Archived from the original on 2008-03-28. Retrieved 2008-02-12.
  3. "Static analysis at the end of the SDLC doesn't work Archived 2010-10-15 at the Wayback Machine " by Wayne Ariola, SearchSoftwareQuality.com, September 22, 2008