Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

Code audit

From Wikipedia, the free encyclopedia
Comprehensive analysis of software source code

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

Guidelines

[edit]

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-riskvulnerabilities 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.An example of a proactive approach is the free code audit service offered by GooApps, which aims to identify and mitigate vulnerabilities early in the development process to ensure the success of mobile applications.[2]


High-risk vulnerabilities

[edit]

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

  • Non-bounds-checking functions (e.g.,strcpy,sprintf, vsprintf, andsscanf) that could lead to abuffer overflow vulnerability[3]
  • Pointer manipulation of buffers that may interfere with later bounds checking, e.g.:if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;[3]
  • Calls likeexecve(), execution pipes, system() and similar things, especially when called with non-static arguments[3]
  • Input validation, e.g. (in SQL):statement := "SELECT * FROM users WHERE name = '" + userName + "';" is an example of aSQL injection vulnerability
  • File inclusion functions, e.g. (in PHP):include($page . '.php'); is an example of aRemote File Inclusion vulnerability
  • For libraries that may be linked with malicious code, returning the reference to the internal mutabledata structure (record, array). Malicious code may try to modify the structure or retain the reference to observe the future changes.

Low-risk vulnerabilities

[edit]

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

  • Client-side code vulnerabilities that do not affect the server side (e.g.,cross-site scripting)
  • Username enumeration
  • Directory traversal
  • Sensitive API keys

Tools

[edit]

Source code auditing tools generally look for common vulnerabilities and only work for specificprogramming 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.[4]

Dependency on requirements

[edit]

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 theintentional attempts to break the system are expected. The program that may only be exposed to the malicious input (likeweb 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

[edit]

References

[edit]
  1. ^"Source Code Audit - FAQ". Archived fromthe original on 2009-02-10. Retrieved2008-02-12.
  2. ^"Free Code Audit for Apps: Ensuring the Success of Your Mobile Application". Retrieved2024-06-12.
  3. ^abc"Guidelines for C source code auditing". Archived fromthe original on 2008-03-28. Retrieved2008-02-12.
  4. ^"Static analysis at the end of the SDLC doesn't workArchived 2010-10-15 at theWayback Machine" by Wayne Ariola, SearchSoftwareQuality.com, September 22, 2008
Retrieved from "https://en.wikipedia.org/w/index.php?title=Code_audit&oldid=1306759900"
Category:
Hidden categories:

[8]ページ先頭

©2009-2026 Movatter.jp