OWASP代码安全审查指南

需积分: 10 155 浏览量更新于2024-07-18 1 收藏 2.31MB PDF 举报

"《代码安全审查》是一本详细介绍如何在企业开发过程中集成代码安全审查的书籍，涵盖了代码审查流程、安全漏洞成因分析，并提供了一系列实用的指导原则、检查清单和威胁建模示例。该书是OWASP（开放式网络应用安全项目）的成果，遵循CC Attribution的创作共享协议，由Larry Conklin和Gary Robinson领导的团队编撰。书中不仅讨论了代码审查的执行方法，还涉及了多种类型的常见安全漏洞，并提供了技术参考，包括HTML5的安全特性、同源策略、日志审查、错误处理以及针对主动防御的审查等内容。" 本书的核心内容可以分为以下几个方面： 1. **代码审查流程**：书中详细阐述了如何在软件开发过程中实施有效的代码审查，包括审查的时机、参与人员的角色、审查的深度和广度，以及如何确保审查的质量和效率。 2. **代码审查的注意事项**：作者列出了代码审查时应遵循的“做与不做”原则，强调了审查的目的不仅仅是找错，更在于提升代码质量和安全性。 3. **代码审查检查清单**：提供了一份详尽的检查清单，帮助审查者系统地检查代码中可能存在的安全问题，涵盖各种安全漏洞类型，如注入攻击（A1）、身份验证与会话管理缺陷（A2）、跨站脚本（XSS，A3）等。 4. **威胁建模示例**：通过实例解析如何进行威胁建模，以便在设计阶段识别潜在的安全风险，并提前采取预防措施。 5. **技术参考**：这部分深入探讨了特定的技术主题，如HTML5的安全特性，对同源策略的理解，以及审查日志、错误处理、客户端JavaScript等环节的安全考虑，帮助开发者从各个层面增强代码的安全性。 6. **应对特定安全漏洞**：针对A1到A10列出的十大常见安全漏洞，书中提供了详细的解释和防范策略，帮助开发者理解和避免这些常见的安全陷阱。 7. **审查主动防御**：讨论了如何在代码审查中查找并审查用于主动防御的安全机制，以提升系统的整体安全性。《代码安全审查》是一本全面且实用的指南，它旨在帮助企业和开发者构建更安全的软件，通过严谨的代码审查流程和策略，降低安全风险，提高软件质量。无论是新手还是经验丰富的开发者，都能从中获益，提升其在安全编码和审查方面的专业素养。

Secure Code Review

Knowing the internal code structure from the code review, and using that knowledge to form test cases and

abuse cases is known as white box testing (also called clear box and glass box testing). This approach can lead to

a more productive penetration test, since testing can be focused on suspected or even known vulnerabilities. Us-

ing knowledge of the specic frameworks, libraries and languages used in the web application, the penetration

test can concentrate on weaknesses known to exist in those frameworks, libraries and languages.

A white box penetration test can also be used to establish the actual risk posed by a vulnerability discovered

through code review. A vulnerability found during code review may turn out not to be exploitable during pen-

etration test due to the code reviewer(s) not considering a protective measure (input validation, for instance).

While the vulnerability in this case is real, the actual risk may be lower due to the lack of exposure. However there

is still an advantage to adding the penetration test encase the protective measure is changed in the future and

therefore exposes the vulnerability.

While vulnerabilities exploited during a white box penetration test (based on secure code review) are certainly

real, the actual risk of these vulnerabilities should be carefully analyzed. It is unrealistic that an attacker would

be given access to the target web application’s source code and advice from its developers. Thus, the risk that

an outside attacker could exploit the vulnerabilities found by the white box penetration tester is probably low-

er. However, if the web application organization is concerned with the risk of attackers with inside knowledge

(former employees or collusion with current employees or contractors), the real-world risk may be just as high.

The results of the penetration test can then be used to target additional areas for code review. Besides address-

ing the par-ticular vulnerability exploited in the test, it is a good practice to look for additional places where that

same class of vulnerability is present, even if not explicitly exploited in test. For instance, if output encoding is

not used in one area of the application and the penetration test exploited that, it is quite possible that output

encoding is also not used elsewhere in the application.

5.7 Implicit Advantages of Code Review to Development Practices

Integrating code review into a company’s development processes can have many benets which will depend

upon the processes and tools used to perform code reviews, how well that data is backed up, and how those

tools are used. The days of bringing developers into a room and displaying code on a projector, whilst recording

the review results on a printed copy are long gone, today many tools exist to make code review more ecient

and to track the review records and decisions. When the code review process is structured correctly, the act of

reviewing code can be ecient and provide educational, auditable and historical benets to any organization.

This section provides a list of benets that a code review procedure can add to development organization.

Provides an historical record

If any developer has joined a company, or moved teams within a company, and had to maintain or enhance a

piece of code written years ago, one of the biggest frustrations can be the lack of context the new developer has

on the old code. Various schools of opinion exist on code documentation, both within the code (comments) and

external to the code (design and functional documents, wikis, etc.). Opinions range from zero-documentation

tolerance through to near-NASA level documentation, where the size of the documentation far exceeds the size

of the code module.

Many of the discussions that occur during a code review, if recorded, would provide valuable information (con-

text) to module maintainers and new programmers. From the writer describing the module along with some of

their design decisions, to each reviewers comments, stating why they think one SQL query should be restruc-

tured, or an algorithm changed, there is a development story unfolding in front of the reviewers eyes which can

be used by future coders on the module, who are not involved in the review meetings.

Secure Code Review

Capturing those review discussions in a review tool automatically and storing them for future reference will pro-

vide the development organization with a history of the changes on the module which can be queried at a lat-

er time by new developers. These discussions can also contain links to any architectural/functional/design/test

specications, bug or enhancement numbers.

Verication that the change has been tested

When a developer is about to submit code into the repository, how does the company know they have sucient-

ly tested it? Adding a description of the tests they have run (manually or automated) against the changed code

can give reviewers (and management) condence that the change will work and not cause any regressions. Also

by declaring the tests the writer has ran against their change, the author is allowing reviewers to review the tests

and suggest further testing that may have been missed by the author.

In a development scenario where automated unit or component testing exists, the coding guidelines can require

that the developer include those unit/component tests in the code review. This again allows reviewers within this

environment to ensure the correct unit/component tests are going to be included in the environment, keeping

the quality of the continuous integration cycles.

Coding education for junior developers

After an employee learns the basics of a language and read a few of the best practices book, how can they get

good on-the-job skills to learn more? Besides buddy coding (which rarely happens and is never cost eective)

and training sessions (brown bag sessions on coding, tech talks, etc.) the design and code decisions discussed

during a code review can be a learning experience for junior developers. Many experienced developers admit to

this being a two way street, where new developers can come in with new ideas or tricks that the older developers

can learn from. Altogether this cross pollination of experience and ideas can only be benecial to a development

organization.

Familiarization with code base

When a new feature is developed, it is often integrated with the main code base, and here code review can be a

conduit for the wider team to learn about the new feature and how its code will impact the product. This helps

prevent functional duplication where separate teams end up coding the same small piece of functionality.

This also applies for development environments with siloed teams. Here the code review author can reach out to

other teams to gain their insight, and allow those other teams to review their modules, and everyone then learns

a bit more about the company’s code base.

Pre-warning of integration clashes

In a busy code base there will be times (especially on core code modules) where multiple developers can write

code aecting the same module. Many people have had the experience of cutting the code and running the

tests, only to discover upon submission that some other change has modied the functionality, requiring the

author to recode and retest some aspects of their change. Spreading the word on upcoming changes via code

reviews gives a greater chance of a developer learning that a change is about to impact their upcoming commit,

and development timelines, etc., can be updated accordingly.

Many development environments have coding guidelines which new code must adhere to. Coding guidelines

can take many forms. It’s worth pointing out that security guidelines can be a particularly relevant touch point

Secure Coding Guidelines Touch Point

Secure Code Review

5.8 Technical Aspects of Secure Code Review

Security code reviews are very specic to the application being reviewed. They may highlight some aws that

are new or specic to the code implementation of the application, like insecure termination of execution ow,

synchronization errors, etc. These aws can only be uncovered when we understand the application code ow

and its logic. Thus, security code review is not just about scanning the code for set of unknown insecure code

patterns but it also involves understanding the code implementation of the application and enumerating the

aws specic to it.

The application being reviewed might have been designed with some security controls in place, for example a

centralized blacklist, input validation, etc. These security controls must be studied carefully to identify if they

are fool-proof. According to the implementation of the control, the nature of attack or any specic attack vec-

tor that can be used to bypass it, must be analyzed. Enumerating the weakness in the existing security control

is another important aspect of the security code reviews.

There are various reasons why security aws manifest in the application, like a lack of input validation or

parameter mishandling. In the process of a code review the exact root cause of aws are exposed and the

complete data ow is traced. The term ‘source to sink analysis’ means to determine all possible inputs to the

application (source) and how they are being processed by it (sink). A sink could be an insecure code pattern

like a dynamic SQL query, a log writer, or a response to a client device.

Consider a scenario where the source is a user input. It ows through the dierent classes/components of the

application and nally falls into a concatenated SQL query (a sink) and there is no proper validation being

applied to it in the path. In this case the application will be vulnerable to SQL injection attack, as identied

by the source to sink analysis. Such an analysis helps in understanding, which vulnerable inputs can lead to a

possibility of an exploit in the application.

Once a aw is identied, the reviewer must enumerate all the possible instances present in the application.

This would not be a code review initiated by a code change, this would be a code scan initiated by manage-

ment based on a aw being discovered and resources being committed to nd if that aw exists in other

parts of the product. For example, an application can be vulnerable to XSS vulnerability because of use of

un-validated inputs in insecure display methods like scriptlets ‘response.write’ method, etc. in several places.

5.9 Code Reviews and Regulatory Compliance

Many organizations with responsibility for safeguarding the integrity, condentiality and availability of their

software and data need to meet regulatory compliance. This compliance is usually mandatory rather than a

voluntary step taken by the organization.

Compliance regulations include:

• PCI (Payment Card Industry) standards

• Central bank regulations

within a code review, as unfortunately the secure coding issues are understood only by a subset of the develop-

ment team. Therefore it can be possible to include teams with various technical expertise into the code reviews,

i.e. someone from the security team (or that person in the corner who knows all the security stu) can be invited

as a technical subject expert to the review to check the code from their particular angle. This is where the OWASP

top 10 guidelines could be enforced.

Secure Code Review

• Auditing objectives

• HIPPA

Compliance is an integral part of software security development life-cycle and code review is an important

part of compliance as many rules insist on the execution of code reviews in order to comply with certain reg-

ulations.

To execute proper code reviews that meet compliance rules it is imperative to use an approved methodolo-

gy. Compliance requirements such as PCI, specically requirement 6: “Develop and maintain secure systems”,

while PCI-DSS 3.0, which has been available since November 2013, exposes a series of requirements which

apply to development of software and identifying vulnerabilities in code. The Payment Card Industry Data

Security Standard (PCI-DSS) became a mandatory compliance step for companies processing credit card pay-

ments in June 2005. Performing code reviews on custom code has been a requirement since the rst version

of the standard.

The PCI standard contains several points relating to secure application development, but this guide will focus

solely on the points, which mandate code reviews. All of the points relating to code reviews can be found in

requirement 6 “Develop and maintain secure systems and applications”.

5.10 PCI-DSS Requirements Related to Code Review

Specically, requirement 6.3.2 mandates a code review of custom code. Reviewing custom code prior to re-

lease to production or customers in order to identify any potential coding vulnerability (using either manual

or automated processes) to include at least the following:

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowl-

edgeable about code review techniques and secure coding practices.

• Code reviews ensure code is developed according to secure coding guidelines

• Appropriate corrections are implemented prior to release.

• Code review results are reviewed and approved by management prior to release.

Requirement 6.5 address common coding vulnerabilities in software-development processes as follows:

• Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and

understanding how sensitive data is handled in memory.

• Develop applications based on secure coding guidelines.

The PCI Council expanded option one to include internal resources performing code reviews. This added

weight to an internal code review and should provide an additional reason to ensure this process is performed

correctly.

The Payment Application Data Security Standard (PA-DSS) is a set of rules and requirements similar to PCI-DSS.

However, PA-DSS applies especially to software vendors and others who develop payment applications that

store, process, or transmit cardholder data as part of authorization or settlement, where these payment appli-

cations are sold, distributed, or licensed to third parties.

剩余219页未读，继续阅读

ych1234567890

粉丝: 0
资源: 1

OWASP代码安全审查指南

通用代码安全编程规范

代码审计标准方案.pdf

Fortify-SCA-扫描工具指导手册.pdf

静态代码扫描与代码安全审查

VCG自动代码安全审查工具

源代码安全审查：理论与实践

单片机C语言代码安全审查：防范安全漏洞的隐患，打造安全的嵌入式系统

安全代码审查-S-SDLC与安全代码审查.pdf

「安全研究」安全代码审查-S-SDLC与安全代码审查 - 安全意识.zip

代码审查：已创建仓库以进行安全代码审查

最新资源